Your Database Doesn’t Know What an Agent Is

An AI agent connecting to an enterprise database, represented as a ghostly figure passing through a security gate unchallenged

Pick any enterprise database deployment from the last thirty years and ask the question that nobody explicitly asked at design time: who is this system built for?

The answer is embedded in every layer of the architecture. Role-based access control organised around job functions. Audit logs capturing usernames tied to employment records. Connection pools sized for the number of people plausibly logged in at once. Session management built around the expectation that someone, somewhere, is sitting at a terminal. Privilege escalation procedures that assume a named employee is requesting elevated access for a documented reason. Even the compliance frameworks that govern these systems – SOX, GDPR, HIPAA, PCI-DSS – were written in a world where every database action had a human author.

Enterprise database identity is not a technical abstraction. It is a social contract written into code. And every term of that contract assumes the other party is a person.

The Service Account Approximation

The challenge is not that organisations are unaware of non-human access. Service accounts have existed for decades. Application tiers authenticate to databases using credentials that represent a system rather than a person. Batch jobs run under dedicated identities. ETL pipelines, monitoring agents, replication processes – all of these operate without a human typing a password, and enterprise database administration has long since developed conventions for handling them.

But those conventions were built around a specific model of machine access: predictable, bounded and purpose-specific. A service account for a nightly billing job does a known set of things on a known schedule – and nothing else. Its blast radius (the scope of damage if something goes wrong) is understood. Privilege is granted accordingly. The audit entry for its actions is meaningless without context, but that context exists in the design documentation, the deployment runbook, the change management ticket that authorised it.

This is the model that AI agents inherit when they connect to a database. They authenticate as a service account, or as an application layer credential, or – most concerning – under the delegated identity of the human user whose session the agent is acting within.

The database sees a familiar identity. It issues familiar grants. It records familiar audit entries.

What it cannot see is that the reasoning behind the actions is no longer predictable, no longer bounded and no longer reviewable before the commit.

The Identity Gap

The problem runs deeper than authentication. Authentication is the mechanism by which a database establishes who – or what – it is talking to. Most agent deployments pass this test without friction. The agent presents a valid credential. The database accepts it. From the database’s perspective, the session looks legitimate because it is legitimate, in the narrow technical sense.

What databases have never been designed to represent is the distinction between an authenticated principal and the reasoning entity that instructed that principal to act.

When a human logs into a database, the authenticated identity and the reasoning entity are the same thing. The DBA connecting to the production schema is the person with the job title, the access rights, the accountability and the judgment.

Identity and intent are co-located.

An agent collapses that co-location. The authenticated identity might be a service account owned by a platform team. The reasoning entity is a language model operating on behalf of a user in a different department, acting on instructions from an orchestration layer, possibly in response to inputs that no human has reviewed. The database sees the service account. It sees the queries and writes that account generates. It has no concept of the chain of instruction that produced those actions and no mechanism to represent that chain in any data structure it maintains.

The equation changed. The database’s identity model did not.

What the Audit Log Cannot Say

Consider what an audit log entry actually records: the timestamp, the authenticated user, the object accessed, the operation performed, the outcome.

This is, in principle, everything you need to reconstruct what happened. In a world of human actors, it frequently is. You can find the person, establish their role, review their authorisation and determine whether the action was appropriate. The audit log is the foundation of every compliance investigation, every incident post-mortem, every regulatory response.

An agent acting under a shared service account credential produces audit entries that are technically complete and operationally useless for this purpose.

You cannot find the person, because the person did not directly perform the action. You can find the human who prompted the agent – perhaps – if the observability tooling upstream has captured that chain. You cannot determine from the database record alone whether the action reflected authorised intent, a misinterpreted instruction, a hallucinated directive or the downstream consequence of another agent’s decision in a different system. The commit is the moment reality is made, and the database records that moment faithfully. It records nothing about what preceded it.

This is not a logging configuration problem. It is a conceptual gap between what the audit model was designed to capture and what agent-driven action actually produces.

Governance Without a Subject

The compliance and governance frameworks that enterprise database teams live under share a common structural assumption: that accountability can always be traced to a named individual. Data access policies specify who can see what. Regulatory requirements mandate that sensitive operations be attributable to an authorised person. Incident response procedures begin with identifying the actor.

The separation between technical and intentional correctness makes this worse: even if you wanted to trace the intent behind a given commit, the database’s identity model gives you no path to do so. The agent is invisible to the system of record as a first-class actor. There is no field for it. There is no concept for it. It passes through the identity layer by borrowing someone else’s identity and leaves behind only the record of what that borrowed identity did.

Resource governance faces the same structural failure. Query resource management, workload prioritisation, connection limits – all are organised around principals whose behaviour is modelled and whose resource consumption is expected. An agent operating under a shared credential contributes its load to the profile of that credential with no separation. When the agent begins behaving unexpectedly – generating the compression and recursion patterns that define agent load – the database has no mechanism to isolate, attribute or govern that behaviour at the agent level. It sees only a familiar account doing unfamiliar things.

The Organisational Dimension

There is a final layer to this that sits beyond architecture. The people deploying AI agents are typically not the people who own the systems those agents are acting on. A business unit deploys an AI workflow. That workflow authenticates to a database owned by a platform team operating under its own governance framework. The platform team’s identity model was designed to manage the principals it knows about – its own service accounts, its own users, its own applications. It was never designed to become the identity infrastructure for AI systems built and deployed by other parts of the organisation, under different ownership, operating under different authorisation assumptions. The gap is not just technical. It is jurisdictional.

Where the Industry Is Looking

The direction of travel is visible. Machine identity frameworks are emerging – the conversation at Gartner’s IAM Summit earlier this year centred on the widening definition of “identity” and the operational challenge of governing systems that can no longer be seen clearly. Agent identity registries are being discussed – recent research from the Cloud Security Alliance found that only 23% of organisations have a formal strategy for agent identity management, and fewer than half felt confident they could pass a compliance review focused on agent behaviour. The concept of verifiable agent provenance – a way to assert, at the point of database access, not just which credential is presenting but which agent, acting on whose authority, with what instruction history – is starting to appear in architecture conversations.

But none of this exists at the database layer in any mature form. The database vendors have not shipped it. The standards bodies have not defined it. The compliance frameworks have not required it.

