Agents do not doubt
bad data

Sadalage and Chandrasekaran define agent-ready data through five attributes. Each is the flip side of a job humans used to do without thinking, now pushed into the data itself. Missing one does not produce graceful degradation: “Miss one, and the agent won't degrade gracefully the way a person would. It fails confidently.”

The attributes sit in an architecture of three dependent layers. The data foundation supplies validated, contract-governed inputs. The context layer gives those inputs business meaning through domain, semantic, and capability models. The access layer exposes retrieval, real-time queries, and controlled write-back. Observability crosses all three from the beginning.

Four engineering topics build those attributes: data contracts that set a hard quality gate, traceability and governance that answer why an agent acted, context models that fix what the business means, and access patterns that move from searchable to actionable. That order is deliberate, beginning with contracts, “because a single wrong fact poisons every layer built on top of it.”

That gap is the organizational version of the pricing agent: confident and wrong. A separate KPMG Global AI Pulse survey of 2,145 leaders points the same way, with nearly half of executives saying AI's costs now exceed its benefits. The conclusion drawn is that most enterprises remain one stale field away from the scenario above.

The answer is a data contract: schema, quality rules, and a freshness SLA written as a versioned artifact that CI/CD enforces, where a freshness SLA defines how long a dataset or index may go without a successful refresh. Treating schema as law reverses a decade of thinking that schemaless data is inherently more flexible. Loose schemas may be inconvenient for human consumers; for agents, they are dangerous.

Enforcement operates along three dimensions. Schema enforcement makes types and constraints explicit and checks that the data respects them. Freshness SLAs set the maximum acceptable staleness per dataset, and nightly batches are insufficient when an agent answers in real time; the SLA has to be measured from the last successful load rather than the last time a value changed, so steady data is not mislabeled as stale and a stalled pipeline cannot appear healthy. Quality gates validate contracts in CI/CD and block deployments on failure.

That prevents the pricing scenario by design. A source that has not refreshed within 24 hours violates its contract before the agent can access it, so when it is asked for the price, the agent responds I don't have current pricing data instead of confidently quoting the wrong amount. That is a better failure mode, and it is produced by the data architecture rather than the model: A better model won't rescue you from bad data.

A medallion architecture, popularized by Databricks, gives each stage a place. Bronze holds raw, immutable ingestion for audit trails and lineage. Silver holds validated, deduplicated data, with schemas applied, contracts enforced, and quarantine handled. Gold is certified and is the tier the semantic model compiles against. For agentic architectures the authors add Adaptive Gold, where agents monitor their own query patterns, identify frequently accessed combinations, and materialize optimized datasets, effectively building warehouse views from real usage.

The same rules extend to unstructured data. Most of what agents consume is documents, wikis, PDFs, and support tickets, chunked and embedded for retrieval. The stale-price scenario has a twin: a policy document changes, the vector index is not re-embedded, and the agent answers confidently from the old version. So an SLA of 24 hours has to mean that the re-indexing job completed within the last 24 hours; if it did not, the index is stale and quarantined even when no change is visible, because a silently failed indexer is precisely the case where there is no way to tell whether anything changed.

For text, contracts move from content to metadata: every chunk must carry a source, version, timestamp, and access scope, and that metadata is also what makes retrieval traceable and governable later. Quality gates get checks suited to text, rejecting empty or truncated chunks, catching near-duplicates that distort retrieval, flagging extraction failures and OCR garbage, and watching for embedding drift. The same principle applies to a price record and an embedded paragraph: The architecture has to smell what's bad before the agent does.

The pieces are additive, and each can reduce risk independently.

Conventional audit logs can identify the tables queried, the time of each query, and the service account involved. They cannot show why the sanctions list was checked before the credit terms, why the agent accepted a minor documentation discrepancy, or which alternatives it rejected. Traditional audit logs can tell you what happened, but they can't tell you why. Agentic lineage closes that gap using the distributed-systems model: one trace per end-to-end workflow, one span per step.

