Most agent projects fail in the same place: nobody decided what the agent is allowed to do on its own. That is an engineering decision, not a prompting one.
Every agent demo works. That is the trap. You give it a question, it reasons out loud, it produces something plausible, and everyone in the room feels the future arriving. Then you point it at real data, with real customers on the other end, and it books the wrong appointment, refunds an order twice, or confidently tells someone a policy that does not exist.
The instinct at that point is to fix the prompt. Add more instruction. Add examples. Add a stern paragraph about never inventing information. This works about as well as writing a longer memo to fix a broken process.
The actual problem is that nobody drew a line around what the agent may do without asking. Until that line exists, the model is not the risk. the absence of a boundary is.
Before writing any agent code, we answer three things with the client, in writing:
Those three answers determine the data model, the tool permissions, the queue design, and the interface. They are not a policy document you write afterwards. They are the spec.
An agent without an escalation path is not autonomous. It is unsupervised.
There is a meaningful difference between telling a model not to do something and making it structurally unable to. If refunds above a threshold require approval, that rule belongs in the tool layer. the agent literally does not have a callable action that issues one. It can request. A human approves. The record shows who did what.
This sounds obvious written down, and it is skipped constantly, because prompt-level rules are faster to add and feel equivalent. They are not equivalent. One is a preference; the other is a constraint.
The first time an agent does something surprising in production, somebody will ask what happened. If your answer is a shrug, the project is finished regardless of how well it performs on average.
So traces, logs, and evals go in from day one, not after the first incident. Every decision the agent took, the context it had, the tools it called, and the output it produced. Not for compliance theatre. because that record is the only thing that lets you improve the system instead of guessing at it.
On one support build, the value of that logging turned out to have nothing to do with the AI. It showed the client which questions customers actually asked, in what volume, at what hour. They changed three things about their product because of it.
A well-bounded agent is unremarkable to use. It answers the routine things instantly, it hands over the rest with everything the human needs, and when you ask it to do something outside its remit it says so rather than improvising. It is boring. Boring is the goal. boring means the system is doing the work and nobody is watching it nervously.
If your agent project has stalled at the demo stage, the missing piece is almost never a better model. It is a decision nobody has made yet about where the agent stops.
