AutoGen, or agents talking to each other

AutoGen, or agents talking to each other

AutoGen started from an idea that sounded eccentric at the time and is obvious today: instead of one model carrying a task from start to finish, several agents with different roles talk to each other until they reach a solution.

One writes code, another reviews it, a third runs tests and reports failures. The conversation proceeds without a human, and the output is finished work rather than a single answer. That concept spread across the whole ecosystem and today you will find it in most agent libraries.

Before going further, a caveat is necessary, since without it the whole text would mislead.

Three projects instead of one

Microsoft moved AutoGen into maintenance mode in October 2025. The repository carries an official notice that the project receives no new features and is community managed, with fixes limited to bugs and critical security patches.

In place of one project there are three paths today.

The first is AutoGen as it stands. It works, it installs, and existing deployments will keep working, while no longer developing.

The second is Microsoft Agent Framework, which the vendor calls the direct successor outright. It came from merging two lineages: multi agent orchestration from AutoGen and enterprise groundwork from Semantic Kernel. The stable release arrived in April 2026, in variants for Python and for the .NET platform.

The third is AG2, a community led fork under a permissive licence, founded by some of the original authors after leaving Microsoft. It develops independently and keeps the project's original philosophy.

The practical conclusion: do not start a new project on AutoGen. You are choosing between the vendor's successor and the community fork, and that is a real decision rather than a formality.

What the idea was

The original concept deserves understanding, since it carried into both successors and into the competition.

from autogen import AssistantAgent, UserProxyAgent

developer = AssistantAgent(
    name="developer",
    system_message="You write Python code. You revise it after reviewer comments.",
    llm_config={"model": "gpt-4o"},
)

reviewer = UserProxyAgent(
    name="reviewer",
    human_input_mode="NEVER",
    code_execution_config={"work_dir": "workspace"},
)

reviewer.initiate_chat(
    developer,
    message="Write a function computing the median of a list and test it.",
)

More happens here than is visible. The first agent writes code, the second extracts it from the response and runs it, and the run's output returns as another message in the conversation. If a test fails, the error message reaches the author, who fixes the code. The loop turns until it succeeds or hits a turn limit.

Two things were novel here. The first was treating code execution as a participant in the conversation rather than a tool the model invokes. The second was the absence of a fixed flow: speaking order emerged from the conversation rather than from a programmed graph.

That second property was both the greatest strength and the greatest problem, as we will see.

Group conversation

With more agents, a mechanism deciding who speaks next became necessary.

from autogen import GroupChat, GroupChatManager

group = GroupChat(
    agents=[analyst, developer, tester],
    messages=[],
    max_round=20,
)

manager = GroupChatManager(groupchat=group, llm_config={"model": "gpt-4o"})
analyst.initiate_chat(manager, message="Build the June sales report.")

Choosing the next speaker fell to the model, which read the conversation history and named who should speak now. Flexible and impressive in a demo, awkward in production.

The problem was that the same input produced different runs. Sometimes the analyst handed off to the developer, sometimes to the tester, and sometimes two agents fell into an exchange of pleasantries, burning the turn limit without result. Debugging such a loop is hard, since there is no single place where the wrong decision was made.

Hence the direction the whole field took: flows described explicitly in code, as in LangGraph, or roles with firmly assigned tasks, as in CrewAI. Conversational freedom gave way to predictability, since production demands repeatability.

Collaboration patterns worth knowing

Whatever library you pick, agent collaboration arrangements repeat endlessly, and recognising them by name shortens design work from hours to minutes.

The critic arrangement is two agents: one produces, the other judges and sends it back with comments. It works wherever a result is easier to check than to produce, meaning code, texts with formal requirements, and calculations. The quality gain is often large, the cost is doubling the number of calls.

The manager arrangement splits a task into parts and hands them to workers. It works well when the parts are independent, since they then run in parallel. With interdependent parts the manager becomes a bottleneck and an ordinary flow written in code does better.

The expert arrangement routes a request to an agent specialised in a given area. Popular in support handling, where one instruction set covers complaints and another technical questions. Note, though, that routing requests is ordinary classification, so a cheaper model suffices for that step.

The debate arrangement runs several agents on the same task and picks the answer by majority. Expensive, since it multiplies calls, and worth considering only where an error costs more than running the task three times.

Three of those four arrangements can be built without a framework, in a few dozen lines of ordinary code. A library earns its keep once you combine them and need to trace what happens inside.

Cost and observability

Two things that look different in an agent conversation than in a single call, and that decide whether a solution belongs in production.

Cost grows faster than intuition suggests, since every turn carries the entire conversation history with it. The tenth message in a thread costs many times more than the first, despite looking the same. At twenty turns the bill for one task can exceed a dollar, which at a thousand tasks a day changes the conversation with the finance team.