What exists today is a set of workarounds: service accounts with narrowed privileges, application-layer proxy systems that attempt to enforce agent-specific policies before requests reach the database, observability tooling that tries to reconstruct agent identity from upstream signals and inject it into audit pipelines. These are reasonable responses to an immediate problem. They are not solutions to the underlying one.

The underlying problem is that enterprise databases were built around an actor model that no longer describes the full population of actors using them. Until that model expands to accommodate agents as first-class principals (with their own identity, their own audit trail, their own resource governance surface) the systems of record at the centre of every enterprise will continue to operate with a fundamental blind spot.

They will know what happened. They will not know who – in any meaningful sense – made it happen.

This article is part of the Databases in the Age of AI series.

Transactions Assume Intent. Agents Don’t Guarantee It

AI agent committing a database transaction without human intent or authorisation – illustrating the gap between ACID correctness and intentional correctness

There is a principle that every database professional understands, even if they have never articulated it in quite this way.

When a transaction commits, the database trusts that someone meant it.

Not in a philosophical sense. In a practical, operational sense. The entire structure of enterprise transaction design – approval workflows, four-eyes controls, authorisation hierarchies, audit requirements – rests on the assumption that a human being, somewhere in the chain, exercised judgment before that commit happened. The database did not need to verify this. It never had to. The human was always there.

This is becoming visible as agentic AI systems begin to operate directly against systems of record.

ACID guarantees atomicity, consistency, isolation and durability. It guarantees that what you commit is complete, correct relative to the schema, isolated from competing operations and permanent. It does not guarantee that the thing you committed was something anyone should have committed. That was never the database’s problem to solve.

It was the human’s problem. And for fifty years, humans solved it.

What ACID Was Never Asked to Do

The relational transaction model emerged in a world where every database write originated with a deliberate human act. A purchase order entered by a procurement clerk. An inventory adjustment approved by a warehouse manager. A payment authorised by a finance controller. Between the business decision and the commit, there was always a human who understood what they were doing and why.

This created an implicit guarantee that ACID was never asked to provide: the guarantee that the commit reflected a considered, authorised intention.

Database engineers built the four ACID properties to solve technical problems – preventing partial updates, maintaining referential integrity, handling concurrent access, surviving hardware failures. These are real and difficult problems, and the relational model solves them well.

But technical correctness was never the same thing as intentional correctness.

Technical correctness means the transaction left the database in a consistent state. Intentional correctness means the transaction reflected a decision that someone authorised and understood.

For five decades, these were the same thing in practice. A technically correct commit was an intentionally correct commit, because no commit happened without a human in the loop.

Databases were built for humans. Agentic AI changes the equation.

The Problem Is Not Malice. It Is Drift.

AI agents are not attacking systems of record.

They are operating as they were designed to operate (retrieving data, evaluating context, executing actions, committing results). In agentic AI systems, the problem is not that agents behave incorrectly relative to their instructions. The problem is the gap between what an agent was instructed to do and what a human would have authorised.

Consider a straightforward scenario: an AI agent managing supplier payments detects what it classifies as a duplicate invoice and suppresses the payment. The agent has followed its instructions. The transaction it commits – or the one it prevents – is technically correct. The database reflects a consistent state. ACID is satisfied in every respect.

But the invoice was not a duplicate. It was a resubmission for a partially fulfilled order that the agent’s context window did not capture. A human reviewing the same situation would have recognised the pattern immediately, or asked a question before deciding.

The agent did not ask. Agents generally do not ask. Asking is slow, and reducing the need for human intervention is the point.

The commit happened. The database state changed. The business event became real. Nobody authorised it.

This is not a failure mode in the traditional sense. Nothing broke. No constraint was violated. The audit log records a valid transaction, committed by an agent with appropriate credentials, against an account that existed, in an amount that was permitted by policy.

What the audit log cannot record is that the underlying decision was wrong.

The Commit Still Defines Reality

The Moment When Intent Became Implicit

To understand why this exists, it helps to be precise about when the assumption entered the architecture.

As Article 7 of this series argued, the commit is the moment when intent becomes fact. Before that moment, a business decision is a recommendation, a proposal, a signal. After it, the decision is real – legally, financially and operationally.

But the architecture that surrounds the commit was built to verify what was committed, not who decided to commit it or why. Access controls verify identity and permission. Constraints verify schema conformance. Triggers verify referential relationships. Transaction logs record what changed and when.

None of these mechanisms capture the reasoning chain that produced the commit.

In the human era, that was fine. The reasoning chain was in the human’s head. If the commit was questionable, you could ask the person who made it. The audit trail led back to a human who could be held accountable and who, in most cases, could explain their reasoning.

With agents, the reasoning chain is distributed across a model’s context window at the moment of execution – and that context window is gone when the transaction ends.

The database records what happened. The reasoning behind it evaporates.

What the Database Sees

The failure modes that produce this gap vary in character. A language model can misread a retrieved record or act on information it inferred rather than read, committing a well-formed transaction that reflects a decision it effectively invented. In multi-agent architectures, instructions arrive from orchestrating agents rather than humans, and each handoff introduces drift between the original intent and the action that finally reaches the database. Agents operating at machine speed can commit hundreds of transactions before any of them surface in a monitoring dashboard, closing the oversight window faster than controls designed for human timescales can operate.

What these failure modes share is that the database is structurally blind to all of them.

This is not a criticism of the relational model. It is a description of what the relational model was designed to do. The database was designed to record state changes that originated from trusted, authorised actors. It has always assumed that the trust and authorisation frameworks existed outside itself – in the application tier, in the human decision-making layer, in the organisational controls that preceded the commit.

Those external controls are now increasingly operated by systems whose reasoning the database cannot examine.

A transaction committed by an agent with valid credentials, against a permitted resource, within the constraints of its defined permissions, will be indistinguishable in the transaction log from a transaction committed by a human who reviewed the situation carefully and made a deliberate decision.

The database cannot tell the difference. It was never built to.

What was always a reasonable design assumption (that every commit arrived carrying human judgment) has become an architectural gap.

The Gap Has a Name, but Not Yet an Architecture

The industry is beginning to reach toward this problem.

Terms like intent auditing and agent identity layers are starting to appear. The idea that agent actions should carry verifiable provenance – a record not just of what was committed but of the reasoning context in which the commitment was made – is beginning to surface in architectural discussions and early product thinking.

