Why does an AutoGen team's second run() see the first task's history, and what does team.reset() do?

## Teams are objects, not calls In AutoGen AgentChat, `RoundRobinGroupChat`, `SelectorGroupChat`, `Swarm` and the other team types hold state across invocations. The group-chat manager keeps the message thread, and each participant keeps its own model context. `await team.run(task="...")` appends the new task to that thread and continues. You can even call `run()` with no task at all to let the team carry on from where it stopped. This is a deliberate design: the common interactive case is a conversation that pauses (for a human, for a termination cap) and then continues. It becomes a defect only when engineers treat the team like a stateless function and reuse one instance across unrelated requests. ## The two symptoms of unwanted carry-over **Cost.** Every participant re-sends its accumulated context on its turn. A team reused across ten unrelated tasks is, by the tenth, prompting each model call with nine irrelevant conversations. Latency and spend rise in a way that looks like model regression but is really an accounting problem. **Bleed.** Agents answer using facts from a previous task, or a critic approves a draft because a *different* draft was approved earlier. This is subtle, intermittent and easy to misdiagnose as prompt drift. In a service where one team object is shared across users, it is also a data-isolation bug: one user's content appears in another user's prompt. ## What reset() does and does not do `await team.reset()` puts the team and every participant back to their initial state: the shared thread is cleared and each agent's model context is cleared. It is a state operation, not a reconfiguration — the participant list, their tools, their system messages, the model clients and the termination condition you constructed the team with all survive. After a reset, the next `run()` behaves like the first. Two constraints matter operationally. Reset is asynchronous and must be awaited. And it is only valid between runs — you cannot reset a team while a run is in progress; stop the run first, for example with an external termination or by cancelling the run's cancellation token, then reset. ## Termination conditions are handled for you A related question interviewers like: do budgets leak? Termination conditions are stateful — a message counter, an accumulated token total — but the team resets its condition at the start of each run, so a second run gets a fresh budget rather than inheriting an exhausted one. What does *not* reset by itself is the conversation. Keeping the two straight is the point: budget is per run, context is per team until you clear it. ## Designing for it Three workable patterns: 1. **One team per task.** Construct the team inside the request handler, run it, discard it. Simplest, safest, and the right default for stateless services. The cost is object construction, which is trivial next to a model call. 2. **One team per conversation.** Keep the instance for the lifetime of a user's session so follow-ups work naturally, and drop it when the session ends. This is the pattern that pairs with human-in-the-loop pauses, where the whole point is that the thread survives. 3. **Reuse plus explicit reset.** Keep a pooled team and `await team.reset()` between tasks. Cheapest in allocations, but the most dangerous: one missed reset is silent context bleed. If you do this, make the reset unconditional in a `finally` block rather than a step someone can forget. Whatever you choose, never share one team instance across concurrent requests. Turn-taking assumes a single logical conversation; two callers interleaving into one thread produces nonsense that is very hard to reproduce. ## What to say in an interview The strong answer names the trade rather than just the API: statefulness is what makes multi-turn and paused conversations work at all, and the price is that reuse is unsafe by default. Then say which of the three patterns you would ship and why — per-request construction unless the product needs continuity.