AutoGen locally: what works and what casse

#The conversation model

Where a chain framework asks you to define steps, AutoGen asks you to define participants. An assistant agent proposes; a proxy agent represents you, may execute code, and returns the result; a group discussion brings in several specialists under a manager who decides who speaks. Behavior emerges from these exchanges.

It is genuinely powerful for open-ended tasks—debugging, iterating on an analysis—and that is exactly what makes the cost unpredictable. A fixed pipeline makes N calls to the model. A conversation makes as many as needed, and “as many as needed” is decided by the model you are rightly questioning.

This design has a direct consequence for role selection: the more distinct agents there are in the conversation, the more turns are possible before a final answer emerges, and the greater the risk of drift. Two agents responding to each other in a loop without ever converging on a conclusion are the most common symptom locally, precisely because no limit was set before the first attempt. The number of agents is therefore not just an architectural choice; it directly multiplies the compute time consumed on your own graphics card.

#AutoGen in maintenance mode: what changed

This is the point most tutorials still online leave out. The official microsoft/autogen repository has stated it plainly since October 2, 2025: the project is in maintenance mode, will receive no new features, and will be community-managed. Microsoft recommends that new projects start directly with Microsoft Agent Framework (MAF), its successor, which merges AutoGen’s components with those of Semantic Kernel in a single development kit that reached general availability in early April 2026.

AutoGen’s original creators, Chi Wang and Qingyun Wu, left Microsoft at the end of 2024 and continued development under the name AG2, an Apache 2.0-licensed fork hosted by the ag2ai organization. AG2 presents itself as the project’s active continuation rather than a break: the historical codebase remains available as AG2 Classic for anyone who doesn’t want to change their code, while AG2 1.0 evolves the architecture toward a more explicit protocol between agents. For a project starting today, AG2 is the most coherent choice if you want to stay close to the original AutoGen API; Microsoft Agent Framework is the one to consider if you’re already in the Microsoft ecosystem and its integration with Semantic Kernel tools directly concerns you.

#Connect it to a local model

1. 01
   Serve the model

   On an OpenAI-compatible endpoint. For multiple agents speaking at the same time, a server designed for concurrency performs much better than one designed for a single workstation.
2. 02
   Configure the client

   Base address (for example, http://localhost:11434/v1 for Ollama), the model name exactly as it was retrieved locally, and a dummy key. Local servers ignore the key; the client library often requires it to exist.
3. 03
   State capabilities honestly

   Frameworks ask whether the model supports function calling or JSON mode. Claiming an unsupported capability produces incomprehensible errors later instead of a clean failure.
4. 04
   Increase the context window

   The history grows with every turn. A default context silently truncates the beginning, so agents redo work that has already been completed.

#Code execution: contain it

The pattern that makes AutoGen appealing—an agent writes code, an executor runs it, the error comes back, and the agent fixes it—is also what runs model-written code on your machine. Run it in a container, without credentials, without network access unless the task requires it, and never against your personal directory. Any content retrieved from outside—a ticket, a web page, or a documentation file—must be treated as potentially hostile.

Observability matters as much as containment. In a conversation with three or four agents, you diagnose an incident by rereading the exact prompt received by each agent on every turn, not a summary afterward. Without a complete trace, you can never know whether an agent misinterpreted an instruction or simply received truncated context because of insufficient memory. Logging every exchange, including tool calls and their exact arguments, costs little and avoids guessing what happened once the graphics card has gone quiet again.

#The model size, again

Prefer models trained for tool calling and structured output. This is the same ceiling faced by all local agent frameworks: prose is easy, strict formats are not. In a group discussion, the manager role generally deserves the most capable model you have: it decides who speaks next, and a poor routing decision costs an entire turn for every mistake, repeated as many times as the conversation keeps going without converging.

• CrewAI: ordered roles and deliverables
• Architecture of a local agent
• Create a local agent in Python with LangChain
• The QuelLLM toolkit for setting up local agents
• Official repository: maintenance mode announcement
• AG2: the actively developed fork
• Ollama's official OpenAI-compatible API

#AutoGen, AG2, or CrewAI

For code already written with AutoGen’s legacy API, migrating to AG2 is generally minor: the original autogen.* namespace remains available in a dedicated branch (AG2 Classic) while you transition at your own pace. Starting from scratch today is a different decision: you might as well choose AG2 directly or evaluate Microsoft Agent Framework instead of learning a codebase that its own publisher describes as community-maintained.

#What a conversation really costs

On a paid API, a three-agent conversation that stretches over twenty turns shows up on the bill. Locally, it shows up in the case fan and on the wall clock. Each turn is a full generation: if a turn takes an average of five seconds on your card, twenty turns without a stop condition represent at least one minute and forty seconds of continuous computation, often much more once the context has grown and each generation rereads a longer history than the previous one. Nothing alerts you while this happens—no counter, no threshold, just a GPU that stays hot.

That is why the turn limit is not just another configuration detail: it is the only mechanism that turns a potentially unlimited cost into a bounded, predictable cost, exactly as a token budget would on a commercial API. Setting this limit before the first test, rather than discovering it afterward, is the difference between a five-minute test and a graphics card monopolized all evening by a conversation that had gone nowhere since the tenth message. On a shared machine with other workloads—a workstation, not a dedicated server—this monopolization also has a real opportunity cost: you cannot launch anything else GPU-intensive while an unlimited multi-agent conversation runs in the background.

#FAQ