Agents need exits
The most important design decision in an agent is not what it can do — it is how it stops.
Every agent demo looks the same: give it a goal, watch it plan, applaud when it finishes. What the demo never shows is the fourth run, where the API times out, the plan loops, and the agent burns forty tool calls politely apologizing to itself.
Production agents are not defined by their happy path. They are defined by their exits — the explicit places where the system decides to stop, hand off, or ask. I design those first, before the prompt, before the tools.
An agent without an exit is not autonomous. It is unsupervised.
Three exits every agent gets
Budget exits cap cost and iterations per goal. Confidence exits force a handoff when the agent cannot verify its own result. Human exits route anything irreversible — payments, deletions, sends — through a person, every time.
Exit conditions:
- spent > budget — budget exit
- confidence < 0.7 — verify or hand off
- action is irreversible — human approval
The pattern is boring, and that is the point. Boring failure paths are what let the interesting parts — planning, tool use, memory — run without a babysitter. Teams do not trust agents that always finish. They trust agents that know when to quit.
This shipped in the BusinessFrame agent fleet — exit rules cut runaway sessions to zero within a week.