Making Your Data Ready for Agentic AI

Your Data Has a New Consumer

For more than thirty years, data systems were built for human analysts. Dashboards, reports, and ad-hoc queries all assume a person sits in front of a screen, supplying the context, judgment, and skepticism needed to work around incompleteness or errors. Humans know what “revenue” means in your organization, which tables to avoid, and when a figure looks suspiciously off. But you are about to hand those systems to a very different consumer: autonomous agents that supply none of that. An agent does not hesitate at data that looks wrong—it acts on it confidently.

That behavioral gap defines what “AI-ready” means now. For a human, data only has to be good enough; the analyst does the rest internally. For an agent, every bit of that implicit labor must move into the data itself. That manifests as five attributes, each the flip side of what humans used to do for free:

• Trusted: Data must be accurate, fresh, and validated before an agent sees it, because an agent acts where a person would pause.
• Contextual: Meaning in someone's head has to be explicit. If “revenue” already excludes returns, or your fiscal year starts in February, the data must say so.
• Traceable: When a person decides, they can explain why later. An agent's reasoning vanishes unless you capture it at runtime.
• Governed: A person's access is bounded by role and judgment; an agent's access must be bounded by design—scoped, controlled, and auditable.
• Operational: A person reads a dashboard, then acts. An agent must be able to act, meaning data must be writeable, not just readable.

None of these attributes builds itself. The work falls into four engineering topics, tackled roughly in order: data contracts and quality first, because a single wrong fact poisons everything above it; then traceability and governance; then a context layer; finally, an access layer that makes data actionable.

Data Contracts and Quality: Agents Can't Smell Bad Data

A human analyst instinctively knows when a total is suspiciously round, a date falls on a holiday, or a price is too low. An agent has no such instinct—it treats every value it receives as truth. That makes schema and validation your first line of defense.

Schema Is Law

Treat data contracts as code. Define the schema, validation rules, and quality checks for data sets as version-controlled contracts that both producer and consumer must comply with. Any change to the contract—a new field, a tightened constraint—should require explicit versioning, not silent mutation. If a producer violates the contract, the data should be rejected or quarantined, never silently passed to an agent.

The Quarantine Pattern

When data fails contract validation, route it to a quarantine zone rather than blocking the pipeline or dropping it entirely. This preserves the raw payload for debugging while keeping bad data away from agents. Quarantined data can be inspected, repaired, and replayed; the pattern prevents the common failure mode where validation errors are lost in logs while downstream systems act on stale or partial data.

Medallion Architecture for Agents

The bronze-silver-gold medallion pattern maps well to agentic workloads. Bronze holds raw, unvalidated data; silver applies contracts and quality checks; gold produces the curated, business-ready data that agents consume. Agents should be pointed at gold, not bronze or silver, so they never encounter the inconsistencies in raw data that data engineers work around daily.

The same rules apply to unstructured data. If your agent reads documents, validate them too: check freshness, authenticity, format, and completeness before allowing them into an agent's context. Apply text-based contract checks—maximum age, required metadata, source whitelist—and quarantine anything that fails.

Confidence-Threshold Routing

Not all data is equally reliable, and an agent does not know the difference. Before data reaches an agent, apply a confidence score rather than simply routing everything through a retrieval step. Responses falling below a threshold should not be delivered as answers; either segment results, label them as low-confidence, or escalate to a fallback process. Retrieval should never feel like the end of the pipeline.

Where to Start

Begin with your highest-impact data sets—customers, orders, products—and write contracts for those first. Pick one data domain, instrument it, measure how often contracts are violated, and use that metric to decide whether to expand the practice. See what breaks your agents, feed those failures back into your contracts, and iterate.

Traceability and Governance: Auditing Autonomous Agents

When an agent acts on your data, the reasoning behind that action lives for the duration of a context window and then disappears. Organizations are not prepared for how much of their decision-making will become undocumented by default.

Agentic Lineage

Start by treating agent activity as data you collect and store. Log every tool call, every data read, every prompt and completion, and every decision an agent makes—in a format you can query later. Build this as an event stream, not an application log, so audits become possible. Agentic lineage is not just about what data fed an answer, but about why the agent chose that data path and what alternatives it considered.

Staged Autonomy

Do not give every agent the same latitude. Define staged autonomy levels: level one agents observe and suggest, level two act with human approval, level three act within tight constraints, and level four act autonomously within a defined window. Data access rules differ per stage, and safeguards expand as confidence grows. An agent that can read an expense report should not automatically be permitted to approve a purchase order.

Delegated Access and Just-in-Time Credentials

