Most of the data conversation in generative and agentic AI is about what goes into the model. The corpus, the context, the prompt. Agentic AI adds a dimension that the industry is still catching up to: agents generate data as much as they consume it. Every tool an agent calls returns data it treats as ground truth. Every action it takes writes data back into systems of record. Every memory it retains becomes context that steers its future behavior. In Article 1 of this series I called data the control surface of agentic AI. This article is about the three data domains that surface is actually made of, and why each one needs an owner, a quality standard, and a set of controls of its own.
This is a departure from the retrieval focused thinking that dominates enterprise AI discussion. Retrieval is about giving a model good context to read. Agents are about what happens when a system reads, decides, and acts in a loop. The data created inside that loop is where the real governance frontier sits, and in financial services it is where the real risk sits too.
For the data retrieval concept, please refer to my articles in the RAG article series:
Domain One: Tool Outputs Are Inputs You Did Not Curate
An agent is only as reliable as the tools it calls. When an agent queries a pricing service, pulls a position from a ledger, or calls an internal API to check a limit, the response becomes an input the agent reasons over with the same trust it gives any other context. But unlike a curated knowledge corpus, tool outputs are live, uncurated, and often outside the AI team's control entirely.
This creates a quiet dependency that most agent designs never examine. If the tool returns stale data, the agent reasons on stale data. If the tool returns an error formatted as text, a naive agent may treat the error message as a fact. If two tools return contradictory values for the same entity, the agent resolves the contradiction invisibly, often by trusting whichever it saw last. The failure is not in the model. It is in treating tool outputs as trustworthy simply because they came from a system rather than a document.
The disciplines that make tool outputs safe to reason over:
• Provenance on every response.An agent should know the freshness, source, and confidence of every tool response, and downstream reasoning should be able to reflect it. A position that is real time and a position that is end of day prior are not interchangeable, and the agent should not treat them as such.
• Contract and validation at the boundary.Tool responses need validation before they enter reasoning: schema checks, range checks, and explicit handling of empty, error, and partial results so a failure is never silently consumed as a fact.
• Contradiction handling.When tools disagree, the resolution rule must be explicit and owned, not left to whatever the model happens to weight. This is the same semantic agreement problem that plagues retrieval, now arriving through live systems instead of documents.
Domain Two: Agent Memory Is a Database Nobody Designed
Read my previous Article about Memory Systems in Agentic AI
Memory is what separates an agent from a single stateless call. It lets an agent carry context across steps, remember a user's prior instructions, and build on earlier conclusions. It is also, in most implementations, a data store that grew organically with no schema, no owner, no quality rules, and no lifecycle. That is a governance problem hiding inside a capability.
The risk with memory is that it compounds. A wrong fact written to memory early is retrieved and reinforced later, and the agent grows more confident in it precisely because it keeps seeing it. Memory can also silently accumulate sensitive data that was appropriate in one moment and a liability in the next, retained with no expiry and no classification. And memory shapes behavior in ways that are hard to audit after the fact, because the context that drove a decision may have been assembled from fragments written across many prior interactions.
Treating memory as a first-class data domain means asking the questions we would ask of any store of record:
• Schema and structure.What is written to memory, in what structure, and with what metadata? Memory that captures its own provenance, timestamp, and source can be audited. Free form memory cannot.
• Lifecycle and expiry.How long does a memory live, when does it expire, and can it be corrected or deleted? A memory with no lifecycle is a liability that only grows. Right to correction and deletion are not just privacy niceties here, they are operational necessities.
• Classification and access.Sensitive content in memory needs the same classification and entitlement treatment as any other sensitive data. A memory the agent surfaces to the wrong user is a leak, whatever its source.
• Correction of compounding errors.A mechanism to detect and correct a wrong belief that has propagated through memory, before it drives a wrong action, is the memory equivalent of data quality remediation.
Domain Three: Action Logs Are Your Only Version of the Truth
When an agent moves from answering to acting, drafting an entry, updating a record, routing a payment, opening a case, it produces a new kind of data: a record of what it did. In a read only world this data barely mattered. In an execution world it is the single most important data an agent produces, because it is the only evidence of what actually happened and why.
This is where agentic AI collides directly with the expectations of a regulated institution. When an action turns out to be wrong, and some will, the questions come fast. What did the agent do? What data did it act on? What reasoning led there? Who, or what, authorized it? If the answer to any of these lives only in ephemeral state that was overwritten on the next step, the institution cannot reconstruct the event, cannot remediate the root cause, and cannot demonstrate control. The action log is not telemetry for engineers. It is the audit trail, and it must be designed as one.
What a defensible action log captures:
• The action itself.Every action the agent took, with enough context to understand it independently of the agent's transient state.
• The inputs.The specific data and tool outputs the action was based on, versioned so the inputs can be reproduced later.
• The authorization.Whether the action was autonomous or gated by a human checkpoint, and who approved it if gated. Irreversible actions in finance should rarely be fully autonomous, and the log should prove where the human stood.
• The retention.A retention and integrity standard that satisfies the institution's recordkeeping obligations, because an audit trail that can be altered or lost is not an audit trail.
The Pattern Across All Three Domains
Tool outputs, memory, and action logs look like three different engineering concerns. They are one governance concern seen from three angles. Each is a data domain the agent creates or consumes at run time. Each needs a named owner, a quality standard, and controls, and none of them existed as a managed domain before agents did. The institutions that will scale agentic AI safely are the ones that recognize these as data domains to be governed, not as implementation details to be logged and forgotten.
This maps cleanly onto the governance disciplines this series has built on throughout. Tool output provenance and validation use controls at the boundary. Memory lifecycle and classification are inventory, classification, and change management applied to a store that did not exist a year ago. Action logs are the lineage and recordkeeping backbone that any SR 11-7 style validation, and any examiner, will expect. The technology is new. The governance questions are not.
The Test I Give Every Agent
Before an agent goes anywhere near production with the ability to act, I ask five questions.
Does the agent know the provenance and freshness of the data its tools return, and does it handle tool failures explicitly rather than consuming them as facts?
Is agent memory structured, classified, and governed by a lifecycle, or is it an undesigned store that only grows?
Can you reconstruct, for any action the agent took, exactly what it did, what data it acted on, and who authorized it?
Are irreversible actions gated by a human checkpoint that the log can prove?
And who, by name, owns each of these three data domains?
An agent that passes these is producing governed data at every step. An agent that does not is accumulating unmanaged data and unlogged actions, and in a regulated institution that is not an efficiency, it is a liability compounding quietly until the first wrong action makes it visible.
If you are designing agents in your own organization, I would welcome hearing how you are governing the data they create, not just the data they read. Share your experience in the comments.
Explore more: Start Here · Topics · Archive · About