In Part 1 I borrowed Nate Jones's question — what is the harness for your data platform? — and ran the first three checks: what your agent reads, what it can touch, and whether its proof is real. Those are the build-time checks, the ones that photograph well. This part is about the check I held back, because it does not behave like the others. It does not knock. It does not throw an error. It moves in.
Here is where data stops pretending to be code. A software bug throws an error you can see, swear at, and fix. A data bug sits quietly in a production table for weeks, corrupting everything downstream with impeccable manners, and you discover it only when the business has already made decisions on the numbers. Or worse: when the business questions the numbers and decides the whole data platform is not to be trusted. Now point an agent at that table. It does not pause. It does not frown. It consumes the bad data with relish and makes confident decisions on it, fast, at a scale no human will review until the quarter is already a crime scene.
The big platforms, independently, reached for nearly the same two words: silent, and permanent. When Databricks announced Genie ZeroOps, it carried a section title I am genuinely planning to put on a t-shirt: "Why coding agents can't solve data and AI operations." Snowflake, the same week, named the failure mode that should keep every data engineer up at night: "a silent failure in an agentic workflow is the worst kind — no alert, no recovery, just wrong answers." That fourth check is not a build problem you can sprint your way out of. It is a Day-2 problem, and Day 2 is where the harness gap actually lives — quietly, rent-free, for months.
I suspect a few of you have been down the same AI-psychosis rabbit hole I have. Notice that almost every agent demo you have ever clapped for is a build demo — watch it write the pipeline, generate the dbt model, scaffold the transform, take a bow. Build is the photogenic half, the half that gets the keynote slot and the standing ovation. But as my CTO at Rackspace, Srini Koushik, used to say: 99% of the value of any solution is in production. The applause happens on Day 0. The value, and the carnage, happen on Day 2 — where pipelines snap at 2am, data drifts like a moored boat in a storm, and a model keeps serving beautifully confident wrong answers long after the last human stopped watching.
It is also, conveniently, where the big guys are now pointing. Genie ZeroOps is a Day-2 agent (detect, assess, remediate, verify), and Databricks' entire argument is that a coding agent simply cannot run those steps for data. Snowflake's nightmare is an operational silent failure. Even the Microsoft demo I cited in Part 1, impressive as the build was, wired CI against production data before any merge — because catching a bad transform after it ships is not caution, it is an apology.
Build and operate are not the same job, and pretending they are is how teams end up surprised. Build rewards patience: get the spec right, cover the edge cases, be thorough before anything ships. Operate rewards the precise opposite: find the break and fix it fast without making it worse. Different objectives, different guardrails, arguably different agents doing the work entirely. A serious data team needs a harness for both. Shipping a pipeline quickly counts for absolutely nothing if nothing trustworthy is watching it the morning after.
And even once you have built all that — congratulations, you are still not finished, because a harness rots. Nate's sharpest point is that agents break in two directions at once, which is a deeply unsporting thing for a problem to do. The world drifts: schemas change, sources move, and the one person who knew why a model was built that way walks out the door. Meanwhile the model improves underneath you, so the guardrail that heroically saved you from last year's clumsy model now quietly handcuffs this year's capable one. A harness is not a wrapper you build once and frame on the wall. It is a system you maintain, indefinitely, like a boat that is genuinely at sea and does not care about your roadmap.
Which means most teams still have a great coding agent and a generous pile of glue — except they have now graduated from suspicion that data isn't code to grim, well-evidenced certainty.
There is the gap, in plain sight. A purpose-built harness for the full data lifecycle, build and operate, running inside your own perimeter. That is the bet Hemanta Banerjee, Umesh Kakkad and I made when we started Vibedata — though once the rest of the industry started answering the question out loud, in keynotes, it rather stopped being our private thesis. In Part 1 I said I was not pitching. As a founder, I should disclose that my definition of "not pitching" did not survive the week between these two parts.
The point of both parts is still the question. What is the harness for your data platform once it is in production? And who is maintaining it when the schema drifts, the model improves, and the person who knew why a pipeline was built that way has long since left?