AI · Systems Architecture · Enterprise

Agents Are Not Infrastructure

On the most expensive misunderstanding in enterprise AI

Bhavana Chamoli May 2026 950 words

There is a moment in almost every enterprise AI engagement when someone in the room says: we should just use agents for that.

The "that" varies. Sometimes it's reconciliation. Sometimes it's compliance monitoring. Sometimes it's customer onboarding. The specifics don't matter. What matters is the assumption underneath the sentence — that an agent is a solution you reach for the way you reach for a database or an API. A component you drop into an existing system to handle a workflow that was previously manual.

This assumption is wrong. And the cost of it is not visible in any one deployment. It accumulates quietly, across many deployments, until an organization has spent eighteen months and several million dollars on a system that works in demo and fails in production.

What an agent actually is

An agent is a function with expanded scope. It has inputs. It has a processing layer — in most enterprise deployments, a large language model. It has outputs. It can call other functions, maintain state across calls, and make decisions based on context.

One property makes it fundamentally different from every other component you have ever deployed: non-determinism at execution level.

The property that changes everything
Deterministic
Traditional function
Input: {"amount": 5000, "account": "A1"}
Output: {"approved": true} — always
Testable · Debuggable · Auditable
Non-deterministic
LLM-based agent
Input: {"amount": 5000, "account": "A1"}
Run 1: {"approved": true, "reason": "within limit"} Run 2: {"approved": true, "reason": "low risk profile"} Run 3: {"approved": false, "reason": "flag for review"}
Probabilistic outputs across identical inputs

Same input. Three different decisions. This is not a bug — it is the architecture.

Give a traditional function the same inputs and it returns the same output. Every time. That determinism is not incidental — it is the foundational assumption on which all software system design rests.

Give an agent the same inputs and it may return different outputs across runs. This is not a bug. It is the fundamental nature of LLM-based reasoning. Stochasticity is built into the architecture.

What breaks

That single property breaks three things most enterprise teams don't realize they're relying on until they're gone.

Three things non-determinism breaks
Testing
Traditional testing asserts fixed outputs for given inputs. An agent's outputs are probabilistic. You cannot write a unit test that asserts an agent will always produce the same decision for the same transaction.
You can test tendencies — not certainties
Debugging
When a traditional system fails, you trace the failure through the call stack. When an agent produces a wrong output, the same input tomorrow may produce the correct output. The failure is real but not reliably traceable.
The error may never reproduce
Audit trails
In financial services and any regulated environment, you need to explain every decision the system made. A deterministic system produces a complete audit trail by construction. An agent cannot reliably reconstruct why it decided what it decided.
Compliance requires determinism

These are not edge cases. They are the core requirements of any enterprise system in a regulated environment.

What must exist before the agent

The infrastructure question is not whether you need it. You always need it. The question is whether you built it before or after you deployed the agent.

"Before deployment, infrastructure is an investment. After deployment, it is an emergency."

The required stack — bottom to top
1

Unified data layer

Canonical schema across all source systems. An agent reasoning over three different field names for the same concept will produce inconsistent outputs — not because the model is bad but because the inputs are inconsistent.

2

Access controls

Enforced at the data layer, not assumed at the agent layer. An agent with access to data it should not have will eventually use that data. Not maliciously. Probabilistically.

3

Audit log

Every input, every output, every tool call captured. Not to explain the reasoning — but to establish what happened for compliance purposes. This is not optional in financial services.

4

Human-in-the-loop checkpoints

At every decision boundary where non-determinism creates unacceptable risk. The agent handles the volume. The human handles the exceptions where the stakes of a wrong decision exceed the value of automation.

5

Fallback paths

When the agent fails — and it will, because all systems fail — what happens? If the answer is "we don't know yet," the system is not ready for production.

↓ deploy the agent here, not before

The agent

Now it has something reliable to act on. Now it can fail gracefully. Now it can be audited. Now it is production-ready.

Build this first. Then deploy the agent. The sequence is not optional.

Why this keeps happening

The gold rush creates pressure to ship. Every week there is a new announcement — a billion-dollar joint venture, a new model release, a competitor who claims to have deployed agents across their entire back office.

Skipping the infrastructure layer is rational under that pressure. The agent works in demo without it. The data is clean enough for a demo. The failure modes don't surface in a controlled environment. By the time they surface in production, the funding is secured and the team has moved on to the next initiative.

This is not a failure of intelligence. It is a failure of incentive alignment. The people who skip infrastructure are not making a technical error. They are making a rational response to a set of pressures that reward demo performance over production reliability.

The result is a generation of enterprise AI deployments that look like progress and function like technical debt.

Agents are not a replacement for infrastructure. They are the most demanding consumer of infrastructure you will ever deploy — because they will probe every gap in your data layer, every ambiguity in your schema, every missing access control, with a thoroughness that no manual process and no traditional software ever could.

Build the foundation. Then deploy the agent.

About the author
Bhavana Chamoli

AI strategist and enterprise architect with experience building data and AI systems at institutional scale, including at MIO Partners (McKinsey's hedge fund office) and in support of BNY Mellon's data modernization program. MBA, Columbia Business School. MS, Carnegie Mellon University. Founding Partner, Chamoli & Pulliam Partners.