Principle:Microsoft Autogen Termination Conditions
| Knowledge Sources | |
|---|---|
| Domains | Multi-Agent Systems, Conversation Control, Boolean Algebra, AI Agents |
| Last Updated | 2026-02-11 00:00 GMT |
Overview
Termination conditions are composable predicates that monitor an ongoing multi-agent conversation and signal when the conversation should stop, preventing unbounded execution and ensuring agents produce results within defined constraints.
Description
In multi-agent systems, conversations between agents could theoretically continue forever. Without explicit stopping criteria, agents might loop indefinitely, consume excessive tokens, or drift away from the original task. Termination conditions solve this problem by providing a declarative way to specify when a conversation should end.
A termination condition is a stateful callable that receives new messages produced during a conversation turn and decides whether to stop. Each condition tracks its own internal state (e.g., message count, token count, whether a specific text was seen) and returns either a stop signal or nothing.
The key design principles of termination conditions are:
- Composability: Individual conditions can be combined using Boolean algebra operators. The OR operator (
|) stops the conversation when any condition is met. The AND operator (&) stops only when all conditions are simultaneously met. - Statefulness: Each condition maintains internal state that accumulates across conversation turns. This enables conditions like "stop after 10 total messages" that span multiple turns.
- Resettability: Conditions can be reset to their initial state, allowing teams to be run multiple times. The framework automatically resets termination conditions after each team run.
- Separation of concerns: Termination logic is decoupled from agent logic and orchestration logic. Agents do not need to know about termination rules; they simply produce messages while the termination layer monitors.
Common categories of termination conditions include:
- Content-based: Stop when a specific text pattern appears in a message (e.g., "TERMINATE", "APPROVED").
- Count-based: Stop after a maximum number of messages have been exchanged.
- Resource-based: Stop when token usage exceeds a budget (total, prompt, or completion tokens).
- External: Stop when an external signal is received (useful for human-in-the-loop scenarios).
- Functional: Stop when a custom predicate function returns true.
Usage
Define termination conditions after creating agents and before assembling teams. Use them when:
- You need to prevent runaway conversations that could consume unlimited tokens and time.
- You want agents to signal task completion through a specific keyword (e.g., "TERMINATE").
- You need to enforce budget constraints on LLM token usage.
- You want to combine multiple stopping criteria (e.g., stop when the agent says "DONE" OR after 20 messages, whichever comes first).
- You need fine-grained control over which agent's messages are checked for termination signals.
Theoretical Basis
Termination conditions implement a form of Boolean algebra over predicates applied to message streams. Each atomic condition is a predicate P(messages) -> {true, false}. The composition operators follow standard Boolean logic:
OR composition: (P1 | P2)(messages) = P1(messages) OR P2(messages) AND composition: (P1 & P2)(messages) = P1(messages) AND P2(messages)
The AND composition has a subtle semantic: it requires that all constituent conditions have been triggered at some point during the conversation, not necessarily on the same turn. Each constituent condition independently tracks whether it has been triggered, and the AND condition checks whether all have been triggered.
The evaluation model follows the Observer pattern. The termination condition is an observer that receives notifications (new messages) from the conversation and decides whether to trigger. The orchestration layer acts as the subject, calling the termination condition after each agent turn.
FUNCTION evaluate_termination(condition, new_messages):
1. If condition is already terminated, raise error
2. For each message in new_messages:
a. Update internal state (counters, flags, etc.)
b. Check if stopping criteria are met
3. If criteria met, return StopMessage with reason
4. Otherwise, return None (conversation continues)
FUNCTION compose_or(condition_a, condition_b):
Return a new condition that:
1. Passes messages to both condition_a and condition_b
2. Returns StopMessage if EITHER returns a StopMessage
3. Returns None only if BOTH return None
FUNCTION compose_and(condition_a, condition_b):
Return a new condition that:
1. Passes messages to both condition_a and condition_b
2. Collects StopMessages from each
3. Returns combined StopMessage only when ALL have triggered
4. Returns None if any has not yet triggered
The statefulness of conditions is critical. A MaxMessageTermination(10) condition does not check "are there 10 messages in this batch?" but rather "have 10 total messages been seen across all batches since the last reset?" This accumulation model enables conditions to work correctly across multiple conversation turns.