Microsoft AutoGen agents are small, single-purpose programs that wrap a language model, give it a job title, and let it hold a conversation with other agents until the work is finished. One agent writes code. Another reviews it. A third decides when the group is done. The framework, released by Microsoft Research in 2023 and heavily rewritten in the 0.4 release in early 2025, handles the plumbing: message routing, tool calls, code execution, and stopping conditions.
That rewrite matters more than it sounds. AutoGen 0.4 split the project into layers. autogen-core holds the event-driven actor runtime. autogen-agentchat holds the conversational patterns most people actually use. autogen-ext holds model clients, code executors, and tool integrations. If you pull a tutorial off a blog and the imports start with from autogen import AssistantAgent, it is describing the pre-0.4 API. A good chunk of the confusion floating around online comes from mixing old and new code in the same project.
Underneath the friendly naming, what you get is a message bus with a scheduler attached, plus a set of opinions about how agents should take turns. If you want the architectural detail, this breakdown of what Microsoft’s AutoGen framework really does under the hood is worth reading before you write a line of code.
The four pieces you actually touch
Ignore the bench tooling and the research papers for a moment. Day to day, an AutoGen project is built from four things.
- Agents.
AssistantAgentis a model plus a system message plus an optional tool list.UserProxyAgentstands in for the human and can execute code it receives. - Teams.
RoundRobinGroupChat,SelectorGroupChat,Swarm, andMagenticOneGroupChat. Each one is a different rule for deciding who speaks next. - Tools. Ordinary Python functions. Type hints and a docstring get converted into a schema the model can call.
- Termination conditions.
MaxMessageTermination,TextMentionTermination,TokenUsageTermination, and combinations of them.
Teams plus termination conditions is where the design work lives. Everything else is configuration.
Round robin versus selector versus swarm
Round robin is the simplest: agent A, then B, then C, then back to A. It works when the pipeline is genuinely sequential, like write, then fact-check, then format. Selector chat hands the choice to a model that reads the transcript and picks the next speaker. That is flexible and unpredictable in roughly equal measure. Swarm uses handoffs, where an agent explicitly passes control to a named colleague, which mirrors how a support queue actually works. Magentic-One wraps the whole thing in an orchestrator that keeps a running task ledger, and it is the pattern Microsoft uses for open-ended research jobs.
Most teams start with round robin, get frustrated when one agent keeps getting called when it has nothing useful to add, and move to selector chat. That migration is close to a rite of passage.
Code execution is what separates AutoGen from a prompt chain
Plenty of frameworks can chain model calls. AutoGen can hand generated Python to an executor, read the output, and feed errors back into the conversation so an agent can try again. That loop is the whole reason people pick it over a plain orchestration library.
The executor choice is a real decision, not a formality. DockerCommandLineCodeExecutor spins up a container with a working directory you choose. LocalCommandLineCodeExecutor runs on your own machine with your own permissions. The second one is fine for a scratch project on a laptop and completely unacceptable on a shared server. An agent that can write arbitrary Python and execute it can also delete files, install packages, or make outbound network calls you never approved. Bind-mount a scratch directory, drop the network, and set a timeout.
A realistic build path
A workable first project takes an afternoon, not a sprint. A three-agent research assistant with a writer, a critic, and a code runner that produces a table of sources is the standard starting point, and there is a full walkthrough of building a multi-agent research assistant in AutoGen step by step if you want the file-by-file version.
The single most useful habit is logging. Dump every message to a JSONL file as it arrives. When a run produces garbage, and it will, you can reconstruct exactly which agent said what at turn nine instead of guessing from a final answer that looks fine but cites a paper that does not exist.
AutoGen Studio and the low-code route
AutoGen Studio ships as a separate package with a browser UI for dragging agents onto a canvas, wiring them into a team, attaching tools, and running a session. It is genuinely useful for two things: showing a non-technical stakeholder what a multi-agent flow looks like, and prototyping conversation patterns before committing to code.
What it is not is a deployment target. Teams that try to grow a Studio prototype into a production service usually end up rebuilding the flow in Python within a month, because the pieces they need to change first are the ones the UI does not expose.
Where AutoGen agents fall over
The failure modes are consistent enough to plan around.
Politeness loops. Two agents will happily agree with each other for forty turns. Every agent sees the full transcript, so token use climbs fast. A twenty-turn conversation with four participants is roughly eighty model calls, and the last call carries the entire history as context.
Silent self-repair. When a tool call throws, the model often rewrites the call instead of surfacing the error. That is great when the fix is right and awful when it quietly changes what the function does. Set MaxMessageTermination to something small, like 12, and read the transcripts before you trust the output.
Version churn. The 0.4 rewrite broke almost every published example. Pin your dependencies and expect to update.
None of this is unique to Microsoft. Every framework in this space has the same rough edges, and the trade-offs in open source AI agents, from licensing to hidden operating costs, apply here as much as anywhere.
How it sits next to the alternatives
LangGraph makes you draw the graph yourself, which is more work up front and far easier to debug at 2am. CrewAI leans hard on role definitions and reads almost like a job description. IBM’s entry, BeeAI, bundles an agent toolkit with a deployment story that AutoGen leaves to you.
AutoGen’s edge is conversation. If your problem genuinely looks like a meeting between specialists who need to argue, it fits. If your problem is a fixed sequence of five steps, a graph framework or fifty lines of plain Python will be easier to maintain and cheaper to run.
Start with a task that has a checkable answer
Pick something where you can tell success from failure without judgment calls. “Find ten papers on X and return a table with title, year, and method” beats “write a strategy document” by a wide margin, because you can score every run.
Keep the first version to three agents. Put the code executor in Docker. Cap the turns. Log everything. Run the same task twenty times and count how often it produces a correct answer. If the success rate lands under 70%, the problem is almost always the task definition rather than the framework, and narrowing the instructions usually moves the number more than swapping models or adding a fourth agent ever will.