Useful agents need controlled tool access, context, workflow state, observability, escalation paths, and clear operational boundaries.
Engineering Perspective · 4 min read · CognitivZen Editorial Team
The demo usually works. Someone connects a capable model to a few APIs and asks it to handle a support ticket from start to finish. It reads the account, checks the order, issues the credit and writes the reply. The room is impressed. Once the same system meets real traffic, repeated actions and unexpected edge cases expose gaps that the demonstration never had to handle.
For many bounded tasks, current models can already produce convincing results. Production failures often come from the surrounding system: permissions, workflow state, monitoring, exception handling and controls that were outside the pilot scope.
An agent that does real work needs five things the demo quietly skipped.
Controlled tool access. In the demo the agent had an API key with broad permissions because that was fastest. In production it needs a scoped credential per tool, a list of what it may call and under what conditions, and a hard stop on anything that moves money or changes a customer record without a second check. The question to ask of any agent design is simple: what is the worst single call this thing can make, and who authorized it?
Explicit workflow state. Agents that reason freshly from conversation history every turn can re-derive decisions they have already made. Repeated-action failures often trace back to missing or poorly managed workflow state. Keep state outside the model — what has been attempted, what succeeded, what is pending and what is terminal — and provide it as fact rather than asking the agent to reconstruct the story.
Observability that matches how agents fail. Application logs tell you a call was made. They do not tell you why the agent thought it should make it. You need the reasoning trace, the tool inputs and outputs, the state at each step, and the ability to replay a run. Teams that skip this spend their first production incident guessing.
Escalation paths. Every agent needs a defined way to stop and hand over. Not an error — a handoff, with enough context attached that the person picking it up does not start from nothing. Without an escalation path, the agent may guess or fail, and either outcome can create avoidable risk.
Operational boundaries. Rate limits, spend caps, a maximum number of steps per task, a kill switch that someone on the operations team can reach without a deploy. These feel like bureaucracy until the first time a loop runs overnight.
Pilots run on clean inputs, generous supervision and a small number of cases. The cases are usually the ones someone picked because they demonstrate well. Production brings the long tail: the malformed record, the customer who is also a supplier, the order that was partially refunded by a human two weeks ago through a different system.
The gap is not that the model gets worse. It is that the proportion of decisions requiring judgment about context the agent cannot see goes up sharply. A high headline accuracy rate sounds strong until you examine the errors, their consequences and whether anyone would notice them quickly.
If you are starting an agentic project, the ordering that tends to work is counter-intuitive. Build the boundaries before the capability.
Start with the tool layer: a small, well-specified set of actions with clear permissions, each one independently testable without the model in the loop. Then the state store. Then the trace and replay tooling. Only then connect the model, and connect it first in a read-only mode where it proposes actions that a person approves. Review its proposals over a representative period. They reveal weak reasoning before the system is allowed to take consequential action.
This is slower to a first demo and considerably faster to something you can leave running.
Before approving an agentic project, ask what happens when it is wrong. Not whether it will be — it will be. What happens. Who finds out, how fast, and what does it cost to undo.
If the answer involves a person noticing something odd in a report at the end of the month, the project is not ready for production regardless of how well the model performs.