翻訳待ち：Making Your Data Ready for Agentic AI

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

Making Your Data Ready for Agentic AI For thirty years we built data systems for human analysts, who supply the context, judgment, and skepticism to work around data that's incomplete or wrong. Autonomous agents supply none of that. They act on whatever they're handed, confidently. For data to be AI-ready we need to build a series of layers: a data foundation that makes data trusted, a context layer to apply proper meaning, and an access layer that supports and controls how agents operate on that data. While doing this we need continuous attention to observability that ensures the data is properly governed and we have an auditable trace of its use in decision-making. 27 August 2026 Pramod Sadalage Pramod is a Distinguished Engineer at Thoughtworks leading the Data Engineering and Architecture service for North America, where he helps clients with particularly challenging data needs, which require new technologies and techniques. In the early 00’s he developed techniques to allow relational databases to be designed in an evolutionary manner based on version-controlled schema migrations. He has been an author on five books on software development, including “Software Architecture: The Hard Parts” and “Refactoring Databases” Prem Chandrasekaran Premanand (Prem) Chandrasekaran is a Market Tech Director at Thoughtworks, where he leads technology strategy and delivery across a portfolio of clients and guides teams through complex, high-stakes engineering decisions. He stays deliberately hands-on, designing and building production-grade systems alongside the teams he leads. His current focus is on how AI can augment the software development lifecycle, from architecture and design to coding, testing, and operations, so that developers can move faster without sacrificing clarity, safety, or maintainability. enterprise architecture data analytics generative AI Contents The consumers of your data are changing What “AI-ready” has to mean now Data Contracts and Quality: Agents Can't Smell Bad Data Agents treat every value as truth Schema is law: data contracts as code The quarantine pattern Medallion architecture for agents The same rules for unstructured data Confidence-threshold routing Where to start Traceability and Governance: Auditing Autonomous Agents The audit gap Agentic lineage The regulatory teeth are real Staged autonomy Delegated access and just-in-time credentials Where to start The Context Layer: Teaching Agents What Your Data Means Your agent doesn't know what “revenue” means What the context layer is Metrics as code Same question, very different SQL How agents use it Where to start Traversing the domain model: knowledge graphs From Searchable to Actionable: Agent-Ready Data Access Your agent can read, but it can't act The data access spectrum Three primitives, one protocol Antipattern: naive API-to-MCP conversion What a capability declares Retrieved text informs, it never gates End to end: the PO payment scenario Where to start The AI-ready data stack Who owns all this? Where do you stand? Four things to start on Sidebars Explainer: the words people use for semantic layers There'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. We'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. The consumers of your data are changing For 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. A 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. A human hesitates at data that looks wrong; an agent acts on it anyway Agents 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. What “AI-ready” has to mean now For a human consumer, the data only had to be good enough; the analyst did the rest. The meaning, the sanity check, and the judgment about whether a number could be trusted all lived in a person's head. When the same data is handed to an agent, every bit of that implicit labor has to move into the data itself. That shows up as five attributes, each the flip side of something a human used to do for free. 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. 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. 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. 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. Operational: a person reads a dashboard and then goes and does something; an agent has to be able to do the something. The data can't just be readable, it has to be actionable. All 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. None of these attributes builds itself. The rest of the article works through four topics that do, roughly in the order you should tackle them. Data Contracts and Quality makes data Trusted. We start here, because a single wrong fact poisons every layer built on top of it. Traceability and Governance records why an agent acted and bounds what it can reach, making data Traceable and Governed. The context layer encodes what your metrics and entities mean, making data Contextual. From Searchable to Actionable lets agents query live systems and write back, making data Operational. We'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. Data Contracts and Quality: Agents Can't Smell Bad Data Humans have a smell test for bad data. They notice when a number looks off, when a date makes no sense, or when a price seems wrong. Agents have no such instinct. As Simon Willison puts it, language models are gullible, they believe whatever they are handed and act on it. Feed an AI agent a wrong value, and it won't pause to wonder, it will use the number and produce a confident, wrong answer. Without trusted data, nothing else in agentic AI works, so this is where we begin. Agents treat every value as truth Consider a concrete scenario. A pricing agent is asked for the current price of Product X. Yesterday, the price was updated from $49.99 to $59.99. But the agent's data source hasn't refreshed, it still shows the old number. The agent doesn't hesitate, it retrieves $49.99, quotes the customer, the customer buys, and the company loses $10 on every unit sold. Every step the agent took was technically correct. It followed its workflow perfectly. The data it accessed was the problem. The leaders most confident their data is AI-ready also name data readiness their biggest barrier A human sales rep would have paused: “Wait, didn't we update this last week?” They'd double-check. They have institutional memory and a feel for when something's off. The agent has neither. Errors don't trigger warnings; they cascade silently through the workflow. And this isn't a rare edge case. In the 2026 State of Data Integrity and AI Readiness report, Precisely and Drexel University's LeBow College of Business surveyed 505 data and analytics leaders, of whom 87% believed their data was ready for AI, yet 43% named data readiness as the single biggest barrier to getting value from it. That gap between confidence and readiness is the organization-level version of the pricing agent, sure of itself and wrong. A separate KPMG Global AI Pulse survey of 2,145 leaders points the same way, with nearly half of executives now seeing AI's costs exceed its benefits. Most enterprises are one stale field away from the scenario above. Schema is law: data contracts as code So how do you prevent AI agents from accessing bad or stale data? The answer is data contracts, treating schema as law, not a polite suggestion. This reverses a decade of “schemaless is flexible” thinking, for human consumers, loose schemas are merely inconvenient, while for AI agents, they're dangerous. A data contract, written in the Open Data Contract Standard, the format the Data Contract CLI uses (and recommended in Thoughtworks tech radar 33), defines the rules explicitly. A product_pricing contract might specify: Properties with strict logical types. A quality rule that price must be greater than zero. A quality check on currency that rejects anything outside USD, EUR, or GBP. Critically, a freshness SLA, pricing data must have been refreshed within the last 24 hours. In the Open Data Contract Standard, that contract is shown below. apiVersion: v3.1.0 kind: DataContract id: product-pricing name: Product Pricing version: 1.0.0 status: active schema: - name: product_pricing physicalType: table properties: - name: product_id logicalType: string physicalType: varchar(64) required: true unique: true primaryKey: true primaryKeyPosition: 1 - name: price logicalType: number physicalType: decimal required: true quality: - type: sql description: Every price must be greater than zero query: SELECT min({property}) FROM {object} mustBeGreaterThan: 0 - name: currency logicalType: string physicalType: varchar(3) required: true quality: - type: sql description: Currency must be a supported ISO code query: SELECT count(*) FROM {object} WHERE {property} NOT IN ('USD', 'EUR', 'GBP') mustBe: 0 - name: ingested_at logicalType: timestamp physicalType: timestamp required: true slaProperties: # the rule that would have caught the stale-price scenario - property: latency value: 24 unit: h element: product_pricing.ingested_at Enforcement happens along three dimensions. Schema enforcement ensures types and constraints are respected and made explicit by the contract. 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' [truncated for AI cost control]