The current data stack assumes a human is the unit of work. A person signs in, opens an application, performs a small number of actions, and leaves a narrow trail behind. The systems underneath can be fragmented — transactional databases, warehouses, search indexes, vector stores, object storage, and log pipelines — because the pace is human and the identity is usually clear, with an implicit accountability model that bounds behavior when things go wrong (shame, job loss, and in some extreme cases, jail).
Agents change that operating model. One instruction can turn into twenty lexical searches, a vector search over runbooks, SQL joins across incidents and policies, filters over audit history, and a sequence of follow-up calls from subagents. Those reads happen in parallel, under delegated authority, and often against data copied into tools that each have their own permissions and retention rules.
agent.search("payment failure", "stripe webhook 5xx",
"checkout timeout", "card declined", ...18 more)
agent.vector_search(embed("user can't complete checkout"), k=50)
agent.sql("select * from incidents
where service = 'checkout' and ts > now() - '24h'
join runbooks using (service)")The hard question is not whether an agent can be connected to existing data. It can. The question is whether the data layer can answer, precisely and later, what the agent was allowed to do, what it actually saw, who approved the authority it used, and how much data it produced along the way — and whether it can do so fast enough that the agent's next step does not stall waiting for the answer. That requires five properties to be part of the data layer itself: identity, audit, latency, cost, and compatibilitywith the systems already trusted by the business.
Identity
Agent identity cannot collapse into service accounts. Every action has to resolve to an accountable human, the role that human owns, the policy that permitted the action, and the specific agent or subagent that executed it. If an agent delegates work, the child agent needs its own credential and a narrower scope. The chain should remain intact from the human owner down to the final tool call.
User and role must stay separate. A user is an identity — a person, or an agent issued its own credential. A role is a named bundle of permissions that exists independently of whoever holds it. Users are granted roles; agents are granted roles on behalf of a user; roles are governed by policies; and every role, policy, and grant has a named human owner. Keeping these layers distinct is what makes the system operable: a credential can be revoked without rewriting permissions, a role can be tightened without reissuing identities, and every action in the log carries both the agent that ran it and the human accountable for the authority it used.
Collapsing the two produces the failure mode every security team recognizes: agents acting as their user, or worse, as a shared svc-agent-prod, with no durable record of which agent ran, which role it held, or who owned the policy that allowed it. Once that shortcut is in production, access reviews, incident response, and customer questions all become exercises in reconstruction.
Audit
Audit is only useful if it is immutable, time-aware, and close to the data being accessed. Agent systems need to answer more than "which API was called." They need to answer what happened, which role approved it, which policy version was evaluated, which rows or files were visible at the time, and whether a blocked action was correctly denied.
"What did triage-bot access yesterday, and under whose role?" "Show every policy decision that blocked a tool call this week." "Reconstruct the exact corpus the agent saw at 14:03 UTC."
That cannot depend on a best-effort trail stitched together from application logs, warehouse history, vector-store metadata, and a separate SIEM. Agents act on a view of data at a moment in time, and the mistake may not be discovered until much later. The store has to preserve that moment: the same objects, the same versions, the same permissions, and the same policy decisions. Otherwise the audit is not an audit; it is a theory about what probably happened.
Latency
A single user-facing answer often takes hundreds of underlying reads: parallel keyword searches, vector lookups, SQL joins, filtered scans over history, and follow-up queries from subagents reacting to what the first pass returned. Latency compounds at every hop, and any query that misses its budget either gets dropped from the plan or forces the agent to answer with less context than it should have. The data layer has to treat high-fanout, mixed-workload access — lexical, vector, relational, and time-travel — as the normal case, not a tuning exercise.
This is why bolting agents onto a stack designed for human-paced BI tends to fail quietly. The queries return, eventually, but the agent has already moved on, retried, or degraded the answer. Fast, predictable reads against governed data are what let an agent actually use the breadth of context it was given access to.
Cost
Agent systems create data as part of doing the work. They generate traces, intermediate corpora, tool-call snapshots, evaluation sets, rejected actions, and long audit histories. Treating that material as exhaust is a mistake; it is the evidence needed to debug the system, improve it, and prove what happened. If storing it is expensive, teams will sample it, shorten retention, or move it somewhere disconnected from the data it explains.
Object storage is the right economic base because it lets teams keep more context without turning retention into a quarterly budget fight. It also enables a practical staging pattern. When two teams, or two companies, want agents to collaborate, neither side should hand the other direct access to its systems of record. A governed copy in a trusted lake, with per-principal permissions and per-query attribution, is safer — but only if the copy is cheap enough to keep.
Compatibility
The agent layer should not create another data island. If every tool gets its own copy — one for search, one for embeddings, one for analytics, one for audit, one for evaluation — the organization inherits five loaders, five permission models, five retention policies, and five ways for the data to drift. That is exactly the problem agents are supposed to help reduce.
The better answer is to keep one governed copy in the lakehouse and let the right engines operate on it. Agents should be able to search, join, filter, and retrieve from the same Parquet files the analytics team already trusts, with the same schemas and governance. The cost of giving agents access should be a permission grant, not a migration into another proprietary store.