Core vs AgentChat Layering

## Why three packages exist AutoGen v0.2 was a single library where the agent class, the conversation loop, the OpenAI call and the code executor all lived together. That made simple demos short and anything unusual very hard: you could not reuse the message plumbing without inheriting the conversation semantics, and every new model provider or tool integration added a dependency to everyone's install. The v0.4 rewrite split the project along those seams into three published distributions, and 0.7.x still follows that shape. ## autogen-core — the runtime and the abstractions `autogen-core` is the bottom layer and the only one the other two depend on. It contains: - **The runtime protocol and a local implementation.** `AgentRuntime` defines message delivery; `SingleThreadedAgentRuntime` runs agents in one process on one asyncio event loop, started with `runtime.start()` and drained with `await runtime.stop_when_idle()`. - **Agent base classes.** `BaseAgent` is the raw contract; `RoutedAgent` adds type-based dispatch through the `@message_handler`, `@rpc` and `@event` decorators. - **Addressing and pub-sub.** `AgentId(type, key)` names an instance, `TopicId(type, source)` names a broadcast channel, and subscription types such as `TypeSubscription` bind topics to agent types. Direct delivery is `send_message`; broadcast is `publish_message`. - **Provider-neutral protocols.** `autogen_core.models.ChatCompletionClient`, `autogen_core.tools.BaseTool` and `FunctionTool`, memory and model-context interfaces, `CancellationToken`, and the `Component` configuration system used for declarative serialization. What core deliberately does *not* contain is any notion of a "conversation", a turn order, or a termination rule. It is a typed actor system that happens to ship LLM-shaped protocols. ## autogen-agentchat — the opinionated layer `autogen-agentchat` is the API most application code imports. It defines a concrete message protocol, preset agents, and teams that orchestrate them, plus composable termination conditions. Crucially it is not a parallel framework: a team spins up a core runtime under the hood and runs its participants as core agents exchanging messages, so AgentChat is a *policy* layer over core's *mechanism*. That is why a team can be embedded inside a larger core application, and why concepts like cancellation tokens surface identically in both. The practical consequence for an interview: if someone describes AgentChat and core as "two ways to use AutoGen", they have the relationship wrong. It is one runtime with an opinionated façade. ## autogen-ext — the integrations `autogen-ext` holds every implementation that depends on a third party. Model clients live under `autogen_ext.models` (OpenAI, Azure OpenAI, Anthropic and others), tool adapters under `autogen_ext.tools`, code executors under `autogen_ext.code_executors`, prebuilt specialist agents under `autogen_ext.agents`, and the experimental distributed runtime under `autogen_ext.runtimes.grpc`. Because these pull heavy or optional dependencies, they are gated behind extras — you install `autogen-ext[openai]`, `autogen-ext[docker]`, `autogen-ext[grpc]` and so on, rather than dragging every SDK into every project. This is the layer that changes fastest. Treating it as a separate distribution means a new provider integration does not force a core or agentchat release, and a project pinning one integration does not inherit the churn of the others. ## The dependency direction The arrows only point one way: `autogen-agentchat` depends on `autogen-core`; `autogen-ext` depends on `autogen-core` (and may target agentchat abstractions for prebuilt agents); core depends on neither. Nothing in core imports an SDK. A useful sanity check when reading unfamiliar AutoGen code is to look at the import lines — they tell you immediately which layer the author is working at, and therefore how much orchestration behaviour is being provided for them versus written by hand. ## Why interviewers ask The question dates your experience. Someone whose knowledge stops at v0.2 will describe a single `autogen` package with `ConversableAgent` and `llm_config`; someone who has shipped on the current line will name the three distributions, know that model clients are objects from `autogen-ext` rather than dicts, and be able to say which layer they would build a given feature at. It also sets up the natural follow-up — when you would drop below AgentChat into core — which is the real design question underneath.