Agents should never hold standing credentials to your entire warehouse. Set them up to request just-in-time, scoped access for specific tasks, with short-lived credentials tied to the agent's current purpose. If an agent needs to read customer data for one job, grant that read access for the duration of the job only. Broader role-based access for agents defeats the point of control; every escalation should be explicit and logged.

The regulatory pressure here is real and mounting. The longer autonomous decisions flow through your enterprise without an audit trail, the fewer options you will have when a regulator asks you to explain a specific action. Start treating this as a compliance requirement today, not a design elegance.

Where to Start

Enable logging on your agent infrastructure now, even before you have the tooling to query it fully. You cannot retroactively create traceability; you can only capture it at the moment the action occurs. Then build your staged autonomy model next, based on your highest-risk data processes.

The Context Layer: Teaching Agents What Your Data Means

Suppose two different users ask your agent for last year's revenue—one from finance, one from the business development team. Finance means recognized revenue in the fiscal calendar; business development means gross booked sales in the calendar year. Your data team knows this. An agent does not.

What the Context Layer Is

Code exists between raw tables and the metrics an agent uses, and it has to encode what every metric means. This layer defines measures, dimensions, relationships, and the business rules that transform raw fields into shared vocabulary. Treat metrics as code, stored in version control, reviewed, and deployed like any other service. Humans have a semantic layer in their heads; agents need an externalized one.

A simple specification captures the essentials: each metric has formula, aggregation, filters, applicable time dimensions, and business ownership. Whether you model this in a metrics store, a semantic layer tool, or a well-structured lookup set depends on your stack—the principle stays identical. You are making the implicit explicit.

Many Questions, One Metric

The same human question generates very different SQL depending on the source system. Bookings may live in one table, revenue in another, invoiced revenue in a third. A context layer resolves those ambiguities before an agent ever generates a query. It also prevents catastrophic cross-filters: a finance user querying revenue should not accidentally get un-invoiced pipeline data because the tool found a matching column name.

Knowledge Graphs for Domain Traversal

Beyond metric definitions, a knowledge graph of your data landscape helps agents navigate relationships between entities, systems, and teams. The graph describes what systems exist, what concepts they own, and how they relate. When an agent needs to determine the “net new ARR,” the graph helps it identify which product systems roll up to that definition and what the correct join paths are. This replaces an analyst's memory of which tables are reliable with a machine-readable map.

Where to Start

Do not attempt a federation-wide semantic standard in one pass. Choose the ten metrics your agents use most often and see which ones your business stakeholders disagree on. Document those two or three controversial metrics precisely, create a spec, and iterate. Whatever short-term debates this exposes are exactly the ones that will otherwise poison your agents at scale.

From Searchable to Actionable: Agent-Ready Data Access

Retrieval is table stakes. Your agent still needs to operate—to update a record, request an approval, initiate a workflow. Traditional data access patterns do not support that.

The Data Access Spectrum

Data access falls on a spectrum. Read-only, batch-friendly access works for analysis; live system queries require real-time, permission-aware endpoints between warehouse abstractions and actual system operations. Write access is fundamentally different—a query returning rows is, but a query updating a sales order changes corporate state. Every step rightward on this spectrum raises risk and requires more control.

Capabilities, Not APIs

For write access, give agents capabilities, not just API endpoints. A capability declares what an action accomplishes at the business level—such as “approve purchase order up to $5,000” rather than “POST /PO/approve/{id}.” Capabilities carry metadata: who can perform them, under what conditions, with what limits. Expose them over a single protocol where discoverable metadata answers what an agent can do before the agent attempts it.

The naive approach—auto-converting your existing REST APIs to webhooks and calling it done—does not work. Webhooks reveal endpoint names and schemas but not the semantics of what an operation does, what entitlements it requires, or its consequences. A capability description must state the business outcome, intent it fulfills, and conditions under which it should be invoked. Present clearly what will change in the system and who you will notify. If an inventory agent deploys a markdown, the capability should surface that the action would affect a product's list price globally.

Retrieved Text Does Not Gate Actions

A dangerous pattern is to have a retrieval step like RAG return text instructing an agent whether an action is permissible. Retrieved instructions feel relevant, but they are not security boundaries. You never want your policy enforcement to be phrased in human language pulled out of a document, because the model will follow both what it says and what it implies. Enforce capability access programmatically and deterministically—outside the inference path. Retrieved context informs; it must never decide.

The AI-Ready Data Stack and What Comes First

