Typed Exits
By the end of this module
- Name the ways an agent run can end, beyond worked and failed
- Tell apart two endings that look identical to the person on the other side
- Explain what a closed vocabulary lets you say that an open one cannot
Definition
The agent loop module ended on an unfinished thought: the loop exits for several different reasons and only some of them mean the work was done. This module is about treating those endings as a vocabulary rather than as an afterthought.
An exit is a typed terminal. Every run of an agent reaches exactly one, and the type says what kind of ending it was. The reason this is worth the trouble is that exits are the metric surface. Almost every question worth asking of a running agent system is a question about the distribution of its exits.
The Eleven
The set used in the agentic notation in this knowledge base. It is closed on purpose, which the section after the drill explains.
| Exit | What happened | Whose problem |
|---|---|---|
| Complete | The agent finished the job. | Nobody. This is the one you want. |
| Agent transfer | Another agent took over. | Design, if it happens more than intended. |
| Human transfer | A person took over. | Operations. It has a staffing cost. |
| Guardrail | A control stopped the turn. | Whoever owns the policy. |
| Refusal | The model declined. | Whoever owns the prompt and the model choice. |
| Budget | A token or cost ceiling was hit. | Engineering, and finance. |
| Loop | The cycle limit was hit. | Engineering. The agent could not tell it was stuck. |
| Context | The context window was exhausted. | Engineering. Usually a context assembly problem. |
| Interrupt | The user left. | Product, if it clusters at one step. |
| Retries | A tool failed too often. | Whoever owns the dependency. |
| Timeout | An upstream call timed out. | Whoever owns the dependency. |
Only the first is unambiguously success. Two are handovers, which are neither success nor failure and are often the right outcome. The rest are failures that differ in who has to fix them, which is the column that makes the set useful on a Monday morning.
Telling Them Apart
Reading the list is not the skill. Six endings, as the person on the other side experienced them. Classify each one.
The merchant asked the agent to waive a fee. It replied that it was not able to help with that request, and the conversation ended there.
The pairs are the part worth arguing about in the room. A refusal and a guardrail stop produce the same silence for the user and belong to completely different people: one is the model declining, which is a prompt and model question, and the other is a control firing, which is a policy question. Count them together and neither team gets a signal.
Why a Closed Set
The instinct is to let teams invent exit names as they go. The reason not to is that an open vocabulary can only describe what happened, and a closed one can describe what did not.
If exits are free text, a system that has never once recorded a budget exit looks exactly like a system that cannot record one. With a closed set, the absence is visible: eleven types exist, your dashboard shows four, so seven kinds of ending are either impossible in your design or invisible in your instrumentation, and you now have a question worth asking. A drawing has no opinion about what is not on it. A vocabulary does.
The same argument covers the untyped case. An exit nobody has classified is not a twelfth kind of ending, it is a finding: a run that stopped for a reason the design never named.
A dashboard shows an agent completing 94% of runs. What is the most important thing it is not telling you?
Discussion
For a system your team runs, write the eleven on a whiteboard and mark which ones it could record today. The gap between the ones that can happen and the ones that would be visible is usually the most useful thing anyone learns in this session.