Building an AI agent that works in a demo has become relatively simple.
A team can connect a language model to a few tools, give it a goal and watch it book a meeting, file a ticket or summarize a workflow. The harder question is what happens when that same agent runs thousands of times a day against real systems, real users and real business consequences.
That is where many agentic AI projects run into trouble. The model may be impressive, but production systems need more than a capable model. They need boundaries, contracts, monitoring and clear rules for what an agent is allowed to do.
Sreekanth Ramakrishnan has spent much of his career building systems meant to stay dependable at scale. A senior software engineer with experience in platform engineering, API systems and service contracts, he focuses on the infrastructure that makes software predictable under pressure.
His book, Contract-Driven AI Systems, argues that AI agents earn trust from the engineering around them, not just from the model at their center.
The demo is not the product
A demo proves that an agent can succeed once. Production asks whether it can behave safely over and over again.
That difference matters. Real production environments are messy. Inputs vary, tools time out, permissions change, systems return unexpected errors and the same request may run thousands of times with slightly different data.
An agent that looks reliable in a controlled setting can start making small mistakes when it operates continuously. Those mistakes may not look dramatic at first. They may appear as duplicated actions, missed callbacks, wrong tool choices or incomplete handoffs. Over time, they can create operational risk.
“A demo proves an agent can succeed once,” Ramakrishnan says. “Production asks whether it can fail safely a thousand times. That is a completely different question.”
Reliability lives in the boundaries
Ramakrishnan’s approach is rooted in contract-driven design.
Instead of trusting an agent to behave correctly because the prompt tells it to, the system defines what the agent can do through explicit contracts. Those contracts describe the shape of each request, the permissions attached to each tool, the expected response and the limits on what an action may change.
That framing treats the agent as one part of a larger system, not the whole system.
The model may choose which step to take, but the surrounding infrastructure determines whether that step is allowed, whether the request is valid and whether the result can be trusted.
“Prompts are suggestions. Contracts are enforcement,” Ramakrishnan says.
That distinction becomes important when an agent can interact with real tools, customer records, financial systems or operational workflows. The more an agent can affect the outside world, the more important the boundary becomes.
Actions need guardrails
The risk changes when an AI system stops only answering questions and starts taking action.
A chatbot that gives a wrong answer may waste time. An agent that issues a refund, cancels an order, changes a record or emails a customer can create a problem that is harder to reverse.
That is why production agents need guardrails designed into the action layer. Operations should be logged, reviewed where necessary and built so that retries do not cause duplicate effects. Where possible, actions should be reversible or limited until a human approves them.
“The question I always ask is what happens when this goes wrong, because it will,” Ramakrishnan says. “Can we undo it? Can we see that it happened? Can we stop it from happening a thousand more times before morning?”
If the answer is no, the agent may not be ready to take that action alone.
Async work makes agents harder to operate
Some of the hardest failures appear when agents run asynchronously.
A simple agent that performs one step and waits is easy to follow. A production agent may launch several tasks, wait on external systems, receive callbacks, retry failed actions and finish work minutes or hours later. Those steps may complete out of order, or not at all.
Without the right infrastructure, it becomes difficult to answer a basic question: what is the agent doing right now?
That is why observability is central to agent reliability. Teams need traces that record decisions, tool calls, retries, failures and final outcomes. When something breaks, they should be able to reconstruct the path instead of guessing.
An unattended agent without visibility is not a productivity tool. It is an operational blind spot.
Trust has to be engineered
The future of AI agents will not be decided only by model quality.
Better models will help, but they do not remove the need for contracts, tests, permissions, logs and escalation paths. In production, trust depends on what the system can prove, what it is allowed to touch and what happens when it fails.
That is the shift Ramakrishnan argues for. The model may be the most visible part of an AI agent, but the durable work is the infrastructure around it.
As models continue to change, companies need agent systems that remain reliable even as the underlying model improves or gets replaced. That means designing around enforceable boundaries rather than assuming the next model will make every decision safe.
A better model may give a better guess. Reliable systems come from deciding what the guess is allowed to do.