{"slug": "making-your-data-ready-for-agentic-ai", "title": "Making Your Data Ready for Agentic AI", "summary": "A new report argues that enterprises must rebuild their data infrastructure for autonomous AI agents, which lack the human judgment to detect bad data, and outlines a five-layer stack including trusted data, context, access, observability, and governance. The report, published on 27 August 2026, emphasizes that agents act confidently on incorrect data, so data must be made accurate, contextual, and traceable before agent frameworks can deliver value.", "body_md": "# Making Your Data Ready for Agentic AI\n\n*For thirty years we built data systems for human analysts, who\nsupply the context, judgment, and skepticism to work around data that's\nincomplete or wrong. Autonomous agents supply none of that. They act on\nwhatever they're handed, confidently. For data to be AI-ready we need to\nbuild a series of layers: a data foundation that makes data trusted, a context\nlayer to apply proper meaning, and an access layer that supports and controls\nhow agents operate on that data. While doing this we need continuous\nattention to observability that ensures the data is properly governed and we\nhave an auditable trace of its use in decision-making.*\n\n27 August 2026\n\n## Contents\n\n[The consumers of your data are changing](#TheConsumersOfYourDataAreChanging)[What “AI-ready” has to mean now](#Whatai-readyHasToMeanNow)[Data Contracts and Quality: Agents Can't Smell Bad Data](#data-contracts)[Traceability and Governance: Auditing Autonomous Agents](#traceability)[The Context Layer: Teaching Agents What Your Data Means](#context-layer)[From Searchable to Actionable: Agent-Ready Data Access](#actionable)[The AI-ready data stack](#TheAi-readyDataStack)[Who owns all this?](#WhoOwnsAllThis)[Where do you stand?](#WhereDoYouStand)[Four things to start on](#FourThingsToStartOn)\n\n### Sidebars\n\nThere's a lot of excitement right now about agent frameworks, orchestration patterns, and protocols. All of it matters, but almost none of it delivers value if you skip the data layer. Before any agent framework can produce useful outcomes, your data has to be in a shape that a machine can consume, trust, and act on. In this article, we discuss what your data needs to look like for agentic AI to derive value from it.\n\nWe've spent quite a bit of time building data architectures for the human consumer. We're about to hand those architectures to a very different kind of consumer, and most of them aren't ready for it.\n\n## The consumers of your data are changing\n\nFor over three decades, we've been building data systems for humans. Dashboards, reports, analyst queries, all of it designed around a person sitting in front of a screen. And it worked, because humans bring an enormous amount of implicit context, along with the curiosity to track down whatever they're missing from the people around them.\n\nA human analyst knows what “revenue” means in your particular organization. They know which tables to query and which ones to avoid. They notice when a number looks off, when a total is suspiciously round, when a date falls on a public holiday, or when a price seems too low. That instinct is doing a large amount of invisible context and knowledge work.\n\nA human hesitates at data that looks wrong; an agent acts on it anyway\n\nAgents have none of it. They can't lean on the tribal knowledge and pattern recognition people accumulate over years, so they need context made explicit, access in real time, and quality they can rely on. And the difference that matters most is this: when the data feels wrong, a human double-checks; an agent confidently acts on it. That behavioral gap is what the rest of this discussion is built around.\n\n## What “AI-ready” has to mean now\n\nFor a human consumer, the data only had to be *good enough*; the\nanalyst did the rest. The meaning, the sanity check, and the judgment\nabout whether a number could be trusted all lived in a person's head.\nWhen the same data is handed to an agent, every bit of that implicit\nlabor has to move into the data itself. That shows up as five\nattributes, each the flip side of something a human used to do for\nfree.\n\n- Trusted: a person pauses at a number that feels wrong; an agent acts on it. The confidence a human used to supply has to be built in, so the data must be accurate, fresh, and validated before the agent ever sees it.\n- Contextual: a person knows your “revenue” figure already has returns taken out, and that your fiscal year starts in February; an agent has to be told both. Meaning that used to live in someone's head has to be made explicit in the data.\n- Traceable: when a person decides, they can explain why afterward; when an agent decides in 30 seconds, that reasoning is gone unless you capture it as it happens. You have to be able to reconstruct what the agent did and why.\n- Governed: a person's access is bounded by their role and their judgment; an agent's has to be bounded by design. Access must be scoped, controlled, and auditable.\n- Operational: a person reads a dashboard and then goes and does\nsomething; an agent has to be\n*able*to do the something. The data can't just be readable, it has to be actionable.\n\nAll five come down to the same idea. Each is a job humans used to do without thinking, now pushed into the data itself. Miss one, and the agent won't degrade gracefully the way a person would. It fails confidently.\n\nNone of these attributes builds itself. The rest of the article works through four topics that do, roughly in the order you should tackle them.\n\n[Data Contracts and Quality](#data-contracts)makes data*Trusted*. We start here, because a single wrong fact poisons every layer built on top of it.[Traceability and Governance](#traceability)records why an agent acted and bounds what it can reach, making data*Traceable*and*Governed*.[The context layer](#context-layer)encodes what your metrics and entities mean, making data*Contextual*.[From Searchable to Actionable](#actionable)lets agents query live systems and write back, making data*Operational*.\n\nWe'll take them one topic at a time, and show what it takes to build each attribute in. Work through all four, and the five attributes stop being abstract goals. They become something you can engineer, turning ordinary data into AI-ready data.\n\n## Data Contracts and Quality: Agents Can't Smell Bad Data\n\nHumans have a smell test for bad data. They notice when a number\nlooks off, when a date makes no sense, or when a price seems wrong.\nAgents have no such instinct. As Simon Willison puts it, [language models are gullible](https://simonwillison.net/2023/Oct/14/multi-modal-prompt-injection/), they believe\nwhatever they are handed and act on it. Feed an AI agent a wrong\nvalue, and it won't pause to wonder, it will use the number and\nproduce a confident, wrong answer. Without trusted data, nothing else\nin agentic AI works, so this is where we begin.\n\n### Agents treat every value as truth\n\nConsider a concrete scenario. A pricing agent is asked for the\ncurrent price of Product *X*. Yesterday, the price was updated from\n$49.99 to $59.99. But the agent's data source hasn't refreshed, it\nstill shows the old number.\n\nThe agent doesn't hesitate, it retrieves $49.99, quotes the\ncustomer, the customer buys, and the company loses $10 on every unit\nsold. Every step the agent took was technically correct. It followed\nits workflow perfectly. The *data* it accessed was the\nproblem.\n\nThe leaders most confident their data is AI-ready also name data readiness their biggest barrier\n\nA human sales rep would have paused: “Wait, didn't we update this\nlast week?” They'd double-check. They have institutional memory and a\nfeel for when something's off. The agent has neither. Errors don't\ntrigger warnings; they cascade silently through the workflow. And\nthis isn't a rare edge case. In the 2026 [State\nof Data Integrity and AI Readiness](https://www.lebow.drexel.edu/sites/default/files/2026-01/lebow-precisely-state-data-integrity-ai-readiness-2026.pdf) report, Precisely and Drexel\nUniversity's LeBow College of Business surveyed 505 data and analytics\nleaders, of whom 87% believed their data was ready for AI, yet 43% named\ndata readiness as the single biggest barrier to getting value from it. That\ngap between confidence and readiness is the organization-level version\nof the pricing agent, sure of itself and wrong. A separate [KPMG Global AI Pulse](https://kpmg.com/xx/en/media/press-releases/2026/06/growing-adoption-signals-progress-as-cost-visibility-and-accountability-drive-ai-value.html) survey of 2,145 leaders points the\nsame way, with nearly half of executives now seeing AI's costs exceed its\nbenefits. Most enterprises are one stale field away from the scenario\nabove.\n\n### Schema is law: data contracts as code\n\nSo how do you prevent AI agents from accessing bad or stale\ndata? The answer is *data contracts*, treating schema as law,\nnot a polite suggestion.\n\nThis reverses a decade of “schemaless is flexible” thinking,\nfor human consumers, loose schemas are merely inconvenient, while\nfor AI agents, they're dangerous. A data contract, written in the\n[Open Data Contract\nStandard](https://github.com/bitol-io/open-data-contract-standard),\nthe format the [Data Contract CLI](https://cli.datacontract.com)\nuses (and recommended in [Thoughtworks tech radar\n33](https://www.thoughtworks.com/radar/tools/data-contract-cli)),\ndefines the rules explicitly. A `product_pricing`\n\ncontract might\nspecify:\n\n- Properties with strict logical types.\n- A quality rule that\n`price`\n\nmust be greater than zero. - A quality check on\n`currency`\n\nthat rejects anything outside USD, EUR, or GBP. - Critically, a\n*freshness SLA*, pricing data must have been refreshed within the last 24 hours.\n\nIn the Open Data Contract Standard, that contract is shown below.\n\n```\napiVersion: v3.1.0\nkind: DataContract\nid: product-pricing\nname: Product Pricing\nversion: 1.0.0\nstatus: active\nschema:\n  - name: product_pricing\n    physicalType: table\n    properties:\n      - name: product_id\n        logicalType: string\n        physicalType: varchar(64)\n        required: true\n        unique: true\n        primaryKey: true\n        primaryKeyPosition: 1\n      - name: price\n        logicalType: number\n        physicalType: decimal\n        required: true\n        quality:\n          - type: sql\n            description: Every price must be greater than zero\n            query: SELECT min({property}) FROM {object}\n            mustBeGreaterThan: 0\n      - name: currency\n        logicalType: string\n        physicalType: varchar(3)\n        required: true\n        quality:\n          - type: sql\n            description: Currency must be a supported ISO code\n            query: SELECT count(*) FROM {object} WHERE {property} NOT IN ('USD', 'EUR', 'GBP')\n            mustBe: 0\n      - name: ingested_at\n        logicalType: timestamp\n        physicalType: timestamp\n        required: true\nslaProperties:\n  # the rule that would have caught the stale-price scenario\n  - property: latency\n    value: 24\n    unit: h\n    element: product_pricing.ingested_at\n```\n\nEnforcement happens along three dimensions.\n\n- Schema enforcement ensures types and constraints are respected and made explicit by the contract.\n- Freshness SLAs define the maximum acceptable staleness per dataset, nightly batch updates aren't enough when an agent answers in real time. Key the SLA to when the data was last successfully loaded, not when a value last changed, so that steady data isn't flagged as stale and a stalled pipeline can't masquerade as fresh.\n- Quality gates validate contracts in CI/CD, blocking deployments when they fail.\n\nNotice how this changes the earlier pricing scenario, it\nprevents it by design. If the pricing data hasn't been refreshed\nin 24 hours, the contract is violated *before the agent ever sees\nthe data.*\n\n### The quarantine pattern\n\nDefining a contract is one thing. What happens when data violates it? You need a circuit breaker and that's the quarantine pattern.\n\nThe flow works like this. Raw data arrives from source systems, APIs, databases, streams. Before it enters the agent accessible data store, it passes through a contract validation gate that checks three things, does it match the schema, is it within the freshness SLA, and does it pass the quality rules?\n\nIf it passes all three, it flows into the certified, agent ready tier. If it fails any one of them, it's quarantined, routed to a dead letter queue for human review, with alerts fired.\n\nBad data lands in a dead-letter queue, never in front of the agent\n\nThe point is that the agent never sees the bad data. It\ndoesn't get poisoned by stale prices or corrupted embeddings. In\nthe pricing scenario, if the `ingested_at`\n\ntimestamp is older\nthan 24 hours the contract is violated and the record is\nquarantined, so when asked about the price the agent says, “I\ndon't have current pricing data” rather than confidently quoting\nthe wrong number. That is a far better failure mode. And it's a job\nfor the data architecture, not the model. A better model won't rescue\nyou from bad data.\n\n### Medallion architecture for agents\n\nA medallion architecture is an analytical data design pattern for\norganizing data in a [lakehouse](https://www.databricks.com/blog/what-is-data-lakehouse),\npopularized by [Databricks](https://www.databricks.com/blog/what-is-medallion-architecture).\n\nBad data gets quarantined, but where does the *good* data go?\nThat's what the medallion architecture organizes, and its first three\ntiers are well established:\n\n- Bronze: raw, immutable ingestion. You keep everything for audit trail and lineage.\n- Silver: validated and deduplicated. Schema is applied, data contracts are enforced, and this is where the quarantine pattern lives.\n- Gold: certified. This is what the semantic model compiles against, access is governed, and metrics are trusted.\n\nFor agentic architectures, there's a useful fourth tier worth\nadding: **Adaptive Gold** where agents become active\nparticipants in data curation rather than passive consumers (shown\nin the figure below). They monitor their own query patterns,\nidentify frequently accessed combinations, and materialize optimized\ndatasets, effectively building their own warehouse views based on\nreal usage. The idea that agents can actively curate data, rather\nthan only read it, is already in production, at [DataHub's CONTEXT 2025 summit](https://datahub.com/blog/context-2025-highlights/), Apple\ndescribed agents acting as “digital stewards” of its data catalog,\ncontinuously scanning metadata, flagging gaps, and proposing\nupdates, turning passive documentation into an active governance\npartner. Apple's agents curate the *catalog*; Adaptive Gold points\nthat same active-curation pattern at the *datasets* themselves. That\nlast step is an extrapolation, but a modest one from something\nalready running.\n\nFigure 1: Medallion tiers for agents: data flows from raw Bronze through validated Silver to certified Gold and agent curated Adaptive Gold, while agents are restricted to Gold and above.\n\nBronze and Silver are for humans; agents see only Gold and above\n\nThe key architectural principle is that agents should only access Gold tier or above. Bronze and Silver exist for lineage, debugging, and human investigation. Exposing raw or partially validated data to agents invites the pricing problem back in.\n\n### The same rules for unstructured data\n\nEverything so far has looked like a table, prices, currencies,\ntimestamps, but most of what agents consume isn't tabular. It's\ndocuments, wikis, PDFs, and support tickets, chunked and embedded\ninto a vector store for retrieval. If your agents do RAG, this is\nthe data they run on, and it needs the same trust guarantees, even\nthough you can't write `price > 0`\n\non a paragraph. The patterns\ncarry over, only the quality dimensions change.\n\nThe stale-price scenario has a twin here. A policy document gets\nupdated, but the vector index isn't re-embedded, so the agent\nretrieves the old version and answers confidently from it, the same\nfailure as the stale price, only now it's an embedding rather than a\nrow. The *freshness SLA* carries over, but be precise about what\nthe clock measures, the point isn't when the content last changed,\nit's when the index was last successfully rebuilt against its\nsources. A 24-hour SLA means the re-indexing job must have completed\nwithin the last 24 hours, if it hasn't, the index is stale and\nquarantined even when nothing appears to have changed, because a\nsilently failed indexer is exactly when you can't tell whether\nsomething did. That one heartbeat catches both the *updated but\nunindexed* document and the pipeline that quietly stopped.\n\n*Contracts* move from the content to the surrounding metadata.\nYou can't constrain the prose, but you can require that every chunk\ncarry a source, a version, a timestamp, and an access scope, and\nreject anything that doesn't. That metadata is also what makes\nretrieval traceable and governable later.\n\n*Quality gates* get checks suited to text, reject empty or\ntruncated chunks, catch near-duplicate documents that skew\nretrieval, flag failed extractions and OCR garbage, and watch for\nembedding drift. A malformed or empty embedding warps similarity\nsearch, so it never reaches the store, for the same reason a bad\nprice never reaches the agent, a warped index makes the agent\nretrieve confidently wrong content.\n\nWhether the data is a priced row or an embedded paragraph, the job is identical. The architecture has to smell what's bad before the agent does.\n\n### Confidence-threshold routing\n\nContracts, quarantine, and the medallion architecture handle the clear cases. But there's a gray area, data that isn't clearly bad, but isn't fully trustworthy either. That's where confidence-threshold routing comes in, bridging full autonomy and full human control.\n\nThe agent processes a request and assesses data quality signals,\nand checks not just *model* confidence, but *data-level* signals\nlike freshness, completeness, and consistency. If confidence is at\nor above the threshold (say 85%), the agent proceeds autonomously.\nBelow it, the agent defers to a human. The threshold is configurable\nper use case, for example, pricing might demand 90%, while an\ninternal FAQ is fine at 70%.\n\nLet's return to the pricing scenario one last time. The price data is three days stale; the freshness SLA says 24 hours. The SLA violation automatically drives the confidence score below the threshold, regardless of how confident the model itself feels about its answer. The agent should respond by pulling a human in:\n\n“I'm not confident this price is current. Routing to a human for verification.”\n\nData quality signals should drive the threshold, not just the model's own confidence\n\nIn other words, data quality signals should drive the threshold, not just the model's own confidence. A model can be sure of a stale answer, and the freshness SLA overrides that misplaced certainty.\n\nThe hard part is turning those quality signals into a single score and weighing it against the model's own confidence. That's an open design problem, not a solved one. Start with a hard gate rather than a smooth composite. Any contract or SLA breach forces a human, regardless of how the other signals look. Add weighted scoring later, and only once you can show it beats that simple rule.\n\n### Where to start\n\nYou don't have to build all of this at once, and most teams can't. Contracts, quarantine gates, a medallion architecture, and confidence-threshold routing are a lot to stand up in one go. The good news is that they're additive, each one lowers risk on its own, and you can layer in the rest over time. Begin with the highest leverage moves and expand from there.\n\n- Define freshness SLAs for every dataset agents touch. The same dataset can have different freshness requirements per consumer, such as a pricing table that's fine on nightly batches for a dashboard may need near real time updates when a quoting agent depends on it.\n- Implement quarantine gates. Validate against contracts before data enters agent accessible storage. Start with your highest risk datasets such as pricing, inventory, customer records.\n- Start with the Data Contract CLI. Bring contract governance into CI/CD, define contracts as YAML, validate automatically, block deployments on failure. Treat data contracts with the same rigor you'd give an API contract.\n- Add confidence threshold routing. When quality signals drop below a threshold, defer to a human. Start high (around 90%) and adjust downward as you build trust and track accuracy.\n\nWe've made data trustworthy. But when agents act autonomously on that data, who's watching?\n\n## Traceability and Governance: Auditing Autonomous Agents\n\nEven with perfect data, autonomous action raises a harder question, when a\nregulator asks why the agent did what it did, can you answer? Traditional\nsystems record what happened. Agentic ones have to explain why. That shift, from\n*what* to *why*, is where governance gets hard.\n\n### The audit gap\n\nPicture a bank running agentic AI for trade finance, where the governance architecture is the real innovation.\n\nAn agent processes a letter of credit. It checks KYC data, verifies the customer isn't on a sanctions list, evaluates the credit terms, and approves a $2.4 million transaction, all in about 30 seconds. Six months later, a regulator asks a simple question, “Why was this approved?”\n\nTraditional audit logs can tell you **what** happened,\nbut they can't tell you **why**.\n\nTraditional audit logs can tell you *what* happened, which tables were\nqueried, at what time, by which service account. What they can't tell you is\n*why*. Why did the agent check the sanctions list before the credit terms? Why\ndid it approve despite a minor documentation discrepancy? What alternatives did\nit consider and reject? The gap between “what” and “why” is where regulatory\nrisk arises, and the [EU AI\nAct](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)'s [Article\n12](https://artificialintelligenceact.eu/article/12/) requires high-risk systems\nto keep automatic logs for exactly this reason, so the “why” can be\nreconstructed after the fact. Closing that gap is what agentic lineage\nis for.\n\n### Agentic lineage\n\nThe way to close this audit gap is *agentic lineage*, an extension of\ntraditional data lineage. Where traditional lineage tracks which sources were\naccessed, agentic lineage tracks why the agent decided to access X, because it\nfound Y in source Z.\n\nConcretely, for the trade finance case, a single trace represents the end-to-end workflow of processing letter of credit LC-4892. Within that trace, each span is an individual step:\n\n- Span 1: retrieved customer KYC data from the compliance database, result: verified.\n- Span 2: checked the sanctions list via the OFAC API, result: clear.\n- Span 3: evaluated credit terms against the policy engine, result: within limits.\n- Final span: the decision, APPROVE, with a 94% confidence score and the full reasoning chain attached.\n\nThis is exactly what a regulator needs. Not “the\nagent accessed the compliance database at 14:32:07 UTC” but “the\nagent checked KYC first, then sanctions, then credit terms, and\napproved because all three passed.” The *traces and spans\nmodel* is borrowed directly from distributed systems\nobservability, so engineers already understand the mental model from\ntools like [Jaeger](https://www.jaegertracing.io/) and [Zipkin](https://zipkin.io/). For the agentic equivalent, [Langfuse](https://langfuse.com/), [Arize\nPhoenix](https://phoenix.arize.com/), and [OpenTelemetry](https://opentelemetry.io/)\nfor AI are the emerging choices. All three feature on the\nThoughtworks Technology Radar, OpenTelemetry at Adopt, Langfuse at\nTrial, and Arize Phoenix at Assess.\n\n### The regulatory teeth are real\n\nThis isn't a theoretical exercise. The EU AI Act is the most\nspecific regulation on the books. [Article 12](https://artificialintelligenceact.eu/article/12/) requires\nhigh-risk AI systems to automatically log events over their lifetime\nso their operation can be traced, and [Article\n19](https://artificialintelligenceact.eu/article/19/) requires\nproviders to keep those logs for at least six months. Breaching\nthese record-keeping obligations falls in the Act's middle penalty\ntier, up to €15 million or 3% of global annual turnover,\nwhichever is higher. For a large company, even 3% of global turnover\nruns into the hundreds of millions.\n\nTogether, Articles 12 and 19 translate into three obligations for your architecture:\n\n- Automatically log events across the system's lifetime, enough to trace how it operated, not just isolated timestamps.\n- Retain those logs for at least six months, which means your observability infrastructure has to handle long-term storage.\n- Be able to reconstruct the “why” after the fact. The law mandates the logs; making them answer a regulator's question is on you. That means capturing the full reasoning chain, which sources were consulted, what logic was applied, and which alternatives the agent weighed and rejected.\n\nThe EU is furthest ahead, and for now no other jurisdiction has a law quite like it. But you don't have to bet on where regulation lands to see the point. Sooner or later something will force the question of why an agent did what it did, whether that's a regulator, an auditor, a customer disputing a decision, or just your own team trying to debug one. The safe assumption isn't that a particular law is coming, it's that you'll want to answer that question regardless. A system you can't explain is one you can't fully trust, defend, or fix.\n\n### Staged autonomy\n\nKnowing you need audit trails is one thing; rolling this out safely is another. You don't deploy an agent with full autonomy on day one, any more than you'd hand a brand new employee unrestricted access. Autonomy is earned in stages:\n\n| Stage | Agent | Human | Monitoring |\n|---|---|---|---|\n| Shadow Mode | Recommends actions | Reviews recommendation and executes if appropriate | All recommendations are logged to track accuracy over time |\n| Supervised | Prepares action and waits for approval | Reviews action and approves or denies | All proposed actions and human decisions are logged |\n| Autonomous with guardrails | Agent acts within defined boundaries (best drawn by reversibility, not transaction size) | Defines guardrails | All actions logged, alerts fired on exceptions |\n| Full autonomy | Agent carries out all actions | Spot checks | Continuous, by other agents and humans |\n\nYou wouldn't give a new hire the corporate credit card on day one. They start with purchase requests, graduate to supervised spending, and eventually earn a card with limits. Agents should earn trust the same way.\n\nPromotion up this ladder should turn on evidence, not a hunch. That means testing an agent before each step, not only watching it in production. Agents are hard to test. They're nondeterministic, costly to call, and act through tools with real side effects. So teams mock or replay the tool and model interactions so tests run deterministically in CI. They score the agent's decisions with evals rather than calling live services on every run. Building that harness is a discipline of its own, and beyond the scope of this article.\n\n### Delegated access and just-in-time credentials\n\nAs agents earn autonomy, the question becomes, what permissions should they hold? Three security patterns matter most here.\n\n- Delegated Access: When Alice asks the agent to check her account, the\nagent should act\n*with Alice's permissions*, not through a broad service account that can see every customer's data. Shared service accounts destroy attribution. When a regulator asks “who accessed this customer's data?”, “the service account” tells you almost nothing. With delegated access, the answer is “Alice's agent, acting on Alice's behalf, with Alice's permissions.” - Just-in-time Credentials: Instead of a persistent API key that never\nexpires, issue a short-lived token for each specific task. The agent needs to\ncheck the sanctions list? Issue a token scoped to\n*OFAC API*read access for that specific customer, valid for five minutes. When the task completes, the token expires. No standing credentials sitting around waiting to be compromised. - Least Privilege: The agent gets the minimum access the task requires. Processing a letter of credit doesn't need reach into HR systems or marketing data.\n\nTogether, these three patterns address the attribution and scope challenges that undermine many current agentic deployments.\n\nThey also defend against the sharpest security risk in agentic systems. Simon\nWillison calls it the [lethal\ntrifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/), an agent\nturns dangerous the moment it holds all three of access to private data,\nexposure to untrusted content, and a way to communicate externally. Put those\ntogether and a single poisoned document or web page can hijack the agent through\nprompt injection and quietly exfiltrate whatever it can reach. Delegated access,\n*just-in-time* credentials, and least privilege shrink how much a hijacked agent\ncan reach, breaking the trifecta. Later we add a second cut at the same problem,\nkeeping retrieved text out of the authorisation path entirely, so that a poisoned\ndocument cannot grant a permission in the first place.\n\n### Where to start\n\nOf the four topics, this is the one where going slowly is the right instinct. But separate two things that are easy to conflate. Autonomy is earned in stages, so nobody expects you to grant it all at once. Observability is not staged at all. It goes in from day one, at full strength, whatever the autonomy level, because retrofitting it onto a running system is painful. What you build on top can stay deliberately conservative; the instrumentation underneath cannot.\n\n- Instrument from day one. Of everything here, this is the one to do\nfirst, adding observability after deployment is far harder. Every agent workflow\nshould emit traces with spans for each step, including reasoning and sources\nconsulted. The tracing pattern here is well established, so lean on a proven\ntool (like\n[OpenTelemetry](https://opentelemetry.io/)) rather than building your own. - Start in shadow mode. Lowest risk, highest learning. Agents recommend, humans decide. You build the audit trail before you need it for compliance and measure accuracy before granting autonomy.\n- Implement delegated access. Agents inherit the invoking user's\npermissions and use\n*just-in-time*credentials with short expiry windows. No persistent tokens. - Build to be explainable. Whether or not a regulator ever asks, an audit trail that answers “why” is what lets you debug a bad decision, defend a good one, and trust the system enough to widen its autonomy. Wire it in now, it's far harder to add later.\n\nSemantic layers bridge the institutional knowledge gap between agents and human analysts, building on trusted data and auditable actions provided by the earlier topics.\n\n## The Context Layer: Teaching Agents What Your Data Means\n\nSemantic layers provide the explicit context AI agents need when they become the primary consumers of data, context that human analysts carry implicitly, based on years of experience.\n\n### Your agent doesn't know what “revenue” means\n\nAsk an agent, “What was Q3 revenue for Product X?” A human analyst knows precisely what to do, which table to query, whether revenue means gross or net, what Q3 maps to in your fiscal calendar. They absorbed all of it over years of institutional knowledge, tribal docs, and Slack threads.\n\nThe agent has none of it. It doesn't know which joins connect products to orders to revenue, or that your fiscal calendar starts in February. With that context missing, it either hallucinates an answer or gives up. The semantic layer fills that gap, supplying the business-domain context.\n\n### What the context layer is\n\nA semantic layer is a set of declarative definitions of your metrics, how revenue is calculated, what an active customer is, what the numbers mean. Every consumer goes through the same definitions, so they all derive consistent, accurate results. But an agent that acts needs more than definitions of numbers. It needs to know what the things are, and what it may do to them. Those are three separate bodies of definition, and an agent needs all three.\n\nThe **domain model** says what exists. Entities, their relationships, and\nthe meaning rules of the business: an order belongs to a customer, an active\ncustomer is one who purchased in the last ninety days. It gives the agent the\nvocabulary to interpret a request and plan against it. It is consulted, never\nexecuted; no query path to data runs through it.\n\nThe **semantic model** says how the numbers are computed. Metrics and\ndimensions, one versioned formula each, compiled to the same SQL every time and\nrun against the analytical store. This is the semantic layer under a more exact\nname, and the job is to put correctness in the compiler rather than in the\nmodel's guess.\n\nThe **capability model** says what the agent may do. A curated set of\noperations against live systems, some that read (check payment status, retrieve\na troubleshooting guide) and some that write (issue a refund). Each carries\npermissions and an owner, and the acting ones carry preconditions and a\nreversibility class as well.\n\nNouns, numbers, and verbs. Together they are the **context layer**, and\nwhat unites them is not that they are all about meaning, because the capability\nmodel plainly is not. It is that each one is a place where a guarantee is\ndeclared once, in version control, instead of being worked out afresh by the\nmodel on every request. The definitions are the layer; the interface, MCP today,\nis just the door.\n\nA reader who works with dbt will object that its\n[semantic models](https://docs.getdbt.com/docs/build/about-metricflow) already declare entities, so why\nseparate the domain model out. Because entities declared inside the metrics layer\nare scoped to metrics, and the capability model has to be written in the same\nvocabulary as the semantic one or the two drift apart. A refund acts on the same\ncustomer the revenue figure counts. One vocabulary underneath, or you get two.\n\nFigure 2: The context layer: a domain model of entities and relationships, a semantic model of metrics compiled to SQL against the analytical store, and a capability model of guarded reads and actions against live systems, with provenance signals across all three. The domain model has no arrow out because it is consulted rather than executed; the other two are written in its vocabulary. Dashboards and analysts reach the semantic model; agents are the first consumer to need all three, which is the shift this article is about.\n\nAll three models are code in source control. They go through code reviews, get tested in CI, and progress through environments before reaching production. When the definition of “revenue” or the rule on refunds changes, you change it in one place and it propagates everywhere. Agents never reach the underlying data directly; they go through the context layer, which constrains and governs both what they can ask for and what they can do.\n\n### Metrics as code\n\nIn practice, the business logic lives right in the definition, ```\nrevenue =\norder_amount - discount_amount\n```\n\n, not buried in a BI tool or an ad hoc SQL view.\nThe agent receives a natural language question, and the semantic model resolves\nit to correct, constrained SQL. The agent doesn't guess table names or join\npaths; it uses the definition.\n\nThe examples here use [dbt\nMetricFlow](https://docs.getdbt.com/docs/build/about-metricflow) syntax (dbt is\nmid-migration from measures to a metrics-first spec; the widely-used form is\nshown here, and the concept holds either way). *Cube.js*, *Snowflake*, and\n*Databricks* all follow similar patterns. The tool matters less than the\ndiscipline of getting business logic into version controlled code.\n\n```\nsemantic_models:\n  - name: orders\n    model: ref('orders')\n    defaults:\n      agg_time_dimension: order_date\n    entities:\n      - name: order_id\n        type: primary\n      - name: customer_id\n        type: foreign\n    dimensions:\n      - name: order_date\n        type: time\n        type_params:\n          time_granularity: day\n    measures:\n      - name: revenue\n        agg: sum\n        expr: order_amount - discount_amount\n        create_metric: true\n```\n\n### Same question, very different SQL\n\nLet's consider an example. Ask “What was Q3 revenue for Product X?” of an agent\n*without* a semantic model, and it guesses at table names, uses the wrong\ncolumn, has no fiscal-calendar mapping, and misses the join.\n\n```\n-- Before metric definition\nSELECT SUM(amount)\n  FROM sales_data\n WHERE product = 'Product X'\n   AND quarter = 'Q3'\n```\n\nAsk the same question *with* a semantic model, and the agent is constrained\nto the correct table, the net-revenue formula from the YAML definition, the\nright fiscal-calendar dates, and the valid join path.\n\n```\n-- Constrained by metric definition\nSELECT SUM(order_amount - discount_amount)\n  FROM orders o\n  JOIN products p\n    ON o.product_id = p.id\n WHERE p.name = 'Product X'\n   AND o.order_date\n       BETWEEN '2025-07-01'\n           AND '2025-09-30'\n```\n\nThe semantic model doesn't make the agent smarter. It stops it from guessing. For an agent that acts on the answer unchecked, that's what matters.\n\n### How agents use it\n\nTake the semantic model on its own, the path a quantitative question travels. End to end, the flow looks like this. The agent sends a natural-language question (step 1). The semantic model looks up metric definitions, valid dimensions, join paths, and access rules, via MCP (step 2), then generates constrained SQL (step 3), both inside the same component. The data warehouse executes the query (step 4). The result flows back to the agent with full lineage metadata (step 5).\n\nFigure 3: One of the three paths: a quantitative question answered through the semantic model. Questions about what things are go to the domain model, and reads or actions against live systems go through the capability model.\n\nAgents pick from governed metrics, never raw tables they can misread\n\nThe semantic model constrains what the agent can ask for. dbt's, for instance, dynamically surfaces only the dimensions applicable to the selected metrics, which prevents the agent from generating plausible sounding but incorrect queries. And that lineage metadata in step 5 is the foundation for the traceability we covered earlier. Context and traceability reinforce one another.\n\n### Where to start\n\nThe temptation with a context layer is to model the whole business before you ship anything. Resist it. Start with the semantic model, because the value is concentrated in a handful of metrics, the contested ones that mean different things to different teams. Let your first agent use case set the scope, and grow the domain model and the capabilities it actually needs rather than the ones you can imagine. A narrow, correct context layer beats a sprawling, half-agreed one.\n\n- 1. Find your conflicting metric definitions. Most organizations have several definitions for their most important metrics, revenue being the classic, with its gross vs net, with or without returns variations. Those conflicts are your biggest agent risk and your quickest win.\n- 2. Pick a tool, but focus on the discipline. Any mainstream semantic layer tool will do; what matters is the discipline behind it, metric definitions in version control, one agreed definition per metric, and agents querying through the layer, not the raw schema.\n- 3. Route agents through the context layer, never the raw schema. The agent should see governed metrics and dimensions, not raw tables and joins. MCP is the common way to expose the layer today, and dbt, Cube, and AtScale all ship MCP servers, but the principle holds however you connect, the point is the abstraction, not the protocol.\n- 4. Test adversarially. The best way to find gaps is adversarial testing, every hallucination points to a missing definition. Fix the definition, not the prompt. And don't boil the ocean, start with the metrics your first agent use case needs.\n\n### Traversing the domain model: knowledge graphs\n\nThe semantic model shines for structured metric queries such as “what was revenue by region.” But some agent tasks demand richer relationship reasoning across entities, events, and time. Consider a customer who bought Product X, then churned after a pricing change. A fixed number of hops like that is an ordinary join. What flat tables handle badly is traversal whose depth you don't know when you write the query, following a chain of relationships until you find what you are looking for. That is the domain model's territory, the entities and how they connect.\n\nThe common way to store and traverse that map is a knowledge graph, which is a\nstorage choice for the domain model rather than a fourth thing to build.\n[GraphRAG](https://github.com/microsoft/graphrag) from Microsoft uses community detection to\nhandle abstract queries that traditional RAG can't, and\n[Graphiti](https://github.com/getzep/graphiti) builds temporally aware knowledge graphs\nfor evolving facts. (Both sat at *Trial* on the Thoughtworks Radar as of\n2026.) The semantic model still defines the metrics; the graph carries the\nconnections between customers, products, events, and decisions over time.\nTogether they give agents something close to institutional memory, the kind of\nknowledge that would take a new hire months to absorb.\n\nNow agents have trusted data, governance, and context. But can they actually act?\n\n## From Searchable to Actionable: Agent-Ready Data Access\n\nOnce agents understand your data and governance is in place, the question\nshifts to access. How do agents reach the data and act on it? The\nanswer is more than “RAG”. It's a full spectrum, from retrieval, to real-time\nqueries, to controlled *write-back* actions. That whole spectrum is the\ncapability model, the third of the three, and the write-back end is where its\nguardrails earn their keep.\n\n### Your agent can read, but it can't act\n\nLet's take an example. An employee reports a PO (purchase order) issue. An ideal agent would do three things, retrieve the relevant troubleshooting guide, check whether the PO payment service is down right now, and create a help desk ticket if needed.\n\nTraditional RAG, the pattern most organizations have deployed, only does step\none. It searches documents and retrieves content. It can't query a live\nmonitoring system to check service status, and it certainly can't create a\nticket in ServiceNow or Jira. That gap between *searchable* and *actionable* is\nthe subject of this final topic, and we will use the PO scenario to\nelaborate.\n\n### The data access spectrum\n\nThis framing comes from Microsoft's [Cloud\nAdoption Framework for AI](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/), which formalizes it as RAG + MCP-Read +\nMCP-Write.\n\n- Retrieval. RAG, vector search, document lookup. The agent finds relevant content. Most organizations live here today.\n- Real-Time Query. The agent queries live systems, checks service status, reads from databases in real time.\n- Write-Back. The most powerful and most dangerous tier. The agent creates tickets, updates records, triggers workflows.\n\nEach step up the spectrum adds capability, and risk. The PO scenario maps cleanly across all three.\n\n- Retrieve the guide (Retrieval)\n- Check payment status (Real-Time Query)\n- Create the ticket (Write-Back)\n\nThe shift to agentic AI requires all three, not just the retrieval most teams have built.\n\nMCP has quickly become the default way to wire these tiers up, and its rise has been remarkably fast. But the mechanism matters less than the demarcation. What counts is keeping retrieval, real-time reads, and write-back as separate, deliberately governed levels of access, whether you expose them through MCP or your own native APIs.\n\n### Three primitives, one protocol\n\nAgents reach all of this through MCP, the Model Context Protocol. Its\nprimitives sit on a risk gradient, Resources (read-only) are safe, Prompts shape\nbehavior, and Tools change state. That gradient maps straight onto the tiers,\nResources to retrieval and Tools to write-back, which is why the safe path is to\nexpose Resources first and graduate to Tools only under governance. In the PO\nscenario, Resources serve the troubleshooting docs, a Prompt guides triage, and\nTools run `check_service_status()`\n\nand `create_support_ticket()`\n\n.\n\n### Antipattern: naive API-to-MCP conversion\n\nHow you design those Tools matters as much as when you reach for them. The\ncommon, costly mistake is to take existing REST APIs and wrap them one-to-one,\nso every endpoint becomes a tool. The result is *tool sprawl*, 50 tools with\nnames like `get_po_payment_status`\n\n, `create_ticket_po_payment`\n\n,\n`create_ticket_po_payment_network`\n\n. The agent then has to choose among 50\nbarely-distinguished tools with little context, and LLMs are bad at that;\naccuracy drops sharply as the tool count climbs. The Thoughtworks Tech Radar put\n[“naive API-to-MCP\nconversion”](https://www.thoughtworks.com/radar/techniques/naive-api-to-mcp-conversion)\non *HOLD* for exactly this reason.\n\nThe better approach exposes the same functionality as a handful of\nwell-designed capabilities with rich descriptions and parameterized inputs.\n`check_service_status`\n\ntakes a service name and location, one tool for all\nservices and all locations. `create_support_ticket`\n\nis parameterized with\ncategory, priority, and description. The descriptions are detailed enough for\nthe LLM to know when to reach for each one.\n\nFive to ten well described business capabilities will outperform 50 thin API wrappers almost every time\n\nThe principle is to *design capabilities, not endpoints.* Five to ten well\ndescribed business capabilities will outperform 50 thin API wrappers almost\nevery time. And this principle is protocol-agnostic, whether an agent reaches\nyour data through MCP, through another agent, or through whatever standard comes\nnext, the properties that make it agent-ready are the same, rich descriptions,\nparameterized access, clear schemas.\n\n### What a capability declares\n\nA rich description tells the agent when to reach for a capability. It says\nnothing about whether the agent is allowed to, or what happens if it is wrong.\nThat is the rest of the declaration. Every capability carries\n**permissions**, who may invoke it and acting as whom, and an **owner**,\nthe person accountable when it misbehaves. The ones that act carry two more.\n\n**Preconditions** are the conditions that must hold before the action may\nproceed, checked against live state at the moment of acting rather than against\nwhatever the agent read earlier in its plan. A refund needs an original payment,\nnot yet refunded, within the amount the invoking user may authorise.\n\n**Reversibility** is the class of damage the action can do: cleanly\nreversible, reversible at a cost through some compensating transaction, or\nirreversible. This is the more useful predictor of safe autonomy than the money\ninvolved. A $50,000 internal ledger correction you can back out is a safer thing\nto automate than a $200 payment to an external account you cannot claw back. Where\nthe staged autonomy ladder earlier keys its guardrails to transaction size, prefer\nkeying them to reversibility, and let irreversible actions require human approval\nwhatever stage the agent has reached.\n\nReversibility predicts safe autonomy better than the size of the transaction\n\nWhich raises the question of where the rules in those preconditions come from, because most of them are written down in prose somewhere, in a refund policy, a contract, a compliance manual.\n\n### Retrieved text informs, it never gates\n\nBusiness documents remain where the business writes its rules down. But a rule that gates an action must not be read and interpreted at the moment of acting. Rules are extracted from those documents ahead of time, curated by a human, and stored as declared preconditions in the capability model, each with a link back to the passage it came from.\n\nAt action time the agent may still read unstructured content, a complaint\nticket, a contract clause, to work out what to propose. Only the declared rules\ndecide what is permitted, and they are checked deterministically against live\nstate. The boundary is between *informing* and *gating*. Retrieved text\ncan shape what the agent suggests and serve as evidence for a human approver, but\nit never carries the authority to authorise the action itself.\n\nThat boundary is also a security property. Removing retrieved text from the authorisation path means a poisoned document cannot grant an agent a permission it did not already have, which is a stronger claim than merely shrinking what a hijacked agent can reach. It is not a complete defence, because injected text can still influence what the agent proposes, and a human approver shown fabricated evidence may wave it through. What it removes is the path where the document authorises the action directly, with nobody in between.\n\nThe provenance link is what keeps the declarations honest as the documents move underneath them. Be careful what you promise here. 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 you is a review queue, the derived rules flagged for a human to re-check when their source moves, 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.\n\nWhere no declaration covers the situation, the agent does not improvise from its own reading of policy. It escalates. This is the hard gate from earlier in a different setting, the same instinct that says any contract or SLA breach forces a human rather than a lower score. An undeclared case degrades the agent to supervised, not to autonomous.\n\nExtraction and curation is a pipeline like any other, and it needs an owner, a cadence, and somebody who clears the review queue. Which is the subject of a later section, because none of this maintains itself.\n\n### End to end: the PO payment scenario\n\nWith all three tiers in place, the PO issue we opened the section with runs end to end, the agent retrieves the troubleshooting guide (a read-only Resource), checks the live payment status (a Tool that reads), and files a ticket (a Tool that writes), all in a single workflow.\n\nFigure 4: One agent, three tiers: retrieval, real-time query, then write-back, combined into a single response.\n\nDone 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 agent is now able to do all this in one pass.\n\n### Where to start\n\nThe safe way in is to climb the tiers, not leap to write-back. Most teams already live in retrieval, the read-only tier where risk is lowest. Write-back is where the real danger sits. So earn your way up. Map what each use case needs, expose read-only access first, and add write-back last, only once you can log every action. Don't let the thrill of an agent that can act rush you past the steps that make acting safe.\n\n- 1. Map your data access tiers. Take your top three agent use cases and classify what each needs, retrieval, real-time query, or write-back. Most gaps live in real-time query and write-back.\n- 2. Design capabilities, not endpoints. Group existing APIs into 5–10 well-described business capabilities. Rich descriptions matter, they're what the LLM uses to decide which tool to call.\n- 3. Start with MCP Resources. Read-only access is the lowest risk entry point. Expose knowledge bases, config data, and documentation as Resources. Graduate to Tools only once governance is in place.\n- 4. Instrument from day one. Before deploying any agent with write access, log every tool invocation, who triggered it, what was called, when, and critically, on whose behalf. This feeds the audit trail from the Traceability and Governance section.\n\n## The AI-ready data stack\n\nWe've now walked through all four topics, contracts that make data trusted, a context layer that makes it meaningful and actionable, access patterns that let agents act on it, and observability that makes those actions auditable. Treated separately, they look like four work streams you could staff independently. But they aren't independent. They build on one another, and the order in which they're built matters.\n\nFigure 5: The AI-ready data stack: three dependent layers built bottom-up, with observability cutting across all of them from day one.\n\nThe dependencies run bottom-up. You can't attach meaning to data you can't trust, so context sits on the foundation. You can't safely let agents act without that meaning to constrain them, so access sits on context. Skip either of those and everything above it collapses. 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. 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 whenever you get around to instrumenting it. It is also much harder to retrofit onto a running system than to build in from the start. Either way, you wire it in from day one.\n\n## Who owns all this?\n\nThe stack has one more dependency the diagram can't draw. Every layer in it produces an artifact that has to be kept true, a data contract, a metric definition, an access scope, an observability trace. Artifacts don't maintain themselves. A contract with no owner drifts out of sync with the source it describes. A definition of “revenue” with no owner forks back into the three conflicting versions you just consolidated. An access scope with no owner quietly widens until it's a standing service account again. The technology is necessary, but it's the operating model that keeps it honest.\n\nThe discipline that makes this work is treating [data as a product](https://martinfowler.com/articles/data-mesh-principles.html#DataAsAProduct). Each\ndataset, contract, and metric has a named owner, a published contract and SLA,\nand a versioned lifecycle, the same way an API does. You won't always know every\nconsumer, and for public or broadly shared data you can't, which is precisely\nwhy the contract matters, it's the stable promise unknown consumers build on,\nand a deprecation policy is how you change it without breaking them. When the\n`product_pricing`\n\ncontract blocks a deployment at 2 a.m., someone is accountable\nfor it. When finance and sales disagree on “revenue,” someone owns the decision.\nWhen a new agent asks for access, someone owns the scope and reviews it. These\naren't infrastructure questions; they're ownership questions, and no tool\nanswers them for you.\n\nA 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. The faster and more autonomous your consumers, the less you can afford data without an owner.\n\n## Where do you stand?\n\nBefore deciding what to build, it helps to locate yourself. Score each attribute against the signals below, all drawn from the topics above.\n\n| Attribute | Human-era | In Transition | Agent-ready |\n|---|---|---|---|\n| Trusted | Loose schemas, no freshness SLAs; quality rests on an analyst noticing when a number looks off | Contracts on a few critical datasets; quality checked but not enforced in CI/CD. | Contracts enforced as code, freshness SLAs per consumer, quarantine before agent storage, agents read Gold only (tables and embeddings) |\n| Contextual | Metric definitions live in BI tools, SQL, and people's heads; humans supply the context | Some metrics defined as code, but definitions still conflict and agents may still hit the raw schema | A context layer in Git: entities and relationships in a domain model, one semantic definition per metric, and a curated set of capabilities; agents route through it, never the raw schema |\n| Traceable | Logs show what a person queried and when; the why lives in the analyst's head | Traces on some agent workflows; reasoning captured inconsistently | Every agent workflow emits traces with spans, reasoning, and sources; any decision's “why” is reconstructable |\n| Governed | People access data through their own roles; systems share broad service accounts | Agents run on scoped but long-lived, coarse credentials | Delegated per-user access, just-in-time credentials, least privilege; lethal-trifecta paths closed |\n| Operational | No agent acts on the data; people read dashboards and take actions by hand | Agents retrieve via RAG; real-time reads emerging; write-back experimental or ungoverned | All three tiers via well-designed capabilities; write-back gated by staged autonomy and instrumentation |\n\nDon't average the rows, because the stack is dependency ordered, your readiness is capped by your weakest foundational layer, a flawless context layer sitting on untrusted data is still not agent ready. Find your weakest row, and that's where the next investment goes.\n\n## Four things to start on\n\nEach topic came with its own starting points. Treat those as tactical checklists for the work itself. The four below are where to start. The first, instrumenting from day one, isn't a build-order step. It runs alongside everything else, which is why it comes first and never stops. The other three build from the bottom of the stack up, because you're only as ready as your weakest foundational layer. The highest-leverage single move among them is the context layer, since context moves accuracy further than a bigger model does, but it only pays off once the data beneath it can be trusted. Build up to it.\n\n- Instrument from day one. This isn't a step in the sequence so much as a constant that runs under all of them. Put traces and spans in every workflow from the start, because observability is far harder to retrofit than to build in, and you'll want audit trails that answer “why” for debugging today and regulators tomorrow.\n- Contract everything. Freshness SLAs, strict schema enforcement, quarantine for bad data. This is the floor the rest stands on, agents can't smell bad data, so the data architecture has to smell it for them.\n- Context over models. Once the data can be trusted, a context layer\nis the highest-return thing you can build on top of it. Its semantic model\nalone carries the point: in\n[AtScale's text-to-SQL benchmark](https://atscale.com/blog/public-leaderboard-text-to-sql-tasks/), accuracy jumped from under 20% on the raw schema to over 92.5% with a semantic layer, on the*same model*. - Read before write. Start with MCP Resources (read-only) and graduate to Tools (write) only with governance in place. Earn autonomy in stages, shadow mode, then supervised, then autonomous with guardrails.\n\nWhen agents become the primary consumers of your data, your data architecture\n*becomes* your AI architecture.\n\nWe go much deeper on all of this, and on the broader operational and\nanalytical data architecture decisions around it, in our forthcoming O'Reilly\nbook, [Data Architecture for Software\nArchitects](https://www.oreilly.com/library/view/data-architecture-for/9781098181185/).\n\n## Acknowledgments\n\nThanks to Martin Fowler for encouraging to write about this topic based on a series of talks we gave at multiple conferences, we would also like to thank Rebecca Parsons, Kevin Hartman, Paul Hammant, Arun Srinivasan, Swapnil Phulse, Brian Smith, Ramanathan Santhanam, Cameron Casher and Mark Taylor for giving us a through review and actionable comments to improve the article\n\nLike most things in the industry, we used AI assistance to help research, organize, and format some parts of our writing.\n\n## Significant Revisions\n\n*27 August 2026: *published", "url": "https://wpnews.pro/news/making-your-data-ready-for-agentic-ai", "canonical_source": "https://martinfowler.com/articles/making-data-ready-for-agentic-ai.html", "published_at": "2026-08-28 10:15:31+00:00", "updated_at": "2026-08-28 10:48:53.410601+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure", "ai-safety", "ai-policy"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/making-your-data-ready-for-agentic-ai", "markdown": "https://wpnews.pro/news/making-your-data-ready-for-agentic-ai.md", "text": "https://wpnews.pro/news/making-your-data-ready-for-agentic-ai.txt", "jsonld": "https://wpnews.pro/news/making-your-data-ready-for-agentic-ai.jsonld"}}