Why AutoGen 0.4 makes TerminationCondition a first class primitive instead of leaving it to convention

Multi-agent systems run a loop: pick the next speaker, let it talk, pick again, repeat. The single most common production failure is that this loop never ends. Two agents hand off to each other forever, or a critic keeps rejecting revisions until the API bill explodes. The naive fix is to put a stop instruction in the prompt: 'finish when the answer is complete.' This fails because models forget instructions in long contexts, disagree about what 'complete' means, or talk themselves into one more polite round of revision. The stop rule is a runtime invariant; prompts are not the place for invariants. AutoGen 0.4 makes TerminationCondition a real typed object. You compose primitives like MaxMessageTermination(20), TextMentionTermination('DONE'), or TokenUsageTermination(50000) using logical OR and AND. After every turn the runtime evaluates the condition; if true, the team stops, no further model calls. The upgrade from convention to primitive matters because invariants you write in code are checked; invariants you write in prose are hoped for. In production, only the first kind survives.

**TerminationCondition** as a typed primitive is AutoGen 0.4's answer to the most common multi-agent failure mode: loops that never stop. Prompt-based termination ('stop when satisfied') fails for three reasons. Models forget the instruction past a few thousand tokens. Two agents can disagree about whether the work is done, and the optimist wins by default. And a polite critic can always find one more thing to improve. None of these are bugs in the model; they are predictable consequences of asking generative output to enforce control flow. Moving the stop rule into a typed runtime object fixes all three. The runtime evaluates the condition after every message, deterministically, without reading the chat. You compose: `MaxMessageTermination(20) | TokenUsageTermination(50000) | TextMentionTermination('FINAL ANSWER')`. The OR enforces a disjunction: any one trip stops the team. The key insight is the **separation of concerns**. The agents handle reasoning and content; the runtime handles whether the system is allowed to keep running. That separation is what makes the system safe to deploy without a babysitter. A composable type lets you build the stop logic per-workflow without writing a state machine each time, and lets reviewers audit the bound from the code, not by reading prompts.