How do you migrate an AutoGen v0.2 ConversableAgent codebase to v0.4+?

## Frame it correctly first The honest answer to "how do you migrate" is: this is not a version bump, it is a different framework wearing the same brand. v0.4 rewrote the foundations into an async, event-driven runtime with a layered package split, and the surface changed accordingly. Interviewers ask this partly to date your experience — a candidate who describes `ConversableAgent`, `llm_config` and `initiate_chat` as the current API has not touched AutoGen since the redesign — and partly to see whether you can scope a real migration rather than promise a search-and-replace. ## The import surface v0.2 code imports everything from one package: agent classes, group chat, the OpenAI wiring. v0.4+ code imports from three — `autogen_agentchat` for agents, teams, messages and termination conditions; `autogen_core` for runtime and shared abstractions; `autogen_ext` for model clients, tools, executors and integrations installed via extras. The first pass of any migration is therefore mostly deleting imports and deciding, per construct, which layer now owns it. It also tells you immediately how much of the codebase was leaning on v0.2-specific behaviour. ## Configuration: dicts become objects v0.2 configured models with an `llm_config` dictionary containing a `config_list` and assorted knobs, threaded into every agent constructor. v0.4+ makes the model a first-class object: you construct a model client once from `autogen_ext.models` and pass that object to the agents that should use it. This is a genuine improvement — typed construction, an explicit lifecycle you can close, and one shared client rather than per-agent config drift — but it means every place that built or mutated a config dict needs rewriting, and any code that inspected `llm_config` at runtime has nothing to inspect. ## Async everywhere v0.2's common path was synchronous: call `initiate_chat` and block. v0.4+ is async-first — agents and teams expose coroutine entry points, and the streaming variants yield events as the run progresses. Practically this means your top-level entry point becomes a coroutine driven by an event loop, and any synchronous integration point (a Flask view, a script, a notebook cell) needs a bridge. Callbacks that used to be sync reply hooks also need rethinking, since the modern equivalents observe an async stream of messages. ## Conversation control: implicit becomes explicit This is where partial migrations go wrong. v0.2 stopped a conversation through a mixture of `max_consecutive_auto_reply`, an `is_termination_msg` predicate, and `human_input_mode`. v0.4+ makes stopping a first-class, composable object: you construct a termination condition and hand it to the team, and conditions compose with the `|` operator so "stop on a keyword or after N messages" is one expression. If you port agents but keep the old mental model of stopping, you get exactly the two failure modes people report — a run that never terminates and burns tokens, or one that stops after a single turn because nothing kept it going. Human input changed shape too: rather than a mode string on the agent, the modern line uses a dedicated user-facing agent whose input function you supply, which fits the async model and makes the human a participant rather than a flag. ## Tools and code execution v0.2 registered functions in two halves — one registration to expose the schema to the model, another to permit execution on the executing agent. v0.4+ collapses this: you pass callables (or tool objects) to the agent that should call them, and the framework derives the schema. Code execution likewise moves out of a configuration dictionary: executors are objects from `autogen-ext`, and a dedicated executor agent runs extracted code, which makes the sandboxing choice explicit instead of buried in a dict key. ## How to sequence the work 1. Inventory what the v0.2 code actually relies on: how many agents, which stopping rules, which tools, whether code execution is used, and where human input enters. 2. Stand the new stack up alongside the old rather than editing in place — the packages coexist, so a parallel implementation is cheaper than a half-migrated tree. 3. Port one complete workflow end to end, including its termination behaviour, and compare transcripts and token usage against the old run before touching the rest. 4. Then move remaining workflows, and only afterwards consider whether any of them wants to drop below the team API into the core runtime. ## The strategic footnote Worth saying out loud: Microsoft has since folded AutoGen's direction into a broader agent framework effort, so the v0.4+ line is best treated as maintained but not the long-term destination. That does not make migrating off v0.2 wrong — running on an API line that has moved on entirely is worse — but it does argue for keeping your domain logic, prompts and tool implementations in framework-agnostic modules so the next port is smaller than this one.