Work through the layers in order. Start with a data foundation with contracts and validation. Add the traceability and governance layer, covering your agent access and observability. Build the context layer for business semantics, then open read-and-write access to your agent operations. Your stack will be a collection of layers that enforce the five attributes anywhere the data moves.

You must also assign responsibility. Data engineers who have worked on internal datasets have to become product engineers for agents to operate without human hand-holding.

Four actions to start with:

1. Pick one high-value data domain and publish contracts for it within the next two weeks. See how often producers violate them.
2. Turn on full logging for any agent you have in production today, even before you decide how to store or query it.
3. Choose five metrics your agents need and write semantic definitions for at least two of them, simply and pragmatically in a document.
4. Interview the owners of your most labor-intensive read-and-write process about which five future tasks they would most trust an agent to perform, and how you would want visibility into it.

Each of these moves data into contexts where an agent can consume, trust, and act upon it. Data built with the gap between human and machine judgment in mind converts the five attributes from aspirations into engineered properties of your infrastructure. Begin with quality and governance, apply context and access, and audit everything in between.

Agents Can't Smell Stale Data: Contracts and Quarantine Gates

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. This is the core challenge of making data ready for agentic AI.

Consider a pricing agent asked for the current price of a product that was updated yesterday from $49.99 to $59.99. If the agent's data source hasn't refreshed, it retrieves $49.99, quotes the customer, the customer buys, and the company loses $10 per unit. Every step the agent took was technically correct. The data it accessed was the problem.

A human rep would have paused and double-checked, drawing on institutional memory. Agents have neither. Errors don't trigger warnings; they cascade silently through workflows. This is not 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 value from it. A separate KPMG Global AI Pulse survey of 2,145 leaders points the same way, with nearly half of executives seeing AI's costs exceed its benefits.

Schema as Law, Not Suggestion

Reversing a decade of "schemaless is flexible" thinking, data contracts treat schema as law. For humans, loose schemas are inconvenient; for AI agents, they're dangerous. A data contract written in the Open Data Contract Standard — the format the Data Contract CLI uses, recommended in Thoughtworks tech radar 33 — defines rules explicitly. A product_pricing contract might specify properties with strict logical types, a quality rule that price must be greater than zero, a check on currency rejecting anything outside USD, EUR, or GBP, and critically, a freshness SLA requiring pricing data refreshed within the last 24 hours.

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 explicit.
• Freshness SLAs define maximum acceptable staleness per dataset. Key the SLA to when data was last successfully loaded, not when a value last changed — steady data shouldn't be flagged stale, but a stalled pipeline can't masquerade as fresh.
• Quality gates validate contracts in CI/CD, blocking deployments when they fail.

This prevents the pricing failure by design: if pricing data hasn't refreshed in 24 hours, the contract is violated before the agent ever sees the data.

The Quarantine Pattern

When data violates a contract, you need a circuit breaker. The quarantine pattern works as follows: raw data arrives from source systems (APIs, databases, streams). Before entering agent-accessible storage, it passes through a contract validation gate checking three things: schema conformance, freshness SLA, and quality rules. If it passes all three, it flows into the certified agent-ready tier. If any check fails, it's routed to a dead-letter queue for human review, with alerts fired.

The agent never sees the bad data. In the pricing scenario, if the ingested_at timestamp is older than 24 hours, the record is quarantined — the agent says "I don't have current pricing data" rather than confidently quoting the wrong number. That's a far better failure mode, and it's a job for the data architecture, not the model.

Medallion Architecture, Extended for Agents

The medallion architecture organizes data in a lakehouse, popularized by Databricks. Its first three tiers are well established:

• Bronze: raw, immutable ingestion. Everything is kept for audit trail and lineage.
• Silver: validated and deduplicated. Schema is applied, contracts enforced, and the quarantine pattern lives here.
• Gold: certified. The semantic model compiles against it, access is governed, metrics are trusted.

For agentic architectures, a fourth tier is worth adding. In Adaptive Gold, agents curate data rather than only consuming it, materializing combinations they keep reaching for based on real query patterns. This isn't speculative: at DataHub's CONTEXT 2025 summit, Apple described agents acting as "digital stewards" of its data catalog, continuously scanning metadata and proposing updates. Apple's agents curate the catalog; Adaptive Gold points the same pattern at the datasets.

The key architectural principle: 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.

Unstructured Data Needs the Same Rules