The principle is sound. If the relational model assumes that commits reflect authorised intent, and that assumption is no longer reliable by construction, then something external to the database needs to restore it. Not by slowing agents down to human speed, but by creating a record of the reasoning chain that the database cannot currently capture.

Put simply: intent is now a first-class concern in data systems. The honest answer today is that this architecture does not yet exist in mature form. The controls enterprises are deploying now (credentialing agents as service accounts, scoping their permissions tightly, logging their operations through existing audit infrastructure) are the right immediate responses. They solve the identity problem. They do not solve the intent problem.

An agent with correctly scoped permissions can still commit transactions that no human would have authorised, for reasons no audit log currently captures.

That gap is not closing on its own. It is widening, at the pace agents are being deployed into production.

The relational transaction model has been the foundation of enterprise data integrity for fifty years. It is not failing. It is working exactly as designed.

The problem is that it was designed for a world where human judgment was assumed to be present at every commit, and it has no mechanism to detect when that assumption is no longer being met.

The commit is still the moment reality is made. AI agents are reaching that moment faster, in greater volume, and with less human oversight than any model of enterprise transaction integrity was built to handle.

The database will record what happened. Faithfully and durably. Correct in every technical sense.

What it cannot record is whether anyone should have let it happen.

That is the problem this phase of the series is here to examine. The answer is not yet clear.

This article is part of the Databases in the Age of AI series.

AI Agents Don’t Just Add Load. They Change Its Shape

Abstract visualisation of AI agent database load patterns – compression, expansion and recursion replacing predictable human-paced query traffic

Every capacity model ever built for an enterprise database rests on a quiet assumption.

It was never written down. It was never debated in architecture reviews. Nobody decided to rely on it. It was simply always true.

Users are human. And humans are slow.

Not slow in a pejorative sense. Slow in the precise, measurable sense that matters to systems design. A human reads a screen. A human considers a result. A human decides what to ask next. Between every request and the next one, there is a gap – sometimes seconds, sometimes minutes – in which the database does nothing on that user’s behalf.

That gap has a name in queueing theory: think time. And for the entire history of enterprise computing, think time was not a performance metric anyone optimised. It was simply part of the background.

It turns out that assumption was doing an enormous amount of work.

What Think Time Was Actually Doing

Think time was not merely latency between requests.

It was implicit backpressure. It was distributed flow control. It was, in effect, the admission control mechanism that enterprise databases have always depended on – the only one that required no configuration, no tuning and no operational overhead, because it was provided automatically by the humans using the system.

Those gaps are why connection pools drain and refill rather than exhaust continuously. They are why buffer caches hold useful state between requests. They are why redo logs catch up. They are, in short, why enterprise databases behave predictably under load.

Remove think time, and you do not get the same system running faster. You get a system whose stability model no longer describes the workload it is receiving.

AI agents do not have think time. And this is the foundational problem – not a configuration issue, not a capacity shortfall, but a structural mismatch between the assumptions encoded in every database ever built and the behaviour of the workloads now arriving.

Three Ways Agents Violate the Assumptions

The shift is not simply a matter of agents running faster than humans. It is a change in the shape of the workload that violates the design assumptions of enterprise databases in three distinct ways. The first is already familiar to anyone who has read earlier articles in this series. The second and third are where the genuinely novel risk resides.

Compression

When an agent handles a task, think time collapses toward zero. The arrival rate assumptions baked into every capacity model – the peaks, the breathing room, the quiet periods that allow connection pools to recover and buffer caches to stabilise – are calibrated for human behaviour. They are wrong for agents.

This part is the easiest to see. This is not new ground. Earlier articles in this series have covered the amplification effects that result when agents remove the natural pacing humans impose on production systems. The point here is simply that compression is the first and most visible way agents change load shape – and it is the least of the three problems.

Enterprise databases were designed for demand with gaps. Agents remove the gaps.

Expansion

A human performing a business task issues a bounded number of database requests. The queries are written by a developer, tested, tuned and deployed. One intent produces a known, finite set of database operations.

An AI agent performing the same task does not execute a predefined sequence. It reasons. The database is not answering a question – it is a node in a search tree the agent is traversing. The agent retrieves data, evaluates what it found, decides what additional context it needs and queries again. Each result redefines the next query. The scope of the interaction is determined dynamically, by the reasoning process itself, with no upper bound established in advance.

The result is fan-out: a single high-level task producing a cascade of database interactions that no query governor was configured for and no capacity model includes.

Recursion and Amplification

The third violation is where the consequences are most severe, and where the existing body of database operational knowledge offers the least guidance.

Enterprise databases are built around an assumption that transactions are independent. A transaction arrives, executes, commits or rolls back and leaves. This is not a minor implementation detail. Transaction independence is the foundational assumption on which locking strategies, concurrency controls, resource scheduling and every capacity model ever written for these systems depends.

AI agents with feedback loops break this assumption.

Anyone who has watched a system spiral under retry pressure will recognise the shape of what follows.

An agent that queries a result and then uses that result to determine its next query creates a dependency chain between transactions that the database has no way to model. The database is no longer serving requests from an external actor. It is participating in a feedback loop it does not control, cannot observe and was never designed to influence.

An orchestration framework can spawn sub-agents in response to intermediate results. The resulting transaction volume bears no relationship to the original request.

An agent that retries a failed step, reformulates the question and tries again does not produce the kind of error pattern that timeouts and governors were built to handle. It produces a closed-loop system whose behaviour under stress is the opposite of what open-loop capacity models predict.

Under human load, adding capacity stabilises a system. Under agent-generated feedback loops, adding capacity can accelerate the instability – more concurrency means more simultaneous feedback cycles, which means harder spikes when those loops interact.

The conventional response to a system under stress makes the problem worse, not better. In the limit, it does not stabilise the system. It accelerates its failure.

When Capacity Planning Stops Working

This is the point where capacity planning stops working as a discipline.

If you are responsible for keeping these systems stable, this is the point where the usual playbook stops helping.

The problem is not that the standard responses – add capacity, tune queries, raise connection limits – are wrong in isolation. It is that they were designed for a different kind of system. They treat load as a volume problem. The pressures described here are shape problems.

Connection pool exhaustion under agentic load does not reflect a sizing error. It reflects the collapse of the arrival rate assumptions the pool was built on. Query cost explosions do not reflect insufficient compute. They reflect fan-out patterns that no query governor was asked to anticipate. Contention under agent feedback loops does not reflect a locking configuration problem. It reflects the violation of transaction independence – the assumption every concurrency control in the system was written against.

