The right data is data the agent's role permits, from a known source, and current enough for the decision. The right time is twice: when the task starts, to assemble context, and again just before any action, to confirm nothing has changed. The governing layer does the fetching and stamping; the agent works with what arrives.
What makes data "right" for an agent?
Three tests, all of which must pass.
Permitted. The role decides which systems and fields an agent may see. A transaction-coding agent needs the chart of accounts and the transaction, not the customer's full history.
Sourced. Every fact arrives with where it came from. A balance read from the ledger and a balance quoted in a customer's email are different facts, even if the number is the same.
Current. Each fact has an age, and each decision has a tolerance. A product's terms can be a day old. An account balance before a payment cannot.
Most agent errors that look like reasoning failures are data failures: the agent reasoned well about the wrong version of the facts.
Why is the "right time" two moments, not one?
Context is assembled when a task begins. The agent reads the case, pulls the relevant records and starts work. If the task takes minutes or hours, the world moves on. A customer pays off an arrears balance; a colleague reassigns the ticket; a policy is cancelled.
So the platform re-reads the facts an action depends on immediately before the action runs. Engineers call the gap between the two reads the time-of-check to time-of-use problem. Closing it is cheap and prevents a class of errors that no amount of model quality can fix, because the model never saw the change.
How does this play out in different jobs?
| Job | Right data | Right time |
|---|---|---|
| Coding transactions to accounts | The transaction, the current chart of accounts, the coding rules | Chart of accounts read at posting, not cached from last month |
| Routing support tickets | The ticket, team remits, who is on shift | Rota read at routing, so tickets do not go to a team that has closed |
| Handling an erasure request | Every system holding the person's data, and any legal reason to retain it | Holds checked at the moment of deletion, not just when the request arrived |
| Drafting a support reply | The customer's case, the current policy text | Policy version confirmed when the draft is created and again when it is sent |
The erasure case shows why "right data" includes knowing where data lives. An agent cannot find what the platform has not mapped.
What does this look like in practice?
Take a collections team's agent that sets up payment plans. A customer asks for a plan on an overdue balance. At the start of the task, the agent reads the balance, the customer's income and expenditure statement, and the firm's affordability rules. It drafts a plan.
Forty minutes later, before the plan is created, the platform re-reads the balance. The customer has made a payment in the meantime and the balance is lower. The original plan would overcharge. The platform stops the action and returns the new figure; the agent redrafts. Without the second read, the plan would have been created on stale data and a person would have unwound it later.
The income statement is a different case. It was declared by the customer, so it arrives stamped as declared. The agent may use it to draft a plan within the firm's limits; anything outside them is held for a collections officer.
What stays with a person?
- Deciding which data each role may see, and reviewing it when roles change.
- Setting freshness tolerances for decisions that matter.
- Resolving conflicts between sources, such as a declared income that contradicts a bank statement.
- Approving actions that rest mainly on declared or external facts.
For new support agents in particular, this is one reason draft and hold is the right default: a person sees what the agent relied on before anything is sent.
What does the platform layer have to do?
- Assemble context from permitted sources only.
- Stamp every fact with source and time.
- Re-read action-critical facts at the moment of action.
- Record what the agent saw alongside each verdict.
The full design is in the governed agentic operating system guide.
Questions people ask
Should agents get as much data as possible to be safe?
No. More data widens what can leak and gives the agent more to misread. Give the role what the task needs and let it ask for more through a scope check.
How fresh does data need to be?
It depends on the decision. Reference data may be hours old; anything that moves money or changes a customer's position should be read at the moment of action.
What if a source is unavailable?
The agent should hold or fail the step, not proceed on an older copy without saying so. If a cached value is acceptable, its age must be recorded with the verdict.