Most of what agents consume isn't tabular. Documents, wikis, PDFs, and support tickets get chunked and embedded into vector stores, and if your agents do RAG, that's the data they run on. The stale-price scenario has a twin: a policy document updates, but the vector index isn't re-embedded, so the agent retrieves the old version and answers confidently. The freshness SLA carries over, but be precise about what the clock measures: not when content last changed, but when the index was last successfully rebuilt. A 24-hour SLA means the re-indexing job must have completed in the last 24 hours — a silently failed indexer is exactly when you can't tell whether something changed.

Contracts move from content to surrounding metadata. You can't constrain prose, but you can require every chunk to carry a source, a version, a timestamp, and an access scope, rejecting anything that doesn't. That metadata makes retrieval traceable and governable. Quality gates get text-suited checks: reject empty or truncated chunks, catch near-duplicate documents, flag failed extractions and OCR garbage, and watch for embedding drift. A malformed or empty embedding warps similarity search, so it never reaches the store — for the same reason a bad price never reaches the agent.

Confidence-Threshold Routing for the Gray Zone

Contracts, quarantine, and medallion tiers handle clear cases. For data that isn't clearly bad but isn't fully trustworthy either, confidence-threshold routing bridges full autonomy and full human control. The agent assesses not just model confidence but data-level signals: freshness, completeness, consistency. At or above the threshold — say 85% — the agent proceeds autonomously. Below it, the agent defers to a human. The threshold is configurable per use case: pricing might demand 90%, while an internal FAQ is fine at 70%.

Return to the pricing scenario: the data is three days stale, the SLA says 24 hours. The SLA violation drives the confidence score below threshold regardless of how confident the model itself feels. The agent pulls in a human: "I'm not confident this price is current. Routing to a human for verification." Data quality signals should drive the threshold, not just the model's own confidence.

Turning quality signals into a single score weighed against model confidence is an open design problem. Start with a hard gate rather than a smooth composite: any contract or SLA breach forces a human. Add weighted scoring later, only once you can show it beats that simple rule.

Where to Start

These practices are additive, each lowering risk on its own. Begin with the highest-leverage moves:

1. Define freshness SLAs for every dataset agents touch. The same dataset can have different requirements per consumer — a pricing table fine on nightly batches for a dashboard may need near-real-time updates for a quoting agent.
2. Implement quarantine gates. Validate against contracts before data enters agent-accessible storage, starting with highest-risk datasets: pricing, inventory, customer records.
3. Start with the Data Contract CLI. Bring governance into CI/CD, define contracts as YAML, validate automatically, block deployments on failure. Treat data contracts with the same rigor as API contracts.
4. 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.

Data is now trustworthy. But when agents act autonomously on it, who's watching?

From “What” to “Why”: Auditing Agents That Act

Even with a foundation of trusted, governed data, autonomous action poses a more uncomfortable question: if a regulator asks why an agent did what it did, can your organization answer? Conventional systems log what happened; agentic systems must explain why. That shift from what to why is the crux of governance.

The Audit Gap in Practice

Consider a bank running agentic AI for trade finance. An agent processes a letter of credit: it checks KYC data, verifies the customer against a sanctions list, evaluates credit terms, and approves a $2.4 million transaction in roughly 30 seconds. Six months later, a regulator asks one simple question: why was this approved?

Traditional audit logs capture exactly what happened—which tables were queried, at what time, by which service account. They cannot capture why: why check sanctions before credit terms, why approve despite a minor documentation discrepancy, or what alternatives the agent weighed and rejected. The gap between “what” and “why” is the heart of regulatory exposure. The EU AI Act’s Article 12 explicitly requires high-risk systems to keep automatic logs so that the “why” can be reconstructed after the fact. That requirement is what agentic lineage addresses.

Agentic Lineage: Traces as Evidence

Traditional data lineage tracks which sources were accessed. Agentic lineage extends that to track why an agent decided to access source X because it found Y in source Z. The traces and spans model from distributed systems observability—familiar from tools like Jaeger and Zipkin—maps cleanly onto agent workflows.

For the trade finance case, a single trace represents the end-to-end workflow handling letter of credit LC-4892. Each span is an individual step:

• Span 1: Retrieved customer KYC data from the compliance database; result: verified.
• Span 2: Checked the sanctions list via the OFAC API; result: clear.
• Span 3: Evaluated credit terms against the policy engine; result: within limits.
• Final span: Decision APPROVE, with a 94% confidence score and the full reasoning chain attached.

This is exactly what a regulator needs: not “the agent accessed the compliance database at 14:32:07 UTC” but “the agent checked KYC first, then sanctions, then credit terms, and approved because all three passed.” Emerging tools for the agentic equivalent include Langfuse, Arize Phoenix, and OpenTelemetry for AI, all featured on the Thoughtworks Technology Radar.