These are not operational incidents. They are the system reporting that its model of its own workload is no longer valid. It is not just that the model is inaccurate. It is that it no longer corresponds to reality in any meaningful way.

Adding capacity treats the symptom. It does not fix the diagnosis.

Where This Goes Next

The pressures described here are already visible in organisations that have moved beyond early AI demonstrations into production deployments. They are not the future. They are arriving now.

They are arriving first at the SaaS and application layer – the middleware that sits between AI agents and the systems of record. That layer is absorbing some of the initial shock. It provides insulation: rate limiting, query mediation and caching. It imposes the pacing that agents themselves do not have.

But middleware does not eliminate these pressures. It defers them.

Agents are moving toward the systems of record directly – removing dashboards, APIs and every middleware layer that once imposed human-paced demand on systems built for human-paced demand. When the insulation goes, what remains is machine-paced reasoning operating against infrastructure whose stability model was written for a different kind of user.

When that insulation is gone, the assumptions examined in this article will no longer be theoretical. They will be production incidents.

This article is part of the Databases in the Age of AI series.

AI Can Replace Interfaces, Not Systems of Record

AI replacing the interface layer while the database remains the system of record – the commit is where intent becomes enterprise reality

There is a moment in enterprise computing where something changes state permanently.

Not the moment a user clicks a button. Not the moment an application processes a request. Not the moment a model generates a recommendation.

The moment a transaction commits to the database.

That moment is when intent becomes fact. A decision moves from something the system considered to something the business did. A number becomes legally real, financially real, operationally real.

Everything before that moment is interface. Everything after it is record.

The Inversion Nobody Expected

Ben Thompson made an observation recently on Sharp Tech that cuts to the heart of where AI capability actually sits.

AI coding tools, he argued, are a far greater threat to backend developers than frontend ones. This is counterintuitive. Backend engineering has traditionally been the prestigious discipline – systems design, query optimisation, API architecture. Frontend was often treated as a cosmetic afterthought.

The inversion is this: AI turns out to be considerably better at generating backend code than at producing interfaces humans find natural and usable. It can write queries, scaffold APIs, generate orchestration logic. It does these things with real competence.

What it cannot do reliably is create a user experience that feels right. The reason is structural. Backend systems are logical – they have correct and incorrect answers. Interfaces exist for humans, and humans remain the one audience AI cannot fully model. What feels intuitive, what feels trustworthy, what makes a complex system feel approachable: these are not problems with deterministic solutions.

This is why the interface layer has always been the least defensible part of enterprise software. And it is the layer AI is now attacking most effectively.

We Have Been Here Before

AI is not the first technology to transform how humans interact with enterprise systems. It is the latest in a pattern that has been running for decades.

Green screens gave way to web interfaces. Web gave way to mobile. Mobile gave way to SaaS. Each transition changed the surface through which people accessed systems. None of them changed the systems underneath. SAP survived the web. Core banking survived mobile. The ERP survived SaaS.

Interface revolutions change the distance between the user and the system. They do not change what the system fundamentally is.

AI follows this pattern, but compresses it dramatically.

The old world:

User → UI → Application → Database

The emerging world:

User → AI agent → Database

The interface collapses. The orchestration collapses. The system of record remains.

What AI Can Replace

It is worth being clear-eyed about what AI is genuinely capable of displacing, because the list is substantial:

Dashboards and reporting layers
Query and search interfaces
Approval workflows and form-based data entry
The analyst interpreting outputs and building weekly slide decks
Increasingly, the application logic tier itself

These are all, in essence, interfaces between human intent and data. They always were. We built elaborate and expensive software to occupy that space because someone had to translate what people wanted into operations that systems could perform.

The SaaS Confusion

This is the source of the current anxiety in the SaaS market. People observe AI generating application code fluently and conclude that entire software stacks are therefore replaceable. The observation is not entirely wrong. What is wrong is what they think is being replaced.

What AI can generate convincingly is the interface and orchestration layer. That layer was always the most visible part of enterprise software and rarely its most valuable part.

The value resided in the data model, the accumulated business logic baked into the schema over years of operation, the constraint definitions, the audit trails, the edge cases that never made it into the product documentation.

Those things do not live in the interface layer.

They live in the system of record.

What AI Cannot Replace

A system of record is not simply a database in the sense of a place that stores data.

It is the mechanism by which a business event becomes real.

When a bank approves a loan, the credit limit the customer can draw against does not exist until it commits to the core banking system. The AI that assessed creditworthiness, the workflow that routed the application, the interface through which a decision was reviewed – all of these can be replaced or automated entirely.

But the approved limit becomes real only when it commits.

Until then it is a recommendation.

After it, the decision becomes fact.

The same logic applies to a trade execution, a purchase order, an invoice, an inventory movement. In every case, the business event acquires its operational, financial and legal character at the moment of the database commit.

Not before.

AI can recommend actions. AI can initiate actions. AI can, increasingly, execute actions autonomously.

But there remains a moment in every consequential enterprise transaction where something moves from intent to fact.

That moment still belongs to the system of record.

Why Systems of Record Remain the Apex Systems

The enterprise data stack has been redesigned many times over the past two decades.

Data warehouses, data lakes, lakehouses, streaming platforms, vector databases, semantic layers – each a genuine contribution.

And every single one of them is downstream of the system of record.

They consume state that the system of record creates. They analyse facts that the system of record committed.

The data warehouse cannot tell you what an account balance is right now. The lake does not create business events. It receives them.

This hierarchy has persisted through every architectural fashion of the past twenty years. Not because of inertia, but because no alternative has solved the problem the relational system of record solves: making a business event irrevocably real in a form that is consistent, auditable and legally defensible.

AI does not change this.

If anything it reinforces it.

As agents begin operating faster and more autonomously, interacting directly with operational systems rather than curated copies, the place where their actions become real grows in importance.

The insulating middleware is being compressed.

The coupling is tightening.

Everything else – models, agents, orchestration layers – feeds on the system of record.

The system that owns the commit owns reality.

Where This Leaves Us

AI will reshape enterprise software more completely than any previous technology transition.

Interfaces will disappear. Applications will collapse into agents. The cost of building software between users and data will approach zero.

None of that changes what a business actually is.

A business is a continuous stream of commitments – payments, obligations, entitlements, inventory movements, risk assumed.