That is what a regulator needs: not that a service accessed the compliance database at a particular timestamp, but that the agent checked KYC, then sanctions, then credit terms, and approved because all three passed. Engineers already know traces and spans from distributed-tracing tools such as Jaeger and Zipkin. For agentic workloads, Langfuse, Arize Phoenix, and OpenTelemetry for AI are named as the emerging options, and the article reports where each sits on the Thoughtworks Technology Radar, the firm's periodic adoption guidance: OpenTelemetry in Adopt, Langfuse in Trial, Arize Phoenix in Assess. These are the authors' reported rings, not recommendations from this site.

Together the articles create three architectural obligations: log events across the system's lifetime in enough detail to trace its operation rather than as isolated timestamps; retain those logs for at least six months, which means long-term observability storage; and be able to reconstruct why a decision occurred, since the law requires the logs and making them answer a regulator's question is on you. For a large company, even 3% of global turnover runs into the hundreds of millions.

The judgment on scope is restrained. The EU is furthest ahead and no other jurisdiction currently has an equivalent law, but a regulator, auditor, customer disputing a decision, or internal team debugging one may all ask the same question. A system you can't explain is one you can't fully trust, defend, or fix.

Autonomy is therefore staged rather than granted in full on day one, and each stage fixes both what the human does and what must be recorded.

Their analogy is a new hire: purchase requests first, then supervised spending, and eventually a corporate card with limits. Promotion depends on evidence rather than intuition, which means testing before each step rather than only watching production. Agents are hard to test because they are nondeterministic, costly to invoke, and act through tools with real side effects, so teams mock or replay tool and model interactions to make CI tests deterministic and score decisions with evals instead of calling live services on every run. Building that harness is a discipline of its own, and beyond the scope of this article.

Once an agent earns autonomy, three patterns bound what it holds. Delegated access has the agent act with the invoking user's permissions and record whom it represents, rather than through a shared service account that can see every customer, because when a regulator asks who accessed this customer's data, the service account tells you almost nothing. Just-in-time credentials issue a short-lived token per task, so checking a sanctions list gets OFAC API read access for one customer valid for five minutes. Least privilege means processing a letter of credit does not reach into HR or marketing data.

A semantic layer fills part of the gap by holding declarative definitions of metrics, declared once so every consumer derives consistent results. But an agent that acts needs more than definitions of numbers. It must also know what the things in the business are and what it may do to them. Those are three separate bodies of definition.

Nouns, numbers, and verbs. What unites them is not that they are all about meaning, because the capability model plainly is not. It is that each one is a place where a guarantee is declared once, in version control, instead of being worked out afresh by the model on every request: The definitions are the layer; the interface, MCP today, is just the door.

dbt is a transformation tool whose semantic layer declares metrics as code, and its semantic_models already declare entities. The remaining boundary question is why the domain model must stay separate. The authors' answer is that entities declared inside a metrics layer remain scoped to metrics, while the capability model has to be written in the same vocabulary as the semantic one or the two drift apart: A refund acts on the same customer the revenue figure counts. One vocabulary underneath, or you get two.

All three models are code in source control. They pass code review, are tested in CI, and progress through environments before production. When the definition of revenue or the rule on refunds changes, it changes in one place and propagates everywhere. Business logic sits in the definition itself, as in revenue = order_amount - discount_amount, rather than buried in a BI tool or an ad hoc SQL view.

dbt is migrating from measures toward a metrics-first specification; the widely used form is the one shown here, and the point holds under either. Cube.js, Snowflake, and Databricks follow similar patterns, and the tool matters less than the discipline of moving business logic into version-controlled code. The same question then produces very different SQL. Without a semantic model the agent guesses a table name, selects the wrong revenue column, omits the fiscal-calendar mapping, and misses the join.

With one, the query is constrained to the correct table, the net-revenue formula from the definition, the right fiscal-calendar dates, and the valid join path.

The semantic model doesn't make the agent smarter. It stops it from guessing. For an agent that may act on the answer without an analyst checking it first, that constraint is what matters.