Regulatory Teeth Are Real

The EU AI Act is not theoretical. Article 12 demands automatic event logging over a high-risk system’s lifetime so its operation can be traced. Article 19 requires providers to retain those logs for at least six months. Breaching these record-keeping obligations falls in the Act’s middle penalty tier: up to €15 million or 3% of global annual turnover, whichever is higher. For a large company, that reaches into the hundreds of millions.

Together, Articles 12 and 19 translate into three architectural obligations:

• Automatic logging across the system’s lifetime, enough to trace how it operated, not just isolated timestamps.
• Log retention for at least six months, which pushes long-term storage requirements onto your observability infrastructure.
• Reconstructing the “why” after the fact. The law mandates the logs; making them answer a regulator’s question is on you. That requires capturing the full reasoning chain, which sources were consulted, what logic applied, and which alternatives the agent rejected.

The EU leads this space; no other jurisdiction has an exactly equivalent law. But you need not bet on where regulation lands to see the point. A regulator, auditor, customer disputing a decision, or your own debug session will eventually force the question of why an agent acted as it did. The safe assumption is not that a specific law is coming, but that you will want to answer the question regardless. A system you can’t explain is a system you can’t fully trust, defend, or fix.

Staged Autonomy

Even with solid audit trails in place, deploying full autonomous agents on day one is unwise. You wouldn’t hand a brand new employee unrestricted access, or the corporate credit card on their first day. They start with purchase requests, graduate to supervised spending, and eventually earn a card with limits. Agents should earn trust the same way, across progression stages:

Promotion up this ladder should hinge on evidence, not intuition. That means testing an agent before each step, not just watching it in production. Agents resist testing: they are nondeterministic, costly to call, and act through tools with real side effects. Teams therefore mock or replay tool and model interactions so tests run deterministically in CI, and score agent decisions with evals rather than calling live services on every run. Building that harness is a discipline of its own.

Authentication and Authorization for Agents

As agents earn autonomy, the question turns to what permissions they hold. Three security patterns matter most:

• Delegated Access: When Alice asks the agent to check her account, the agent should act with Alice’s permissions, not a broad service account that can see every customer’s data. Shared service accounts destroy attribution. When a regulator asks who accessed a customer’s data, “the service account” answers nothing. With delegation, the answer is “Alice’s agent, acting on Alice’s behalf, with Alice’s permissions.”
• Just-in-Time Credentials: Issuing a short-lived token for each specific task beats standing API keys that never expire. Checking the sanctions list? Issue a token scoped to OFAC API read access for that specific customer, valid for five minutes. When the task completes, the token expires—no standing credentials waiting to be compromised.
• Least Privilege: Grant the minimum access a task requires. Processing a letter of credit does not need reach into HR systems or marketing data.

These three patterns together address both attribution and scope challenges undermining many agentic deployments. They also blunt the sharpest security risk in agentic systems—what Simon Willison calls the lethal trifecta: an agent turns dangerous when it simultaneously holds access to private data, exposure to untrusted content, and a way to communicate externally. Together, those conditions let a single poisoned document or web page hijack the agent via prompt injection and exfiltrate whatever it can reach. Delegated access, just-in-time credentials, and least privilege shrink the blast radius of a hijacked agent, breaking that trifecta. Separately, a second cut at the problem—keeping retrieved text out of the authorization path entirely—ensures a poisoned document cannot grant a permission in the first place.

A Pragmatic Path Forward

Governance is the area where moving deliberately is correct. But separate two conflated concepts. Autonomy is earned in stages; no one expects full autonomy at once. Observability, however, is not staged. 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 remain conservative; the instrumentation underneath cannot.

• Instrument from day one. Do this first—adding observability post-deployment is far harder. Every agent workflow should emit traces with spans for each step, including reasoning and sources consulted. Lean on proven tools like OpenTelemetry rather than building your own.
• Start in shadow mode. Lowest risk, highest learning. Agents recommend; humans decide. You build an audit trail before compliance demands it and measure accuracy before granting autonomy.
• Implement delegated access. Agents inherit the invoking user’s permission and use just-in-time credentials with short expiry windows, with no persistent tokens.
• Build to be explainable. Whether or not regulators ask, an audit trail that answers “why” is what lets you debug bad decisions, defend good ones, and widen autonomy with confidence. Wiring it now is far easier than adding it later.

With auditability and staged controls in place, the next frontier is connecting agents to the institutional knowledge trapped in your analytical tools and metadata — the bridge that semantic layers can build.