Each commitment becomes real at the same moment it always has: when it commits to the system of record.

AI makes the path to that moment faster and increasingly autonomous.

It does not make the moment itself optional.

Which raises the question this series will spend its next phase examining:

As AI agents operate at machine speed on production systems, issuing queries that no human wrote and generating actions that no DBA anticipated – how do we allow that to happen without compromising the systems of record that make those commitments real?

That is where we go next.

This article is part of the Databases in the Age of AI series.

The Hidden Cost of Letting AI Agents Query Live Systems

AI agents querying a live enterprise database – illustrating the hidden performance cost of unplanned, machine-generated SQL on production systems

Every DBA has seen it at least once. You are looking at the production database and something feels wrong. CPU is climbing. Logical reads are surging. One or two sessions are consuming far more resources than everything else combined.

You drill down into the SQL.

The query is unfamiliar. It joins more tables than you would expect, sometimes even joining the same table multiple times. The execution plan is complex, the logical reads enormous.

The first question is always the same: where did this query come from?

Often the answer is simple. A new application feature has been released. Somewhere inside it is a query that looked perfectly reasonable in testing. Run once or twice, it behaved well enough.

Production tells a different story.

Now the query is executed repeatedly. Sometimes concurrently. Sometimes triggered by user behaviour the test harness never simulated. Occasionally the query runs long enough for the application to time out, so the user refreshes the page, launching another execution while the first one is still running.

What looked harmless in isolation becomes dangerous when multiplied across real workloads.

But a DBA usually has one advantage: you can usually find the human behind the query.

Someone wanted to know something. Once you understand that intent, the workload can usually be controlled. Run it less often. Move it elsewhere. Rewrite it entirely.

Operational databases survive because their workloads are ultimately bounded by human intent. AI agents change this equation in a subtle but important way.

When the Database Becomes Part of the Reasoning Process

Traditional enterprise applications interact with databases in predictable ways.

An application developer writes the query. It is tested, reviewed, and eventually deployed. Over time the database develops a recognisable workload pattern. DBAs learn those patterns, optimise them, and build operational safeguards around them.

Even complex systems ultimately follow this model. A user action triggers application logic, which triggers a known set of database queries.

AI agents behave differently.

Instead of executing a predefined query pattern, an agent may generate queries dynamically as part of a reasoning process. It retrieves data, evaluates the result, refines the question… and queries again.

In other words, the database is no longer simply answering a question. It becomes part of the mechanism the system uses to figure out the answer.

This subtle shift has an important consequence.

Applications constrain database workloads.

Agents amplify them.

The Amplification Effect

A traditional application might translate a single user action into one or two database queries.

An agent may translate the same request into many.

The agent retrieves information, evaluates it, and then decides what to ask next. It may retry a query with different parameters, join additional tables, or explore alternative paths through the data.

Some systems do this only once or twice. More autonomous agents may repeat the process multiple times in a reasoning loop.

From the database’s perspective, a single human question can now generate many queries. In simple retrieval pipelines this may only be a handful. In more autonomous reasoning systems it can grow to dozens — sometimes even hundreds — as the agent explores the data.

Multiply that pattern across thousands of employees interacting with AI systems, and the database workload begins to look very different from the one the system was originally designed to support.

This is not necessarily a flaw. It is simply how exploratory systems behave. But it does change the shape of the workload interacting with production systems.

Why Traditional Controls Are Not Enough

Experienced DBAs will recognise that production databases already include many mechanisms designed to control runaway workloads.

Connection limits, query governors, resource groups, and timeouts exist precisely because poorly behaved queries can destabilise shared systems.

These controls work well when applications generate predictable query patterns.

What they are less suited to is a workload whose shape is not known in advance.

Agentic systems can generate new queries dynamically, retry failed steps, or explore alternative reasoning paths. The individual queries may not be problematic on their own. The challenge is the emergent behaviour that appears when many such queries interact with a production workload.

The result is a new class of operational uncertainty. In practice this can manifest as unexpected infrastructure consumption, runaway query costs in cloud databases, or production incidents triggered by exploratory workloads interacting badly with operational traffic.

When a traditional query misbehaves, a DBA can usually trace it back to a specific application feature or report. With agentic systems, the activity observed in the database may simply be a side effect of an evolving reasoning process.

Understanding why a query is running becomes much harder.

Enterprise Architectures Will Evolve

For this reason, the architecture implied by many early AI demonstrations is unlikely to survive unchanged in large enterprise environments.

Those demonstrations often show AI agents querying operational databases directly. For simple scenarios, that approach works well enough.

At scale, however, exploratory workloads interacting directly with systems of record create operational and economic pressures that are difficult to manage.

The likely response is architectural evolution.

Instead of allowing agents to query operational systems directly, enterprises will increasingly introduce intermediate layers designed to absorb exploratory behaviour. These layers might include analytical replicas, semantic data services, curated retrieval surfaces, vector indexes, materialised views, or other forms of controlled query infrastructure.

What matters is not the specific technology. It is the architectural separation.

Systems of record remain the authoritative source of enterprise data. But the exploratory behaviour of AI agents will increasingly occur one step removed from those systems.

Until architectures evolve to contain that behaviour, many enterprise AI initiatives will struggle to deliver the level of return on investment that early demonstrations appear to promise.

Not because the models fail, but because the surrounding architecture has not yet caught up with how those models actually behave.

This article is part of the Databases in the Age of AI series.

The Cloud Is Built on Uniformity. Databases Are Not

Cloud infrastructure built on uniformity contrasted with enterprise databases that demand architectural specificity and performance predictability

When engineers build infrastructure, they aim for stability. Systems must behave predictably under load. They must survive success as well as failure. Growth is assumed. If the system is successful, it will be stressed. The challenge is ensuring that growth does not destabilise the structure meant to support it.

Uniform Supply, Irregular Demand

The public cloud addresses this challenge through uniformity. Compute, storage and network capacity are delivered as standardised building blocks. Instance sizes are predefined. Performance characteristics are abstracted. Capacity can be replicated across availability zones and regions with remarkable consistency. This is the operational achievement of Amazon Web Services, Microsoft Azure and Google Cloud. Uniform supply enables hyperscale.

It is an extraordinary achievement. It is also deliberately impersonal.

