Provocation

Do you have a harness for your data platform, or do you have a coding agent and an admirable amount of hope?


In the third week of June 2026, Nate Jones asked a question that ought to ruin a few weekends: what, precisely, is your harness?

The framing is almost rude in how clean it is. The agent is the worker. The harness is the workbench around it — what it reads, what it remembers, what it is permitted to touch, what proof it must drag back, and what grabs its collar before it does something expensive. You do not launch an agent and stroll off for a coffee. The model underneath keeps improving, the world around it keeps wandering off, and the harness (not your lovingly curated pile of prompts) is the part you are on the hook to maintain. His line: agents are less like apps and more like sailboats. They live in motion. Turn your back and the wind has opinions.

He was not the only one ringing the bell.

At its Data + AI Summit that Tuesday, 16 June, Databricks shipped Omnigent, an open-source "meta-harness" that sits above coding agents like Claude Code and Codex. The phrasing leaves no wiggle room: "LLM capabilities are wrapped into an agent harness," and "the layer you work at shouldn't have to change every time the model does." The model is the commodity. The harness is the product. Read that twice, because half the industry is still spending its energy (and budget) on the commodity.

The same day, Snowflake published a Well-Architected Framework "for the AI era", which opened by listing why agentic projects fall over: "governance, observability, reliability and cost control at scale." Note what is conspicuously absent from that list of executioners. The model.

And a week earlier, at Microsoft's Build session "The AI-Native Data Engineer", Raki Rahman ran agents through production transformations and then — this is the part everyone skips past on the way to the applause — showed the harness he had built to keep the whole thing from setting fire to the warehouse: skills, deterministic tools, a gold-standard test the agent has to match, local compute wired to production data, CI before any merge. It took a principal engineer with years on the platform to assemble that, by himself, with his own two hands (blood, sweat and tokens). That is the going rate. That is what "just use an agent" actually costs once you read the receipts.

Four witnesses. One week. All saying the same unfashionable thing: the model stopped being the hard part. The harness is the hard part now, and it always quietly was.

So let me put Nate's question where it stings. What is the harness for your data platform? And before you answer, run his checks. Every one of them gets nastier the moment the work is data and not software.

The data-harness self-audit: Reading, Touch, Job and Proof.

The data-harness self-audit: Reading, Touch, Job and Proof.

What is it reading?

Your agent reads your source schemas, your dbt models, the documentation that solemnly claims what a table means. Now ask, but with a straight face, how current any of that is and who maintains it. A column got renamed upstream two sprints ago. Ingestion carried on, dutifully as ever. The bad shape slid into silver, then gold, and your agent wrote its transform against a contract that quietly stopped being true. Nate's version of this was a stale wiki making an agent confidently wrong. In data, the stale wiki is your schema — and a keen, proactive agent turns it into wrong numbers that arrive beautifully formatted and full of conviction.

What can it touch?

Reading is the polite half. Can it write to a production table? Re-run a pipeline? Your production data is governed, sensitive, and the sort of thing that ends careers when mishandled. You cannot hand it to an outside tool or let an agent improvise against it the way you cheerfully let it refactor a function. A coding agent can sandbox code all day. It cannot hand itself a throwaway copy of your lakehouse to test a fix against real data without touching production. That bit is genuinely hard, and it is precisely the bit that nobody's glue solves, no matter how confidently the glue is described in the launch post.

What is its job, and is its proof real?

When the agent announces "the orders pipeline is fine," what exactly stands behind that sentence? The spec it built against, the tests that passed, a diff of what actually moved in the data. If it cannot produce those, it is not reporting to you. It is guessing — in grammatically immaculate, fully punctuated, deeply reassuring sentences.

Three assumptions the data case breaks

For the more advanced teams I have spoken to, the thing running their data agents today is a generic coding harness (Claude Code, Codex, Cursor) plus glue. Those tools are extraordinary; I use them every day and would defend them to a room full of Klingons. But they were built for software, and the data case breaks three of their assumptions at once: the context includes data, not just code; production data is governed and cannot be posted to an outside agent; and verification has to run against real data in isolation, not against a set of tidy little unit tests.

Hold that against your coding agent. It reads your repo, not your data. It runs your unit tests, not a validation against a clone of a production table. It knows, beyond doubt, that the code compiles. It has not the faintest idea that the number is wrong.

So the honest answer, for most teams I talk to, is the uncomfortable one: I don't have a harness. I have a brilliant coding agent, a generous pile of glue, and a slowly hardening suspicion that data is not, in fact, code wearing a different hat.

That suspicion is the bet Hemanta Banerjee, Umesh Kakkad and I made when we started Vibedata — that a data team needs a harness built for data, not a coding agent conscripted into a job it never trained for. I am not pitching it here. Though I will confess my definition of "not pitching" softens considerably around anyone who makes eye contact.

If you are responsible for a data team, here is the question worth losing a weekend over: what is the harness for your data platform? And who, exactly, is maintaining it?


This is the first of two parts. The three checks above are the build-time ones — the ones that photograph well. The fourth check does not throw an error and does not knock; it moves in. Part 2 takes up the Day-2 problem.

References

Similar posts

Stay in the loop

New Proof, Provocation, and Practice posts - straight from the team building the harness.

Blog subscribe form