The Context Layer: Nouns, Numbers, and Verbs

Semantic layers give AI agents the explicit context that human analysts carry implicitly. A person asking "What was Q3 revenue for Product X?" knows which table to query, whether revenue means gross or net, and how the fiscal calendar maps—knowledge absorbed over years. An agent has none of that. Without it, the agent either hallucinates or gives up. The context layer fills that gap, but a capable agent needs more than just metric definitions.

Three models, one vocabulary

The context layer comprises three distinct bodies of definition, and an agent needs all three:

• The domain model says what exists: entities, relationships, and business meaning rules. An order belongs to a customer; an active customer is one who purchased in the last ninety days. It gives the agent vocabulary and is consulted, never executed—no query path runs through it.
• The semantic model says how numbers are computed. Metrics and dimensions each have one versioned formula, compiled to the same SQL every time and run against the analytical store. This puts correctness in the compiler rather than in the model's guess.
• The capability model says what the agent may do: a curated set of operations against live systems, some reads (check payment status), some writes (issue a refund), each with permissions, an owner, and for acting ones, preconditions and reversibility status.

What unites these three is not that they are all about meaning—the capability model plainly is not. It is that each declares a guarantee once, in version control, instead of letting the model work it out fresh on every request. The definitions are the layer; the interface, MCP today, is just the door.

Why separate the domain model from the semantic model, when tools like dbt already declare entities in their semantic models? Because entities declared inside the metrics layer are scoped to metrics. The capability model must 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.

Metrics as code

The business logic lives directly in the definition—revenue = order_amount - discount_amount—not buried in a BI tool or ad hoc SQL view. Given a natural language question, the semantic model resolves it to correct, constrained SQL. The agent doesn't guess table names or join paths; it uses the definition.

The syntax examples here use dbt MetricFlow, though Cube.js, Snowflake, and Databricks follow similar patterns. The tool matters less than the discipline: metric definitions in version control, one agreed definition per metric.

semantic_models:
  - name: orders
    model: ref('orders')
    defaults:
      agg_time_dimension: order_date
    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
    measures:
      - name: revenue
        agg: sum
        expr: order_amount - discount_amount
        create_metric: true

Same question, very different SQL

Consider the difference. Ask an agent without a semantic model "What was Q3 revenue for Product X?" and it guesses at table names, uses the wrong column, has no fiscal-calendar mapping, and misses the join.

-- Before metric definition
SELECT SUM(amount)
  FROM sales_data
 WHERE product = 'Product X'
   AND quarter = 'Q3'

With a semantic model, the agent is constrained to the correct table, the net-revenue formula from the YAML definition, the right fiscal-calendar dates, and the valid join path.

-- Constrained by metric definition
SELECT SUM(order_amount - discount_amount)
  FROM orders o
  JOIN products p
    ON o.product_id = p.id
 WHERE p.name = 'Product X'
   AND o.order_date
       BETWEEN '2025-07-01'
           AND '2025-09-30'

The 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. Another benefit: dbt's semantic model dynamically surfaces only the dimensions applicable to selected metrics, preventing plausible but incorrect queries. The lineage metadata returned with results is also the foundation for traceability.

Where to start

Resist the urge to model the whole business before shipping anything. Start with the semantic model, scoped to the contested metrics that mean different things to different teams—those conflicts are your biggest agent risk and your quickest win.

• Find conflicting metric definitions. Revenue is the classic case: gross vs. net, with or without returns. Resolve those in version control first.
• Pick a tool, focus on discipline. Any mainstream semantic layer tool works if you keep definitions in code, one per metric, and route agents through the layer, not the raw schema.
• Route agents through the context layer, never raw tables. Expose governed metrics and dimensions via MCP if you like; dbt, Cube, and AtScale all ship MCP servers. The abstraction matters, not the protocol.
• Test adversarially. Every hallucination points to a missing definition. Fix the definition, not the prompt. Start with what your first agent use case needs; a narrow, correct context layer beats a sprawling, half-agreed one.

Beyond structured queries: domain traversal with knowledge graphs

Semantic models shine for structured queries like "revenue by region." Some tasks demand richer reasoning: a customer who bought Product X, then churned after a pricing change. A fixed number of hops is an ordinary join. What flat tables handle poorly is traversal of unknown depth—following a chain of relationships until you find what you're looking for. That is the domain model's territory.

The common way to store and traverse that map is a knowledge graph—a storage choice for the domain model, not a fourth thing to build. Microsoft's GraphRAG uses community detection for abstract queries that traditional RAG can't handle; Graphiti builds temporally aware graphs for evolving facts. The semantic model still defines metrics; the graph carries the connections between customers, products, and events over time. Together, they give agents something close to institutional memory.