dbt's semantic model can dynamically surface only the dimensions that apply to the selected metrics, which prevents plausible sounding but incorrect queries. The lineage returned in step five is the foundation for the traceability covered in section 03, so context and traceability reinforce one another.

On where to start, the warning is against modelling the whole business before shipping anything. Value is concentrated in a handful of contested metrics, the ones that mean different things to different teams; let the first agent use case set the scope, because a narrow, correct context layer beats a sprawling, half-agreed one. The four points: find the conflicting metric definitions, revenue being the classic with its gross versus net and with or without returns; pick a mainstream tool but keep the emphasis on the discipline; route agents through the layer and never the raw schema, with dbt, Cube, and AtScale all shipping MCP servers though the point is the abstraction and not the protocol; and test adversarially, since every hallucination points to a missing definition. Fix the definition, not the prompt.

The parts are called models rather than layers for two reasons: each is a body of definitions rather than a tier of infrastructure, and that is what the tools call them. dbt declares semantic_models, and the vendor-neutral specification that came out of the Open Semantic Interchange initiative, now Apache Ossie, is a semantic model specification.

The domain model goes by other names. Store its entities and relationships as a graph and you have a knowledge graph. Domain-driven design calls it a domain model, and its Bounded Context is the reminder that no single model covers the whole enterprise. Chasing one canonical model is usually a mirage; each domain has its own, governed in the federated way Data Mesh describes.

The industry term is ontology, and it refers to the same artefact, with a longer pedigree than the current wave suggests: a formal, explicit specification of a shared conceptualization, with RDF, OWL, and SHACL as the formal machinery. Strictly, an ontology describes and does not act. Two shipping products stretch it further. Palantir's Foundry Ontology pairs its objects, properties, and links with the actions an agent may take on them, and Databricks' Genie Ontology puts a living graph of a company's concepts on top of its governed metric definitions. The one real difference between Palantir's shape and this one is that it bundles the actions in; here they stay separate because the write path carries different risk from the read path and benefits from being governed on its own terms.

One practical note: none of this is usually written from scratch. The strongest implementations bootstrap from what you already have, table structures, glossaries, and how people actually query, and let humans curate on top.

The division of labour stays clear. The semantic model defines the metrics; the graph carries the connections between customers, products, events, and decisions over time. Together they give agents something close to institutional memory, the kind of knowledge that would take a new hire months to absorb.

The framing comes from Microsoft's Cloud Adoption Framework for AI, which formalizes it as RAG plus MCP-Read plus MCP-Write. Retrieval covers RAG, vector search, and document lookup, where most organizations live today. Real-Time Query lets an agent inspect live systems and read databases at the time of the request. Write-Back is the most capable and most dangerous tier, where the agent creates tickets, updates records, and triggers workflows. Each step up adds capability and risk, and agentic AI requires all three rather than retrieval alone.

The note on protocol is restrained: MCP has quickly become the default way to wire the tiers up, but the mechanism matters less than the demarcation. What counts is keeping retrieval, live reads, and write-back as separate, deliberately governed levels of access, whether they are exposed through MCP or native APIs. The MCP primitives sit on the same risk gradient. Resources are read-only and safe, Prompts shape behavior, and Tools change state, which is why the safe path exposes Resources first and graduates to Tools only under governance.

The Thoughtworks Tech Radar put naive API-to-MCP conversion on HOLD for exactly this reason. The principle is to design capabilities, not endpoints, and the authors claim that Five to ten well described business capabilities will outperform 50 thin API wrappers almost every time, presenting it as a design principle. It is also protocol-agnostic: whether an agent reaches your data through MCP, another agent, or whatever standard comes next, the properties that make it agent-ready are the same, rich descriptions, parameterized access, clear schemas.

With all three tiers in place the PO workflow runs end to end in one pass. Done manually, the employee would wait in a queue, explain the issue, have a support agent check the monitoring dashboard, and get a ticket created. The four starting points: map what your top three use cases need, retrieval, real-time query, or write-back, since most gaps live in the latter two; group existing APIs into 5–10 well-described business capabilities; start with MCP Resources, the lowest-risk entry point; and instrument from day one, logging every tool invocation, who triggered it, what was called, when, and critically on whose behalf.

