Key Takeaway
An AI agent is only as reliable as the data and interfaces it acts on. Before you give one write access, score the use case on four layers (definitions, interfaces, controls and observability), and if it lands below 10 of 20, fix the foundation instead of buying a bigger model.
AI agents act on your data, so every weakness in it turns into an action. This article is for CDOs (chief data officers) and CTOs planning to give an agent write access to real systems. It walks through a foundation review you can run on one use case: definitions, interfaces, controls and observability, scored out of 20.
A dashboard built on a bad definition produces a wrong chart. Someone squints at it in a meeting, asks a question, and the number gets fixed.
An agent built on the same bad definition sends a customer the wrong credit. Then it does it 400 more times before anyone notices, because nobody was squinting at anything. The agent was trusted to act.
That’s the shift agents bring to data work. Analytics tolerates ambiguity because a person sits between the data and the decision. Agents remove that person, or at least move them further away. Every weakness a human used to absorb now flows straight into an action: a fuzzy definition, an API with undocumented side effects, a service account with too much access, a pipeline that quietly went stale.
McKinsey’s April 2026 research on scaling agentic AI puts the gap in numbers. Nearly two-thirds of enterprises have experimented with agents, and fewer than one in ten have scaled them to tangible value. Eight in ten cite data limitations as a roadblock. Our experience points the same way, with one refinement. The problem is rarely the data alone. It’s the data plus the interfaces around it.
Is trusted data the same as agent-ready data?
No. Trusted data is enough for a person who knows its quirks. Agent-ready data has to be safe for a system with no context, no judgment about exceptions and no fear of getting fired.
In From Data to Value, we argued for starting with one decision and one source the decision owner already trusts. That’s still the right first step. For an agent, it isn’t enough.
A person who trusts a source also knows where it bends. They know the “region” field is blank for accounts migrated in 2023. They know the refunds API takes a minute to reflect a change. They know not to touch enterprise accounts without asking the account owner. None of that is written down, so the agent has none of it.
Four layers decide whether an agent can act on the data safely.
| Layer | The question | What breaks when it’s missing |
|---|---|---|
| Definitions | Is the business meaning of every field the agent uses written down, in a form a machine can read? | The agent picks one of three meanings of “active customer” and acts on it |
| Interfaces | Does the agent reach systems through stable, documented, versioned APIs? | Scraped screens break, raw SQL hits production, retries duplicate writes |
| Controls | Is the agent’s access scoped to the task, with limits and an approval path? | A shared admin service account lets a prompt injection do real damage |
| Observability | Can you see data quality before the agent acts, and reconstruct every action after? | Stale data drives confident wrong actions, and nobody can explain why |
McKinsey’s own architecture principles agree. Two of them are about sharing meaning alongside data and exposing capabilities through stable interfaces. Both get skipped in most pilots, because the pilot runs on a clean extract with a developer watching.
How do you write data definitions an AI agent can use?
Make each one explicit, singular for the use case and reachable at runtime. Most organizations already have definitions. They live in a BI tool’s metric layer, a wiki page from 2022 and the heads of three senior analysts, and they disagree with each other.
Write down the terms the agent reasons over. Not the whole glossary. For a billing agent that’s customer, active subscription, invoice status, dispute, credit and eligible. Each gets one definition, one owner and the source field it maps to.
Put the definitions where the agent can retrieve them. A semantic layer or metrics store is the cleanest place. A well-structured document in the agent’s retrieval context also works for a first use case. A wiki page nobody links to doesn’t.
Encode the exceptions. The rules a person carries in their head (“never auto-credit an account in collections”) are definitions too. If they matter, they belong in code or in a policy the agent checks. A prompt instruction is the wrong place, since the model may weigh it against other instructions.
Check: pick five terms the agent uses. Ask two people from different teams to define them. If the answers differ, the agent will be wrong for one of those teams.
What makes an API safe for an AI agent to call?
A contract. Agents call tools, and each tool is an interface to a real system. Most of those interfaces were built for people clicking buttons or for batch jobs, not for an automated caller that retries on failure and reads error messages literally.
An agent-ready interface has five properties.
- Versioned and documented. The agent’s tool definition points at a specific API version with a schema. When the API changes, the tool definition changes with it, through code review.
- Typed inputs and outputs. Enums instead of free text where possible. A credit amount is a decimal with a currency and a ceiling, not a string.
- Idempotent writes. Every write takes an idempotency key, a unique ID that makes a repeated call harmless. If the agent retries after a timeout, the customer gets one credit, not two.
- Errors that explain themselves. “Account in collections; credits require approval” lets the agent route correctly. “400 Bad Request” leads to a retry loop.
- Business-level operations. Expose “issue goodwill credit” as one operation that enforces its own rules. Don’t let the agent compose three low-level calls against the ledger.
The last point matters most. The more business logic sits behind the interface, the less the agent has to get right on its own. We go deeper on tool design in AI agent architecture: what production systems actually look like.
Check: list every tool the agent calls. For each one, can you point to its schema, its version and what happens when it’s called twice with the same input?
What permissions should an AI agent have?
The fewest that let it do the task, granted per operation, with hard limits enforced outside the prompt. The fastest way to get a demo working is to give the agent the credentials a developer already has. That’s also how teams end up with an agent that can delete records it should only read.
The agent gets its own identity. Not a shared service account and not a human’s token. Its own principal, so every action is attributable and access can be revoked without breaking anything else.
Read-only by default. Write access is granted per operation, not per system. “Can issue credits” is a permission. “Has write access to billing” isn’t.
Limits on every write. Per-action ceilings (no single credit over a set amount), rate limits (no more than a set number of actions per hour) and scope limits (only accounts in a given segment). Enforce them in the interface, not in the prompt.
An approval path for anything above the limit. The agent prepares the action and a person approves it. The workflow keeps moving instead of failing, and you get a labeled record of which recommendations a human accepted.
Inputs treated as untrusted. If the agent reads customer emails, support tickets or documents, someone can plant instructions in them. Scoped permissions keep a successful prompt injection from becoming a serious incident. Our guide to the AI agent attack surface covers this in depth.
Check: if the agent followed a malicious instruction hidden in a support ticket, what’s the worst single action it could take? If the answer makes you uncomfortable, the permissions are too wide.
What should you monitor before and after an AI agent acts?
The data going in and a record of what came out. Agent observability usually means tracing the agent itself: prompts, tool calls, latency, cost. That’s necessary, and we cover it in AI agent observability. The half that gets missed is watching the data the agent is about to act on.
Before the action: data quality gates. Freshness (when did this source last update?), completeness (are required fields populated for this record?), schema (did a column change type upstream?) and volume (did today’s load drop by half?). If a gate fails, the agent stops or routes the case to a person. It doesn’t push ahead on stale data.
After the action: a decision record. What the agent saw, which definitions and policies it applied, which tool it called with which arguments, what the system returned and what changed. Store it somewhere the business can query, not only in an engineering trace tool.
Check: pick an action the agent took last week. Can a non-engineer find out, in under ten minutes, what data it used and why it acted?
How do you score whether a use case is agent-ready?
Score ten items 0 (missing), 1 (partial) or 2 (in place), for one specific use case rather than the whole company. The total out of 20 tells you whether to ship with write access, ship in recommend-only mode, or fix the foundation first.
| # | Item | 0 / 1 / 2 |
|---|---|---|
| D1 | Every term the agent reasons over has one written definition and an owner | |
| D2 | Definitions and business exceptions are retrievable at runtime | |
| I1 | Every tool maps to a versioned, documented API | |
| I2 | All write operations are idempotent | |
| I3 | Errors are descriptive enough for the agent to route correctly | |
| C1 | The agent has its own identity, read-only by default | |
| C2 | Write permissions are per operation, with ceilings and rate limits enforced in the interface | |
| C3 | Actions above the limits route to a human approver | |
| O1 | Freshness, completeness and schema checks gate the agent’s actions | |
| O2 | Every action produces a decision record the business can query |
How to read the total:
- 16 to 20: Ready for a supervised rollout with write access in a limited segment.
- 10 to 15: Ship in recommend-only mode while the gaps get fixed. The agent drafts, a person executes.
- Below 10: Fix the foundation first. The fastest path to a working agent is two or three foundation milestones, not a bigger model.
A low score on a first use case is normal, and it’s useful. The zeros tell you which two or three fixes come first.
What does a foundation review look like on a real agent?
Here’s a billing dispute agent that worked in the pilot and scored 5 of 20. This example is illustrative. The structure is typical; the company and numbers aren’t real.
The use case. A B2B SaaS company wants an agent to handle billing disputes: read the customer’s message, check the invoice and usage, and issue a goodwill credit when the dispute is valid.
The pilot. It worked well on 50 hand-picked tickets. In a shadow run against live tickets, it would have credited three accounts in collections and double-credited one customer after a timeout.
The scorecard.
- D1: 0. “Valid dispute” had no written definition. Finance and support disagreed on whether usage overages counted.
- D2: 0. The collections exception lived in one manager’s head.
- I1: 1. Invoices had a documented API; usage data came from a raw warehouse query.
- I2: 0. The credits endpoint wasn’t idempotent.
- I3: 1. Partial.
- C1: 1. The agent had its own identity, but with broad billing write access.
- C2: 0. No ceilings.
- C3: 1. An approval queue existed for refunds, not for credits.
- O1: 0. Usage data was sometimes 36 hours stale, unflagged.
- O2: 1. Traces existed in the engineering tool only.
Total: 5 of 20. The model was never the problem.
The first milestone. Finance and support agree on a written definition of “valid dispute” and the collections exception. Engineering wraps credits in a business-level “issue goodwill credit” operation with an idempotency key, a per-credit ceiling and automatic routing to approval for accounts in collections. A freshness gate stops the agent when usage data is older than six hours. The agent ships in recommend-only mode for one segment. Scored again after the milestone, the use case lands between 14 and 16, and the team has a clear path to supervised write access.
On a live agent. We made the same calls on a creator platform agent that reached real users in under three weeks. The agent runs as the signed-in user, through the same Postgres Row Level Security rules as the UI, and there’s no service-role key for it to misuse. It has 17 typed actions with validated inputs and can’t do anything outside that list. It can archive but never delete, so every change it makes can be undone. Interfaces and controls were settled before the first user touched it.
Who should run an agent foundation review?
The data team, application engineers, security and the business owner, together. The work cuts across groups that don’t usually sit in one room. Data owns definitions and quality checks. Platform or application engineers own the APIs. Security owns identity and permissions. The business owns the exceptions.
Agents force those groups into one conversation, which is useful on its own. What’s usually missing is someone who has shipped production agents and can translate between them, someone who knows which gaps block an agent and which only look bad on a slide.
That’s the role our engineers play. They embed with your team, run the foundation review on one use case, then work in your codebase to close the top gaps and ship the agent behind them, in your release cycle. The definitions, interfaces and controls stay with your team when the engagement ends, ready for the next agent. For how embedded work runs week to week, see AI augmented development.
Frequently Asked Questions
What does agent-ready data mean?
It means an AI agent can act on the data safely without a human filling in context. Terms have one written definition, systems are reached through versioned APIs with idempotent writes, access is scoped per operation, and quality checks run before every action.
Can an AI agent use our existing APIs?
Often, but rarely as they are. Most internal APIs were built for people or batch jobs, so they need typed inputs, idempotency keys, descriptive errors and business-level operations before an agent should write through them.
Should an AI agent start with write access?
Not unless the use case scores 16 or more out of 20 on a foundation review. Below that, run it in recommend-only mode so it drafts actions and a person approves them while you close the gaps.
Which data source would you not trust an agent to act on?
Every company has one. The system everyone works around, the table with the unreliable column, the API nobody wants automated callers anywhere near. Start there.
Tell us which one, and we’ll run a foundation review on one use case: data, interfaces, controls and observability, scored with the checklist above. You leave with the gaps in order and a proposed first milestone. Book a foundation review.