Reading Data Is Not the Same as Acting on It

Knowledge and governance give an agent context and boundaries, but neither makes it useful. Usefulness requires access — the ability to reach live systems and change them. Most organizations have built only the first step of that access: retrieval. Real agentic workflows need three distinct tiers of data access, and the gap between what is searchable and what is actionable is where the risk lives.

Consider a common scenario: an employee reports a purchase order (PO) problem. A capable agent would retrieve the relevant troubleshooting guide, verify that the payment service is currently operational, and, if necessary, open a support ticket. Standard RAG deployments stop at the first step. They can search documents, but they cannot query a live monitoring system or file a ticket in ServiceNow. That difference defines the full spectrum of agent-ready access.

The three tiers of agent access

Microsoft's Cloud Adoption Framework for AI formalizes this as RAG + MCP-Read + MCP-Write. The tiers are:

1. Retrieval. Vector search and document lookup. The agent finds relevant content. Most current deployments live here.
2. Real-time query. The agent reads live state — checking service status, querying databases — at the moment of need.
3. Write-back. The agent takes action: creating tickets, updating records, triggering workflows.

The PO scenario maps cleanly onto all three: retrieve the guide, check the payment service status, and create the ticket. Each step up adds capability and risk. Agentic AI requires all three tiers, not just the retrieval most teams have built. MCP has become the default wiring for these tiers, but the mechanism matters less than keeping the tiers separate and deliberately governed, whether exposed through MCP or native APIs.

Capabilities, not endpoints

Within MCP, the primitives sit on a risk gradient. Resources are read-only and safe, Prompts shape behavior, and Tools change state. This maps directly onto the tiers: Resources serve retrieval, Tools serve write-back. The safe path is to expose Resources first and graduate to Tools only under governance.

The common mistake in designing Tools is naive API-to-MCP conversion: wrapping every REST endpoint one-to-one so each becomes a tool. This produces tool sprawl — fifty tools with names like get_po_payment_status and create_ticket_po_payment_network. LLMs are poor at choosing among dozens of barely-distinguished tools, and accuracy drops as the count climbs. Thoughtworks' Tech Radar placed this pattern on HOLD for exactly that reason.

The better approach exposes the same functionality as five to ten well-described capabilities with rich descriptions and parameterized inputs. check_service_status takes a service name and location; one tool serves all services. create_support_ticket is parameterized with category, priority, and description. Well-described business capabilities outperform thin API wrappers almost every time. This principle is protocol-agnostic: whether access runs through MCP or whatever standard comes next, the agent-ready properties are the same — rich descriptions, parameterized access, and clear schemas.

Declaring what a capability can do

A rich description tells the agent when to use a capability, but not whether it is permitted to, or what happens if it is wrong. Every capability declaration must carry permissions, specifying who may invoke it and acting as whom, plus an owner accountable when it misbehaves. The capabilities that act carry two more elements.

Preconditions are conditions that must hold before the action proceeds. Crucially, these are checked against live state at the moment of acting, not against whatever the agent read earlier in its plan. A refund requires an original payment that has not yet been refunded, within the invoking user's authorization limit.

Reversibility classifies the damage an action can do: cleanly reversible, reversible at a cost via a compensating transaction, or irreversible. This predicts safe autonomy better than the transaction size. A $50,000 internal ledger correction you can back out is safer to automate than a $200 payment to an external account you cannot recall. The staged autonomy ladder built earlier keys guardrails to transaction size; prefer keying them to reversibility, and require human approval for irreversible actions regardless of the automation stage.

Retrieved rules inform, they never authorize

Business rules live in prose — refund policies, contracts, compliance manuals. But a rule that gates an action cannot be read and interpreted at the moment of acting. Rules must be extracted from documents ahead of time, curated by a human, and stored as declared preconditions, each with a link back to the source passage.

At action time, unstructured content can still inform what the agent proposes — a complaint ticket, a contract clause — but only the declared rules carry authority, checked deterministically against live state. The boundary separates informing from gating. Retrieved text shapes suggestions and serves as evidence for human approvers, but it never authorizes the action itself.

This boundary is also a security property. Removing retrieved text from the authorization path means a poisoned document cannot grant an agent permission it did not already possess. It is not a complete defense — injected text can influence what the agent proposes, and a human shown fabricated evidence may approve it. What is removed is the path where a document authorizes action directly, with no human in between.