Preconditions are checked deterministically against live state at the moment of action. Facts read earlier while the agent formed its plan cannot be carried forward as authorization assumptions, because state may change between planning and execution. The agent may propose an action, but its plan never becomes authority by itself.

Reversibility provides a separate classification of operational risk, and the amount involved does not determine the class.

Every capability already declares permissions and an owner; preconditions and reversibility add two more execution boundaries. The authors argue that reversibility is a better guide to safe autonomy than transaction size. A platform team may derive a precondition from a refund policy, contract, or compliance manual, but the model does not read that natural-language document at execution time and decide whether it grants permission. Natural-language interpretation can inform a recommendation; it cannot authorize a state-changing action.

An agent may still retrieve a customer complaint, inspect contract language, or read a policy passage. That material can shape a recommendation, explain why a case appears eligible, identify missing information, and serve as evidence for a human approver. Only the structured rule, evaluated deterministically against current state, can open the execution gate.

This is described as a specific security property, and as a stronger claim than merely shrinking what a hijacked agent can reach. A poisoned document may still distort a recommendation or mislead a human approver, so this is not complete protection against prompt injection. What the boundary removes is the path where the document authorises the action directly, with nobody in between.

The provenance link is what keeps the declarations honest as the documents move underneath them, and the source is careful about what it buys. Detecting that a document changed is easy; knowing that the change invalidated a precondition derived from it is a judgement, not a diff. What the link buys is a review queue, in the same spirit as keying a freshness SLA to when the index was last rebuilt rather than to when the content last appeared to change.

Where no declaration covers the situation, the agent does not improvise from its own reading of policy. It escalates. This is the hard gate from section 02 in a different setting: an undeclared case degrades the agent to supervised, not to autonomous.

The dependencies run bottom-up. Meaning cannot be attached to data that cannot be trusted, so context sits on the foundation, and agents cannot act safely without that meaning to constrain them, so access sits on context. Skipping either leaves everything above it without footing. That's exactly why so many agentic AI programs stall. They jump straight to agent access without building the foundation underneath.

Observability is different. Rather than a fourth tier stacked on top, it runs alongside all three, and every layer has to be traceable and auditable from the moment it handles real work. The trust checks, the semantic queries, the agent's actions, all of it has to be explainable in production, not at whatever later point it gets instrumented. Retrofitting observability onto a running system is much harder than building it in from the start, so it belongs in every layer from day one.

The stack has one more dependency the diagram cannot draw. Every layer produces an artifact that has to be kept accurate, and Artifacts don't maintain themselves.

The technology is necessary, but it's the operating model that keeps it honest. The discipline that makes it work is treating data as a product: each dataset, contract, and metric has a named owner, a published contract and SLA, and a versioned lifecycle, the same way an API does. You will not always know every consumer, and for public or broadly shared data you cannot, which is precisely why the contract matters, since it is the stable promise unknown consumers build on, and a deprecation policy is how you change it without breaking them.

Ownership becomes concrete under pressure. When the product_pricing contract blocks a deployment at 2 a.m., someone is accountable for it. When finance and sales disagree on revenue, someone owns the decision. When a new agent asks for access, someone owns the scope and reviews it. These aren't infrastructure questions; they're ownership questions, and no tool answers them for you. A human consumer of an unowned, drifting dataset notices and works around it; an agent consumes it at machine speed and scale and propagates the error just as fast.

Before deciding what to build, the authors suggest locating the organization first. The table scores each attribute against signals drawn from the topics above.

Each topic came with its own starting points, which are tactical checklists for the work itself. The four below are where to start. Instrumentation comes first because it is not a build-order step; it runs alongside everything else and never stops. The other three build from the bottom of the stack up, and the authors identify the context layer as the highest-leverage single move, since context moves accuracy further than a bigger model does, but only once the data beneath it can be trusted.