Enterprise systems of record operate under different conditions. They reflect the behaviour of real customers and real businesses. Demand is rarely smooth. It clusters around product launches, reporting cycles, market opens, regulatory deadlines and seasonal peaks. A transactional database sits at the centre of this behaviour. It absorbs whatever the business generates.

It does not get to choose the shape of that demand.

Cloud infrastructure assumes that workloads can be distributed horizontally across uniform units. Systems of record often experience concentrated pressure at specific moments in time. This is not a flaw, although it can feel like one at 9:01 on Monday when performance dashboards are flashing red. It reflects the difference between uniform supply and irregular demand.

Statistical Guarantees, Deterministic Commit

The distinction becomes clearer when examining reliability. Cloud platforms express resilience statistically. Availability is measured in percentages. Durability in strings of nines. Performance in ranges and envelopes. At fleet scale, these models are extraordinarily effective.

Most of the time, that is enough.

Transactional systems optimise for a different property. When a transaction commits, it must commit correctly and in order. When state changes, it must change once. The authoritative copy of truth cannot be approximate. Modern database engines distribute storage and parallelise reads. But the semantics of correctness still converge at the transaction boundary. Correctness is deterministic even when the infrastructure beneath it is statistical.

Cloud platforms optimise for aggregate behaviour across fleets. Transactional systems optimise for the one transaction that must not be wrong. Both approaches are rational. They are aimed at different targets — and those targets matter most under stress.

Where the Models Converge

The economic model reinforces the distinction. Elasticity allows capacity to expand and contract in response to demand. Stateless services align naturally with this pattern. Horizontal replication tends to make cost proportional to usage.

That is the promise.

Systems of record often scale differently. Reducing latency, increasing memory and tightening the coupling between compute and data frequently precede horizontal distribution. Cloud providers offer very large instance types and strong performance isolation. It is entirely possible to achieve impressive stability and scale in this way — and not infrequently, equally impressive cloud bills.

However, as performance guarantees increase, elasticity typically narrows. Dedicated capacity replaces shared pools. Provisioned throughput replaces best-effort scheduling. Predictability rises. Flexibility declines. These are trade-offs rather than failures. They always have been.

For many years, architects could separate these optimisation philosophies. Operational systems preserved deterministic state transitions. Analytical platforms absorbed variability downstream.

AI Removes the Insulation

AI reduces that separation. Machine agents increasingly interact directly with live operational data rather than curated extracts. Inference engines that are inherently probabilistic now depend more directly on infrastructure expected to be exact. The probabilistic layer now relies on deterministic state in real-time.

This does not invalidate the cloud model, nor does it imply that systems of record do not belong there. It makes the architectural assumptions more visible. Uniform, statistical infrastructure interacts with non-uniform, deterministic state, and the optimisation choices at each layer become more tightly coupled.

Architects must therefore decide explicitly where determinism resides in their stack and what elasticity they are willing to trade to preserve it. Elasticity, isolation and correctness can coexist. But not infinitely, and never without cost.

Someone always pays for certainty.

The cloud is built on uniformity. Databases are built on authority. That authority carries operational consequence.

As AI tightens the feedback loop between them, trade-offs once hidden inside abstraction become explicit design decisions. And explicit design decisions are where responsibility ultimately resides.

This article is part of the Databases in the Age of AI series.

Why We Spent 20 Years Protecting Databases from Analytics (and Why AI Just Broke That Truce)

Twenty years of ETL-era database protection from analytics workloads – and how agentic AI has broken that long-standing architectural truce

8:53am on a Monday

I want to take you back roughly twenty years.

It is 8:53am on a Monday morning in central London and I am sitting at my desk staring at the screen. My coffee is untouched. My palms are sweating.

The ETL job is still running.

If that phrase means nothing to you, it was enough in the mid-2000s to strike fear into the heart of any production DBA. At the time I was the database lead for a SaaS platform serving customers across the UK, most of whom would start logging in from 9am.

The weekend ETL process (Extract, Transform, Load) pulled data out of the operational database, reshaped it and pushed it into the enterprise data warehouse. It ran every weekend and it was supposed to finish long before Monday morning.

It had not.

CPU pinned. Redo logs churning. User sessions beginning to queue.

In a few minutes customers would start calling support. Support would start calling me. And somewhere upstairs, the CEO would notice that his dashboard was still showing last week’s numbers.

I had two options. Let it run and hope it finished before the system buckled under real user traffic. Or kill it and spend the next hour watching rollback potentially take even longer, while guaranteeing that the warehouse would be stale until the following weekend.

How did we end up building systems where that was a normal Monday morning dilemma?

Why We Built the Wall

For the better part of two decades, the industry answered that question in one consistent way: keep analytics away from operational systems.

Transactional databases were designed to process orders, update accounts and record events predictably. Analytical workloads were different. They were heavy, exploratory and often poorly constrained. They scanned large portions of data, built aggregates, joined everything to everything and consumed CPU and I/O in bursts that were difficult to forecast.

Putting the two together in the same system was a recipe for contention.

So we separated them.

We built ETL pipelines. We built data warehouses. Later, we built data lakes and lakehouses. We introduced replication, change data capture and streaming. Each innovation was, in its own way, an attempt to preserve the integrity of the system of record while still making data available for analysis.

This was not fashion. It was defensive architecture.

The separation protected revenue-generating systems from analytical curiosity. It provided workload isolation. It gave operations teams a fighting chance of keeping Monday morning uneventful.

It Was Never Just About Performance

Enterprise environments rarely have a single system of record. A CRM system holds customer interactions. An ordering platform tracks transactions. Billing lives somewhere else. Supply chain somewhere else again.

The warehouse became not just a safety valve for analytics, but a unifying layer. It was the place where disparate operational systems could be reconciled into something coherent.

For years, this model worked.

Dashboards were allowed to be slightly stale. Reports could reflect yesterday’s state. Humans tolerate delay. In fact, they often prefer it. Analysis takes time, and decisions are rarely made in milliseconds.

The truce held because the consumer was human.

AI Changes the Consumer

AI agents change that.

An AI agent does not log in at 9am. It does not wait for a dashboard refresh. It does not tolerate yesterday’s numbers if it is expected to act on what is true right now.

Inference is not reporting. It is decision execution at machine speed.

If an agent is recommending a next action, approving a transaction, adjusting a price or triggering a workflow, the freshness of the underlying data becomes materially important. Close enough is no longer good enough. Staleness is no longer cosmetic. It alters outcomes.

