How do you persist and resume an AutoGen team across restarts with save_state and load_state?

## The problem it solves An AgentChat team is an in-memory object. Its participants accumulate a model context as the conversation runs, and the group chat manager tracks whose turn it is. Kill the process and all of that is gone. `save_state` / `load_state` is the mechanism for taking a snapshot of that runtime state and rehydrating it later — a different process, a different pod, tomorrow. ``` state = await team.save_state() # Mapping[str, Any] ... await team.load_state(state) ``` Both are coroutines; forgetting the `await` gives you a coroutine object that serializes to nonsense, which is a classic first-attempt bug. ## State versus configuration — the key distinction This is the point interviewers are probing. AutoGen deliberately splits two things: - **State** — what happened: message histories, the manager's turn pointer, per-agent bookkeeping. Captured by `save_state`. - **Configuration** — what the system *is*: which agents exist, their names and system messages, which model client each uses, which tools are registered, the termination condition. Captured by your code, or declaratively by the component-config surface (`dump_component()` / `load_component()`). Secrets are a consequence of that split: because model clients are configuration, API keys are not in the saved state. That is a feature — you can store state in a normal application database without it becoming a credential store. The practical rule: **rebuild, then load**. Construct the team exactly as you did the first time, with the same participant names, then apply the state. Participants are keyed by name, so renaming an agent between save and load orphans its history. ## What is inside For a team you get a nested structure: the team's own state plus a map of participant name to that agent's state. An `AssistantAgent`'s state is essentially its `llm_context` — the serialized messages it will replay on its next model call. `autogen_agentchat.state` defines the typed models behind this, but you should treat the mapping as opaque and version-sensitive rather than reaching into it. Do not hand-edit it to "fix" a conversation; construct the team differently instead. ## The failure modes that matter in production **Unbounded growth.** State size is proportional to the transcript. A long-running session accumulates every message the agents exchanged, and a team is chattier than a single assistant by construction. Persisting raw state per user per session gets expensive quickly; capping the model context so agents forget old turns is the mechanism that bounds it, and that cap must be part of the agent configuration you rebuild. **Version skew.** The state shape follows the library version and your team's topology. A stored blob from last month's deployment may not load into today's code. Store a schema/app version alongside the state and decide explicitly what happens on mismatch — usually "start a fresh session", which is far safer than a half-loaded team. **Mid-run snapshots.** Save between runs, at a natural boundary, not while a `run_stream` is in flight. Snapshotting concurrently with execution gives you state whose consistency you cannot reason about. **Confusing reset with resume.** Clearing a team's state and loading a saved state are opposite operations; a resume path that clears first and then loads nothing leaves you with a team that has silently forgotten the user. ## Granularity choices You can persist per agent instead of per team when only one participant carries knowledge worth keeping — for example a research agent whose gathered context you want across sessions while the reviewers start clean each time. That is a deliberate design decision, and it is usually cheaper than storing whole-team transcripts. Finally, note that state persistence is not observability. The saved state tells you where a conversation *is*; it does not tell you why it got there, what each model call cost, or how long it took. Those come from the message stream and from tracing.