Which of Your Agents Is Actually Ready?

In an executive review I was asked which of five agents launching that quarter would be running on data that was actually ready for them. I said none of them.

It was not a brave answer. It was the only defensible one, and I would have much preferred to have a different one.

The failure was consistent enough across teams to be structural rather than technical. Every domain had two engineering groups. One was building agents. One owned the data. They were not talking to each other, and the agent teams were on the faster clock. So they copied the data they needed and launched anyway.

Some of it worked immediately and genuinely well. Connecting unstructured sources produced real wins in weeks — duplicate invoices surfaced, payment-term discrepancies found across thousands of contracts and documents that no human was ever going to read. That part was not hype.

Where it fell apart was merging that with structured data. Missing master records. Entities that could not be resolved, so the same company appeared three times under three identifiers. Quality nobody had ever characterized, because until an agent consumed it, nobody had needed to. Projections in one order of magnitude, delivery in another.

And the conclusion in the room afterward was almost always that the model had disappointed them.

It had not. The rule that nobody could state was this: this agent may only operate on data that meets this standard of freshness, accuracy and policy. Everybody agreed with that sentence. It lived nowhere. It was enforced by hoping.

So we made it exist somewhere.

The unit is the data product — a logical cluster of tables and interfaces, owned by the domain that actually understands it. Attached to each one is a contract declaring what it guarantees: refresh cadence, accuracy, integrity, and the security policy that governs it. A product intended for reporting promises daily freshness. One intended for real-time transactional use guarantees millisecond writes as part of the contract. The owner declares it once. Every consumer inherits it without asking anyone.

Then map the chain so executives can see it: business outcomes to the data products that serve them, and data products to the agents that consume them. Suddenly a roadmap dependency that used to surface in an incident review is visible a quarter ahead.

And put the check somewhere the agent cannot route around. Not a review board, not a launch checklist. When a query is decomposed during disambiguation, the system checks whether the contract is met before calling the data product. An agent either meets its contract or it declares the dependency.

The framing mattered as much as the mechanism, and I want to be explicit about it, because it is where most governance efforts lose. We did not sell readiness as a gate. Gates get routed around, and the routing is invisible until something breaks in front of a customer. We sold it as what it actually delivers to the person doing the work — better evaluation quality, higher developer velocity, lower cost to build a working agent. The requirement was identical. The adoption was not.

What I would tell anyone standing where I was:

• Ask which of your launching agents runs on data with a stated contract. If the answer is none, that is not a crisis, it is a starting position — but you have to say it out loud in a room with budget in it.
• Make the data product the unit, not the table and not the pipeline. Contracts do not attach to assets at any useful scale.
• Put the check at a machine boundary. Anything enforced by a meeting is enforced by hoping, with extra steps.
• Expect the fix to be organizational. Two teams not talking to each other is the actual defect.

The AI-readiness problem was an organizational problem wearing a data costume.

Almost every enterprise deploying agents right now is going to find this out. Most will find it the expensive way: after the demo, in production, in front of an auditor.