The architectural assumption that analytics can safely run on a delayed copy of operational data begins to fracture.

This does not mean warehouses were a mistake. It does not mean lakehouses are obsolete. It does not mean streaming pipelines were misguided.

It means they were optimised for a different consumer.

For years, we optimised for human analysis. Now we are increasingly optimising for machine-driven action.

That is a different problem.

The Balance of Trade-Offs

For two decades, the answer was clear: keep them apart.

Protect the system of record. Move the data. Analyse it somewhere else. Accept a little delay in exchange for stability and control.

That architecture was forged in moments exactly like that Monday morning at 8:53am, CPU pinned, redo logs churning, business users about to log in.

AI does not invalidate that history. It simply changes the balance of trade-offs.

The truce between operational databases and analytics was built for a world where humans consumed insight.

We are now entering a world where machines consume state.

And that changes the conversation.

This article is part of the Databases in the Age of AI series.

AI Doesn’t Read Dashboards… and That Changes Everything for Databases

AI agents bypassing dashboards to query databases directly – replacing human interpretation with machine-speed access to systems of record

A bank executive opens a fraud dashboard in Microsoft Power BI.

Losses by region, chargeback ratios, transaction velocity trends and a heatmap of anomalous activity. The numbers refresh within minutes. Data flows out of the system of record, is reshaped and aggregated, then presented for interpretation.

This is contemporary analytics: fast and operationally impressive. But it remains interpretive. It explains what is happening, while intervention occurs elsewhere – inside a fraud model embedded in the execution path, deciding in milliseconds whether money moves or an account is frozen.

Reporting systems describe what has already occurred. Even when refreshed every few minutes, they are retrospective. Inference systems are anticipatory. They evaluate the present in order to shape what happens next.

For two decades, enterprise data platforms were built around a deliberate separation between systems of record and analytical platforms. The system of record handled revenue-generating transactions; analytics operated on copies refreshed hourly or even every few minutes. Latency narrowed, but the boundary remained.

AI systems do not consume summaries, however fresh. They make decisions inside the transaction itself. A real-time fraud model does not want a recently refreshed extract; it requires the authoritative state of the business at the moment of decision. When automation replaces interpretation, data freshness becomes a decision integrity requirement. That shift changes the role of the database entirely.

Snapshots ≠ State

The difference is not batch versus real time. It is snapshot versus canonical state.

A snapshot is a materialised representation of state at a prior point in time – even if that point is only moments earlier. It may be refreshed frequently or continuously streamed, but it remains a copy. The system of record contains the canonical state of the enterprise – balances, limits, flags and relationships – reflecting the legal and financial truth when a transaction commits.

In fraud detection, that distinction is decisive. A dashboard can tolerate slight delay because its purpose is explanation. A model embedded in the execution path cannot. It must evaluate current balance, velocity and account status, not a recently materialised representation.

For years, we increased the distance between analytics and the system of record to protect transactional stability. That separation reduced risk in a world where insight followed action.

Automation reverses that order. Insight now precedes action. Once decisions are automated, the gap between a copy of the data and the authoritative source becomes consequential.

When Almost Right Is Still Wrong

If a fraud dashboard is slightly stale, an analyst may adjust a threshold next week. When a fraud model evaluates incomplete or delayed state, the error is executed immediately and repeated at scale.

False declines can lock customers out within minutes. False approvals can leak substantial losses before discrepancies surface in reporting. Automation compresses time and amplifies mistakes because there is no interpretive buffer.

Real-time intervention is inevitable. Competitive pressure and regulatory scrutiny demand it. But once decisions are automated, tolerance for architectural distance shrinks. A delay harmless in reporting can be material in a decision stream. A dataset “close enough” for analytics may be insufficient for automated intervention.

The risk is not that dashboards are wrong; it is that forward-looking systems may act on something almost right.

Databases in the Age of Intervention

When fraud detection becomes automated intervention rather than retrospective analysis, the requirements on the data platform change. Freshness is defined at the moment of decision, not by refresh intervals.

Replication patterns take on new significance. Asynchronous copies and downstream materialisations were designed to protect the system of record. They optimise scale and isolation, but every layer introduces potential lag or divergence. For reporting, that trade-off is acceptable. For automated decisions in revenue-generating workflows, it becomes risk.

Workload separation also looks different. When analytics is retrospective, distance protects performance. When inference is embedded in operational workflows, proximity to live transactional state matters. The challenge is enabling safe, predictable access without compromising correctness.

Fraud detection is simply the clearest example. Dynamic pricing, credit approvals, supply chain routing and clinical triage all follow the same pattern. The model is not generating a report about what happened; it is evaluating the present to influence what happens next.

For decades, enterprise architecture assumed intelligence followed events. As AI systems become anticipatory and automated, intelligence precedes action. The database is no longer simply the foundation of record-keeping.

It becomes part of how the future is decided – whether we are comfortable with that or not.

This article is part of the Databases in the Age of AI series.

Databases Were Built for Humans – AI Agents Change the Equation

Enterprise databases built for human-paced interaction now facing agentic AI that removes the assumptions of think time, session boundaries and deliberate intent

For more than a decade, the industry has been preparing for a data explosion.

Zettabytes. Exponential curves. Hockey sticks on slides. Whether it was IDC’s DataSphere forecasts or countless vendor keynotes, the message was consistent: the amount of data created and stored worldwide was about to grow very, very fast.

And to be fair, that part largely went to plan.

Enterprises adapted. Storage scaled out. Cloud elasticity became normal. Analytical workloads were pushed away from systems of record. The industry did the work required to survive – and even thrive – in a world of exploding data volumes.

What almost nobody questioned, however, was a much quieter assumption baked into all of that planning.

The Assumption Nobody Revisited

All of those forecasts, explicit or implicit, assumed that the users of enterprise systems would remain human.

Humans are slow. Humans are bursty. Humans sleep.

Even power users have natural limits, predictable working patterns and an instinct for self-preservation when systems start pushing back. Entire generations of database design, connection management and capacity planning quietly depend on those characteristics.

It wasn’t a bad assumption. It was a reasonable one. Until it wasn’t.

A Step-Change, Not a Trend

What has changed is not just how much data exists, but who – or what – is accessing it.

AI agents introduce a new class of user into enterprise computing: non-human, machine-speed actors operating directly against application logic and data sources. This isn’t a continuation of an existing trend. It’s a step-change.

