AI agents have become remarkably good at demos. Give an agent a clear prompt, a controlled environment, predictable inputs, and a defined set of tools, and the results can look almost flawless. It can reason through a task, call APIs, use tools, inspect results, recover from mistakes, and eventually produce the expected output. The real challenge begins when that same agent moves into production. In a demo, you may run an agent ten or fifty times against carefully selected inputs. In production, it may execute hundreds or thousands of times, interacting with external systems, unpredictable data, APIs, databases, authentication layers, and other services. That is where failures start appearing. The important realization is that an agent can be highly effective at individual steps while still being unreliable at completing an entire workflow.
Consider an agent that is 95% effective at every individual step. A 95% success rate sounds excellent. But production workflows rarely consist of a single action. If a task requires 29 sequential steps, the probability of getting every step right is approximately 0.95²⁹, or around 23%. The calculation is simplified, but it illustrates the core problem with multi-step agentic workflows: reliability compounds across the entire chain. A model can perform extremely well at individual decisions and still produce a surprisingly low end-to-end success rate when the workflow becomes long enough. This is why evaluating an agent only through model accuracy or benchmark scores can be misleading. The real question is not simply, "How capable is the model?" It is, "How reliably can the complete system finish the task?"
Modern coding agents offer an important lesson here. Their effectiveness does not come only from the underlying model. They can execute a large number of steps, inspect results, identify failures, retry operations, modify their approach, and repair problems along the way. The system has mechanisms that allow it to recover. When a developer uses an agent locally, there is also usually a human available to provide feedback or restart a process. A production agent does not have that advantage. It can run continuously without someone watching every execution. That creates one of the most dangerous failure modes in agentic systems: the quiet failure.
A quiet failure occurs when something goes wrong but the failure is not communicated clearly enough for the agent or the surrounding system to react. The agent might receive an unclear error, continue with an invalid state, retry an operation that cannot succeed, or eventually produce an incorrect result. The problem is therefore not simply that the agent failed. The deeper problem is that the system failed to make the failure visible and actionable.
This is why production agents need loud failures. Traditional distributed systems already follow this principle through status codes, exceptions, timeouts, circuit breakers, logs, and monitoring. AI agents need the same discipline. Instead of returning a vague message such as "Bad request," provide information that helps the agent understand what needs to change. For example, "Invoice date must use YYYY-MM-DD format" gives the model a clear correction path. An error message such as "Invalid invoice_date. Expected format: YYYY-MM-DD. Received: 12/08/26" is even more useful because the model can use that information to correct its next action.
Errors should also be classified according to whether they are recoverable. A transient error could be a temporary API failure, network timeout, or unavailable service. A persistent error could be invalid input, an unsupported operation, invalid authentication, or a resource that does not exist. These situations should not trigger identical behavior. A transient failure may justify another attempt. A persistent failure may require changing the input or stopping the workflow altogether. If an agent cannot distinguish between these conditions, it can waste steps repeatedly attempting something that will never work.
This changes the role of error messages in agentic architectures. In traditional software, an error is primarily diagnostic information for developers or operators. In an agentic system, the model itself may consume that error and decide what to do next. The error therefore becomes part of the agent's interface. The objective is not simply to tell the agent that an operation failed. The objective is to explain what failed and, where possible, provide enough information for recovery.
Another major problem appears when agents repeatedly retry failed operations: context contamination. Imagine an agent calls a tool and receives an error. It retries and receives another error. The previous responses, failed attempts, intermediate information, and new attempts continue accumulating in the context. After several retries, the agent is carrying a large amount of information about things that did not work. Much of that information may have little value for the next attempt. For transient failures especially, retaining every failed attempt can make the context unnecessarily large and potentially make recovery harder.
A useful principle is that a failed attempt should not automatically become permanent knowledge. If an external service temporarily returns a 500 error, the agent may not need every detail of that failed attempt when it tries again. Depending on the architecture, clearing or minimizing irrelevant failed context can provide a cleaner starting point for recovery. Context management therefore becomes an important part of agent reliability, not simply a way to reduce token consumption.
Step count is another metric that deserves much more attention in production. Suppose an agent normally completes a workflow in ten steps. After deployment, that number gradually increases to twelve, fifteen, and eventually twenty. The agent may still be completing the task, but the rising step count is an early warning signal. Something may have changed in the environment. An external service may be returning less predictable responses. A tool may be failing more frequently. The agent may be entering unnecessary retry loops. Or a change to the workflow may have made the reasoning process longer.
The important point is that a longer execution is not necessarily a failure, but it can be an indication that the system is becoming less efficient. It also directly affects cost. More steps generally mean more model calls, more tool calls, more tokens, more latency, and more opportunities for failure. Step count therefore becomes both a reliability metric and a cost metric.
Production systems also need boundaries around retries. An agent should not have unlimited freedom to continue trying to recover from a problem. Maximum steps, maximum retries, execution time, token consumption, and cost per task can all be useful controls. The exact limits depend on the workflow, but the principle remains the same: an agent needs a point at which it decides that continuing is no longer useful.
This is where guardrails become important. The model should not be responsible for every decision in the system. Deterministic validation gates can sit around the agent and enforce rules that can be expressed in code. A workflow might look like Agent → Validation Gate → Tool → Result → Validation Gate → Agent. The gates can check whether required fields exist, whether the input follows the expected schema, whether an action is permitted, whether the external system returned an expected response, or whether the workflow has exceeded its retry limit.
The model should handle decisions that require reasoning, while deterministic parts of the system should enforce deterministic rules. This separation can make an agent significantly more predictable. Instead of asking an LLM to determine whether a date follows a specific format, validate the format programmatically. Instead of asking the model whether a required field exists, let the system check it. Give the agent the parts of the workflow where reasoning adds value.
This also means that production agents should not be designed around perfect inputs. Test environments are often clean. Production environments are not. An invoice-processing workflow might receive missing fields, unexpected date formats, duplicate invoices, authentication failures, service outages, different schemas, network failures, or tool errors. The model may be perfectly capable of processing a valid invoice, but the production workflow has to deal with everything surrounding that invoice as well.
That leads to a broader shift from prompt engineering toward runtime system design. Writing a good prompt is still important, but it is not enough. A production agent needs an architecture that can handle unpredictable inputs and recover from failures. Instead of asking, "How do I write the perfect prompt?" the more useful question is, "How do I design a system that helps the agent recover when the prompt cannot predict reality?"
This is also where teams building production AI systems, including GeekyAnts, have to think beyond the model itself. The difficult part is often not getting an agent to perform a task once. It is designing the surrounding workflow so that the agent remains observable, recoverable, and predictable when real-world conditions introduce failures.
One interesting architectural approach is to avoid putting an agent directly inside every part of a repetitive workflow. Consider processing 200 invoices. A naïve architecture might run an agent separately for each invoice, with every invoice triggering multiple model and tool calls. The number of steps can quickly become large. A different approach is to use an extraction layer to process the collection first, identify the small number of problematic invoices, and then use the agent only for those exceptions. The system could extract information from all 200 invoices, identify eight problematic records, generate targeted fixes for those eight, and reprocess them.
This creates an important pattern for agentic systems: use deterministic processing for the predictable majority and agentic reasoning for the exceptions. The objective is not to eliminate agents from the workflow. It is to use them where their reasoning capabilities provide the most value. This can reduce the number of execution steps while also making cost and performance more predictable.
The strongest agentic systems also demonstrate another important capability: self-repair. Instead of simply following a predefined sequence, the agent observes the result of its actions. When something goes wrong, it identifies the cause, changes its approach, and tries again when recovery makes sense. Production systems should adopt this pattern where appropriate. The agent should have enough information to determine what happened, why it happened, whether it can fix the problem, whether it should retry, whether it should stop, or whether it should escalate the issue.
For teams operating AI agents in production, three metrics are particularly valuable. The first is the rate of quiet failures. How many failures are happening without being properly surfaced to the agent or the monitoring system? The second is median step count. How many steps does the agent typically need, and is that number increasing over time? The third is cost per successful run. A production agent should have a reasonably predictable cost profile. If similar tasks sometimes cost a small amount and sometimes become several times more expensive because of retries, the system becomes difficult to operate at scale.
The goal should not necessarily be to make every agent 100% successful. AI agents are probabilistic systems, and even powerful models can struggle with complex multi-step workflows. A more practical goal is to build systems that are observable, recoverable, bounded, predictable, cost-controlled, and safe when they fail.
That changes how agent reliability should be measured. The real unit of reliability is not an individual model response. It is the entire workflow.
A production agent is effectively a combination of the model, prompt, tools, context, guardrails, error handling, observability, and recovery mechanisms. If one of these components is poorly designed, the overall system can become unreliable even when the underlying model is extremely capable.
The next stage of agentic development will therefore not be defined only by which model performs best on a benchmark. It will be defined by how well the surrounding system handles everything that happens after the model makes a decision.
A good demo proves that an AI agent can succeed.
A production-ready system proves that it knows what to do when it doesn't.
Watch here!
Top comments (0)