Three ways to constrain that spend are simple and effective. The first is a hard turn limit, set lower than caution suggests, since conversations beyond a dozen or so messages rarely improve the result. The second is trimming history, meaning passing a summary forward instead of the full transcript. The third is matching the model to the role: a critic checking formal requirements does not need the strongest model, while the worker usually does.

Observability matters more here than in an ordinary call, since a failure shows up not as an exception but as a bad answer after fifteen turns. Record every message together with token usage, a run identifier, and a timestamp. Without that the only available diagnostic method is rerunning and watching the console, which under a non deterministic flow is unreliable.

Which successor to choose

The first question concerns the platform. If a company stands on .NET and Microsoft cloud services, the vendor's successor is the natural choice, since it is the only variant with full support for both languages and integration with the rest of the offering. The same ecosystem also holds Foundry Agent Service, which is not a library but a service running the agent on the vendor side: you get a separate identity per agent, session isolation, and versioned definitions, and pay for it with lock in to one cloud and with checking which tools have already left public preview.

The second concerns migration scale. The community fork sits closer to the code you already have, so moving over is often a package rename and minor fixes. The vendor's successor is a different architecture and a real rewrite.

The third, most often skipped, concerns whether you need a multi agent framework at all. Plenty of tasks described as agent collaboration are in reality three model calls in sequence, and such code is shorter, cheaper, and easier to maintain than any library.

Migrating without rewriting everything

Whichever direction you take, the order of work is similar and deserves planning before the first change.

Start by writing down what your agents actually do. It usually turns out the conversation follows a fixed order and the freedom to choose a speaker was never used. Migration then means recording that order explicitly, which incidentally removes the source of irreproducibility.

The second step is extracting the tools. Functions the agents call, meaning database queries, API calls, and file operations, should be ordinary code independent of the framework. That part carries the most value and moves between libraries unchanged.

The third is reproducing the flow in the new tool and comparing results across the same set of cases. Without a test set, migration is guesswork, since agents do not return values you can compare with an equals sign.

The fourth, optional, is running both versions in parallel on a slice of traffic. For business critical processes that is the only way to see the difference before switching.

Code execution and security

One thing from the original project deserves separate treatment, since it recurs in every successor and gets underestimated.

An agent running code written by a model is a powerful mechanism and an open door at once. The code arises from text influenced by the request, and when reading external data, by that content as well. Running it in the same process as your application is a risk not worth taking.

The right answer is a container with no network access, mounting only a working directory, with an execution time limit. Configuring that takes a quarter of an hour and turns a serious problem into a minor one.

It also pays to constrain what the agent can do at all. An allow list of libraries works better than a deny list of operations, since the former cannot be circumvented by ingenuity you did not anticipate.

Think separately about what the agent sees. If API keys or personal data end up in the conversation context, they reach the generated code and the run transcript, and across a longer history every subsequent model call as well. Passing identifiers instead of values, substituting the real data only inside a tool executed on your side, solves that once and costs nothing.

Common mistakes

The first is starting a new project on AutoGen. Maintenance mode means no new features, so choose among the successors.

The second is confusing the community fork with the vendor's project. The names are similar, the licences and directions differ, and mixing documentation from both produces code that will not run.

The third is relying on the model to choose speaking order in a production process. If the order is known, write it down explicitly, since you gain repeatability for free.

The fourth is having no turn limit and no cost cap. An agent conversation can circle indefinitely, and every turn is a model call, so a spending ceiling belongs there from the first run.

The fifth is running agent code without isolation. A container with no network and a time limit is the minimum rather than a precaution for the unusually careful.

The sixth is reaching for a multi agent framework for a task that is three model calls in sequence. The simpler solution is usually better here and cheaper to maintain.

FAQ

Is AutoGen deprecated?

Not in the sense of removal, but in maintenance mode since October 2025. The code works and receives bug fixes and critical security patches, while new features are not being built and the project is community managed.

How does AG2 differ from Microsoft Agent Framework?

AG2 is a community led fork founded by some of the original authors, close to the original code and released under a permissive licence. Microsoft Agent Framework is the vendor's successor, formed by merging AutoGen with Semantic Kernel, with Python and .NET variants and commercial support.

Do I have to migrate right now?

Not immediately. A working deployment on pinned versions will keep running. It does pay to plan the move, though, since the absence of new features eventually means drifting away from the rest of the ecosystem, particularly around new models and protocols.

Is a multi agent framework worth using at all?

It depends on the task. For a process with a fixed sequence of steps, ordinary code calling a model a few times is simpler and cheaper. A framework earns its keep once you need state management, retries, observability, and parallel branches.

How do I compare two libraries before choosing?

Build the same real case from your project in both and measure three things: the line count, the cost of one run, and how easily you can establish the cause after a failed run. The third measure matters most and is checked least often before a decision.

The project's status is documented in the AutoGen repository, and the migration path in Microsoft's documentation.