You’re not adding more users along the same curve. You’re changing the curve itself.

The data explosion was predicted. The user explosion – at least in this form – was not.

Why AI Agents Break Old Rules

AI agents don’t just behave like very enthusiastic humans.

They are fundamentally different:

Speed: they operate at machine speed, turning milliseconds into meaningful units of work
Relentlessness: they don’t pause, sleep or slow down unless explicitly forced to
Unpredictability: agentic workflows fan out, retry, amplify and cascade in ways humans never could

These aren’t “power users”. They’re closer to autonomous load generators.

When Agents Hit Systems of Record

Critically, AI agents don’t want last night’s report.

They want now.

That pulls them towards operational systems of record – the RDBMS platforms that were carefully protected for the last twenty years from exactly this kind of access pattern. Read replicas help, until they don’t. Caches help, until coherence matters. Copy lag becomes a business problem, not a technical detail.

The long-standing truce between OLTP and everything else is under strain.

Capacity Planning Enters the Chaos Zone

Traditional infrastructure planning assumes that tomorrow looks broadly like yesterday, just a bit bigger.

AI agents break that assumption.

Sudden workload spikes. Non-linear fan-out. Cost curves that move faster than budgeting cycles. Organisations are forced into an uncomfortable choice: over-provision aggressively and accept unpredictable cloud bills, or under-provision and risk outages in systems that now sit directly on critical decision paths.

Capacity planning stops being optimisation. It becomes risk management.

This Is Already Happening

None of this is theoretical.

Organisations are already talking openly about AI agents as part of their workforce – not as tools, but as actors performing work at scale.

Enterprises are comfortable counting tens of thousands of AI agents as “workers”, but it shouldn’t be surprising when those workers behave very differently to humans – and place very different demands on the systems beneath them.

The Equation Has Changed

The data explosion followed the forecast.

The explosion in users did not.

Databases were built for humans – slow, bursty, predictable ones – and that assumption shaped everything from architecture to cost models. AI agents don’t fit that mould… and pretending they do is how organisations drift into outages, runaway costs or both.

Databases were built for humans. AI agents didn’t get the memo – and they’re already in production.

This article is part of the Databases in the Age of AI series.

Inferencing Is a Database Problem Disguised as an AI Problem

AI inferencing reframed as a database performance problem – latency, concurrency and data access patterns under real-time machine workloads

I have a habit of becoming interested in technology trends only once they collide with reality. Flash memory wasn’t interesting to me because it was new – it was interesting because it broke long-held assumptions about how databases behaved under load.

Cloud computing wasn’t interesting to me because infrastructure became someone else’s problem. It became interesting when database owners started making uncomfortable compromises just to get revenue-affecting systems to run acceptably in the cloud. Compute was routinely overprovisioned to compensate for storage performance, leading to large bills for resources that were mostly idle. At the same time, “modernisation” began to feel less like an architectural necessity and more like a convenient justification for expensive consultancy services.

And now, just when I thought flashdba had nothing left to say, AI is following the same path.

We’ve Seen This Movie Before

For the last couple of years, most of the attention has been on training. Bigger models, more parameters, more GPUs, massive share prices. That focus made sense because training is visible, centralised and easy to reason about in isolation. But as inferencing starts to move up into the enterprise, something changes.

In the enterprise, inferencing stops being an interesting AI capability and starts becoming part of real business workflows. It gets embedded into customer interactions, operational decisions and automated processes that run continuously, not just when someone pastes a prompt into a chat window. At that point, the constraints change dramatically.

Enterprise inferencing is no longer about what a model knows. It is about what the business knows right now. And that is where things begin to feel very familiar to anyone responsible for systems of record.

Because once inferencing depends on real-time access to authoritative operational data, the centre of gravity shifts away from models and back towards databases. Latency matters. Consistency matters. Concurrency matters. Security boundaries matter. Above all, correctness matters.

This is the point at which inferencing stops looking like an AI problem and starts looking like what it actually is: a database problem, wearing an AI costume.

Inferencing Changes Once It Becomes Operational

While inferencing remains something that sits at the edge of the enterprise, its demands are relatively modest: a delayed response is tolerable… slightly stale data is acceptable. If an answer is occasionally wrong, the consequences are usually limited to a poor user experience rather than a failed business process.

That changes quickly once inferencing becomes operational. When it is embedded directly into business workflows, inferencing is no longer advisory… it becomes participatory. It influences decisions, triggers actions and – increasingly – operates in the same execution path as the systems of record themselves. At that point, inferencing stops consuming convenient snapshots of data and starts demanding access to live context data.

What is Live Context?

By live context, I don’t mean training data, feature stores or yesterday’s replica. I mean current, authoritative operational data, accessed at the point a decision is being made. Data that reflects what is happening in the business right now, not what was true at some earlier point in time. This context is usually scoped to a specific customer, transaction or event and must be retrieved under the same consistency, security and governance constraints as the underlying system of record. In other words, a relational database. Your relational database.

Live Context gravitates towards RDBMS systems of record. It does not appear spontaneously – it is created at the moment a business state changes: when an order is placed, a payment is authorised, an entitlement is updated or a limit is breached, that change becomes real only when the transaction is committed to the RDBMS. Until then, it is provisional.

Analytical platforms can consume that state later, but they do not create it. Feature stores, caches and replicas can approximate it, but they do so after the fact. The only place where the current state of the business definitively exists is inside the operational production databases that process and commit transactions.

As inferencing becomes dependent on live context, it is therefore pulled towards those databases. Not because they are designed for AI workloads, and certainly not because this is desirable, but because they are the source of truth. If an inference is expected to reflect what is true right now, it must, in some form, depend on the same data paths that make the business run.

This is where the tension becomes unavoidable.

Inferencing Is Now A Database Problem

Once inferencing becomes dependent on live context, it inherits the constraints of the systems that provide that context. Performance, concurrency, availability, security and correctness are no longer secondary considerations. They become defining characteristics of whether inferencing can be trusted to operate inside business-critical workflows at all.

This is why enterprise AI initiatives are unlikely to succeed or fail based on model accuracy alone. They will succeed or fail based on how well inferencing workloads coexist with production databases that were never designed, built or costed with AI in mind. At that point, inferencing stops being an AI problem to be delegated elsewhere and becomes a database concern that must be understood, designed for and owned accordingly.

This article is part of the Databases in the Age of AI series.