Stack Guide · AutoGen
Microsoft's AutoGen takes a different approach to multi-agent systems than LangGraph or CrewAI. Where LangGraph models agents as nodes in an explicit state machine and CrewAI models them as crew members with roles and tasks, AutoGen models agents as participants in a conversation.
That conversational model is ideally suited to iterative code-generation workflows: an agent writes code, another executes it, observes the output, and passes it back. The loop continues until the result is correct. It's also well-suited to adversarial review patterns where a critic agent's job is to find problems with the main agent's output.
These are our notes on when AutoGen's model is the right fit, and when its non-determinism and security surface make it the wrong choice.
Building a code-generation or analysis workflow?
The conversational model is distinctive. These are the workflows where it creates real value.
AutoGen was designed from the ground up for workflows where agents write, run, and iterate on code. The built-in code executor means an agent can propose a Python function, run it in a sandboxed environment, inspect the output, and revise the function if the result was wrong, all within the same workflow. This loop is the core of what makes AutoGen distinctive.
AutoGen's conversational model makes it natural to set up workflows where one agent produces output and another agent's job is to find problems with it. A code-writing agent produces a solution; a code-reviewer agent checks for bugs, edge cases, and style issues; the code-writer revises. This adversarial refinement pattern produces better outputs than a single agent working alone.
For tasks that have no single right answer (research synthesis, strategic analysis, technical design tradeoffs) having agents with different perspectives debate a question can surface considerations that a single-agent approach misses. AutoGen's GroupChat manager can orchestrate these debates with configurable speaking order and termination conditions.
When the task is 'analyze this dataset and tell me what's interesting', a static prompt to an LLM produces mediocre results. An AutoGen workflow where an analyst agent writes analysis code, runs it, observes the output, and decides what to investigate further produces significantly better exploratory analysis, because each code execution informs the next query.
Three things separate AutoGen from other multi-agent frameworks — and they're all related to the conversational model.
Conversation-centric model
In AutoGen, everything is a message between agents. Agents communicate by sending messages to each other, and the 'program' is the conversation transcript. This is different from LangGraph's explicit state machine or CrewAI's task assignment model. It makes AutoGen natural for iterative back-and-forth workflows but awkward for deterministic sequential pipelines.
Built-in code executor
AutoGen ships with a code execution environment that runs Python in a sandboxed subprocess (or Docker container for production). Agents can include code blocks in their messages, and the executor automatically detects and runs them. The output is passed back to the agent as a message. This tight integration between code generation and code execution is something you'd otherwise have to build yourself.
GroupChat for multi-agent orchestration
GroupChat is AutoGen's mechanism for coordinating multiple agents in a shared conversation. A GroupChat manager agent decides which agent speaks next based on the conversation state. This is more flexible than CrewAI's sequential and parallel execution modes, and less structured than LangGraph's explicit routing. It sits in between.
AutoGen's conversational model and code execution surface create real constraints. Here is when those constraints are disqualifying.
Pure data pipeline workflows
If your workflow is a deterministic sequence of steps (retrieve documents, summarize them, format the output, send to Slack) AutoGen adds unnecessary complexity. The conversational model is designed for iterative workflows where the next step depends on the output of the previous one. For linear pipelines, LangChain or a simple sequential script is cleaner.
Production systems that need deterministic routing
AutoGen's GroupChat manager uses an LLM to decide which agent speaks next. That introduces a layer of non-determinism into the orchestration itself, the routing decision depends on the LLM's interpretation of the conversation. For production systems where you need to know exactly which code path will execute under which conditions, LangGraph's explicit conditional edges are far more reliable.
When code execution is a security concern
AutoGen's code executor runs Python code that an LLM generated. Even in a sandbox, this is a meaningful security surface. In a corporate environment where agents might be processing sensitive data, the risk of a poorly sandboxed code execution environment is real. If you use AutoGen in production, the Docker-based executor and careful input validation are not optional. They are required.
When AutoGen's model fits the workflow, the results are genuinely better than alternatives. Here is where we find that fit.
We use AutoGen for data analysis tasks where the analysis questions aren't fully specified upfront. An analyst agent explores a dataset by writing Python code, observes the outputs, and generates follow-up queries. The iterative code execution loop produces better analysis than a single static prompt, and the code artifacts are useful deliverables in themselves.
For workflows that generate code (SQL queries, data transformation scripts, API integrations), we use a two-agent pattern where a writer agent generates code and a reviewer agent checks it. The reviewer runs the code in the executor and validates the output against expected behavior. Bugs that would reach production in a single-agent setup get caught in the review loop.
We never use AutoGen's default subprocess executor in production systems. The Docker executor isolates code execution in a container with no access to the host filesystem, limited network access, and resource constraints. Setting this up correctly adds time to initial deployment but is not optional for any system where the code being executed is not fully trusted.
AutoGen's power and its pitfalls are closely related. These are the patterns that cause the most problems.
Treating AutoGen as a general-purpose agent framework
AutoGen's strength is conversational multi-agent workflows, especially those involving code. Teams that try to use it for RAG pipelines, structured data extraction, or simple sequential automation end up fighting the framework. AutoGen is excellent at what it does; it's not the right default for everything.
Ignoring code execution sandbox security
The default AutoGen code executor runs in a subprocess on the host machine with access to the same filesystem and environment variables. In a development environment that's convenient. In production (where agents might be writing code based on untrusted user input), it's a significant security exposure. Container-based execution is mandatory for production deployments.
Letting GroupChat conversations run unconstrained
GroupChat without termination conditions will keep running until the LLM decides the conversation is done, or until it hits your token limit. In practice, conversations wander and agents repeat themselves. Explicit termination conditions (maximum turns, success detection, error detection) are required. Teams that skip them are surprised by both the cost and the latency of production runs.
Describe the workflow. What the agents need to do, what the code executes against, and what the success criterion is. We can give you an honest opinion on whether AutoGen is the right fit and how to set it up safely.