The provenance link keeps declarations honest as documents change. Detecting a document changed is easy; knowing that the change invalidated a derived precondition is a judgement, not a diff. The link yields a review queue: when source content moves, derived rules are flagged for human re-check. Where no declaration covers a situation, the agent must not improvise from its own reading of policy — it escalates. An undeclared case degrades the agent to supervised, not autonomous.

The end-to-end PO flow

With all three tiers in place, the PO issue runs completely: 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), in a single workflow. Manually, the employee would queue, explain the issue to a support agent who checks a monitoring dashboard, and wait for a ticket to be created. The agent collapses that into one pass.

Climbing the tiers safely

The safe path is to earn write-back access. Most teams already live in retrieval, where risk is lowest. Write-back is where the danger sits. Climb the tiers deliberately:

• 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 concentrate in the latter two.
• Design capabilities, not endpoints. Group existing APIs into 5–10 well-described business capabilities. The quality of descriptions determines how well the LLM picks the right tool.
• Start with MCP Resources. Read-only access is the lowest-risk entry point. Expose knowledge bases and configuration data as Resources, and graduate to Tools only once governance is in place.
• Instrument from day one. Before deploying any agent with write access, log every tool invocation — who triggered it, what was called, when, and on whose behalf. This feeds the audit trail required for the traceability and governance already established.

Assembling the AI-ready foundation

Viewed in isolation, the four pillars—trusted contracts, a semantic context layer, controlled access, and observability—look like separate workstreams that could be staffed independently. They are not independent. Each builds on the one below it, and the order of construction is non-negotiable.

The dependency chain runs bottom-up. You cannot attach reliable meaning to data you cannot trust, so the context layer sits on top of validated contracts. You cannot safely grant agents write access without that semantic constraint, so access patterns rest on the context layer. Skips any of these steps and everything above it is structurally unsound; this is precisely why many agentic AI initiatives stall when they jump straight to agent access without building the substrate first.

Observability is the exception to the stacking order. Rather than a final tier added at the end, it is a cross-cutting concern present from day one. Every layer—the trust checks, the semantic queries, the agent's actions—must be traceable and auditable as soon as it handles production load. Retrofitting instrumentation onto a running system is considerably harder than wiring it in initially, so it belongs in every workflow from the start.

Ownership as the missing layer

The stack diagram cannot depict one further dependency: every layer produces artifacts that must be kept honest. A data contract drifts out of sync without an owner. A unified definition of “revenue” forks back into conflicting versions. An access scope quietly widens into standing privileges. The technology is necessary, but the operating model is what maintains its integrity.

The discipline that holds this together is treating data as a product. Each dataset, contract, and metric gets a named owner, a published SLA, and a versioned lifecycle, in the same way a public API does. For broadly shared data you cannot know every downstream consumer, which is exactly why a versioned contract matters—it is the stable promise unknown consumers build against, and deprecation policy is how you change it without breaking them. When a contract blocks a deployment at 2 a.m., someone is accountable. When finance and sales dispute a metric definition, someone owns the decision. These are ownership questions, and no tool resolves them automatically.

The cost of unowned data scales with consumer autonomy. A human notices drift and works around it. An agent consumes the data at machine speed and propagates the error just as quickly. The more autonomous your consumers, the less you can afford data without an owner.

Assessing your readiness

Before building, locate your starting position. Score each capability against the signals below.

Do not average the scores. Readiness is capped by your weakest foundational layer—a flawless context layer on untrusted data is still not production-ready. The weakest row dictates the next investment.

Initial priorities

The tactical lists within each previous section address the mechanics. The following four items set the sequence. The first is not a build step; it runs alongside the others continuously. The remaining three build from the foundation upward.

1. Instrument from day one. This is a constant across all workstreams, not a phase. Traces and spans in every workflow from the outset are far easier to embed than retrofit, and audit trails that answer “why” serve debugging today and regulators tomorrow.
2. Contract everything. Enforce freshness SLAs, strict schemas, and quarantine for bad data. This is the floor beneath all else—agents cannot detect bad data, so the data architecture must detect it on their behalf.
3. Context over models. Once data is trusted, a context layer provides the highest return on additional investment. In AtScale's text-to-SQL benchmark, the semantic model alone raised accuracy from under 20% on the raw schema to over 92.5% with the same underlying model.
4. Read before write. Start with read-only MCP Resources and graduate to write-capable Tools only when governance is in place. Earn autonomy in stages: shadow mode first, then supervised, then autonomous with guardrails.

When agents become the primary consumers of your data, your data architecture becomes your AI architecture.