How do you bound cost and runtime for an AutoGen team running unattended in production?

## The framing that matters An unattended multi-agent team is an autonomous loop that spends money per iteration. The engineering question is not "which termination condition do I use" but "what does the system do when the agents fail to converge". A good answer separates three layers. ## Layer 1 — the success path Exactly one stop should mean *done*. In practice that is a `TextMentionTermination` on a token the agents are explicitly instructed to emit, or a `HandoffTermination(target="user")` in a handoff-based team where finishing means returning to a human, or an agent-specific stop such as `SourceMatchTermination`. Choose a token that cannot appear in user input, and put the instruction to emit it in the responsible agent's system message rather than hoping the model volunteers it. ## Layer 2 — the fuses Everything else that can stop a run is a failure to reach layer 1, and each fuse covers a different runaway shape: - `MaxMessageTermination(n)` — bounds the conversation length; the cheapest sanity bound. - `max_turns` on the team — an independent cap that applies even if the condition object is misconfigured. - `TimeoutTermination(seconds)` — bounds wall clock, which is what your caller's SLA actually cares about. - `TokenUsageTermination(...)` — bounds spend directly, but only if the model client reports usage; if it does not, this fuse silently never fires, which is why it must be ORed with a message cap rather than trusted alone. - `ExternalTermination()` — lets an operator or supervising service stop a specific run by calling `set()`. Compose them with `|` so any one is sufficient. Also remember where the checks happen: conditions are evaluated at message boundaries, so a single agent turn with many tool calls runs to completion before any fuse can fire. Fine-grained cost control therefore also needs per-call limits on the model client and, for tool-heavy agents, sane tool timeouts. For a hard abort mid-run, cancel the `CancellationToken` you passed to `run()`. ## Layer 3 — the framework's own cost drivers AutoGen teams broadcast messages, so every participant re-reads a growing thread on its turn. Total spend therefore grows super-linearly in turns; halving the turn cap is worth more than it looks. On top of that, the team type you chose has its own overhead: a positional team adds none, `SelectorGroupChat` adds one selection model call per turn with history in its prompt, and `MagenticOneGroupChat` adds an orchestrator that maintains task and progress ledgers and re-plans when it detects the team is not making progress — bounded by `max_stalls` (default 3), after which it revises its plan rather than looping silently. Choosing the cheapest team type that can express the workload is a bigger lever than tuning any single condition. Code-executing participants deserve their own bounds; unattended execution of model-written code is a blast-radius question, not a cost question, and it is answered with sandboxing and approval gates rather than with termination conditions. ## Layer 4 — the feedback loop The part most teams skip. Every run returns a `TaskResult` with a `stop_reason`; log it as a dimension alongside turn count and token usage. Then the fleet answers questions like: what fraction of runs end on the success signal versus a fuse? Which fuse? Did that shift after a prompt or model change? A team where the message cap fires on most runs is not "safely bounded" — it is failing, and the cap is hiding the failure behind truncated but plausible output. Cutting a run off mid-conversation and returning its partial result to a caller as if it were an answer is the real production hazard here. ## The judgment call Caps are a floor on safety, not a design. If safety nets fire routinely, the response is to change the design — fewer participants, a cheaper team type, a smaller task per run, an explicit completion protocol, or a human gate — not to raise the cap. Conversely, caps set too tight look like quality regressions and push people to disable them. Pick fuse values from the observed distribution of successful runs, with headroom, and revisit them whenever prompts, models or the roster change.