AutoGen and CrewAI Compared: Building Agent Teams, Counting Their Cost

For a long stretch of applied LLM work, the picture of an AI interaction was a single loop: someone types a prompt, a model answers, the chat continues. That works fine for question answering. It starts to creak once the job is to actually get something done, such as writing and debugging a program, planning a research report, or running a multi-step workflow that touches several tools and data sources.

Multi-agent systems exist for that gap. Instead of asking one monolithic prompt to carry everything, the task is cut into roles: an engineer, a critic, a researcher, a writer. Each role becomes an agent, which is a wrapper around an LLM with its own persona, memory and responsibilities. The agents talk to each other, pass partial results along, critique one another and iterate until the work is finished. The experience is less like consulting an oracle and more like managing a small, very fast team.

Two frameworks dominate this space and are compared here: AutoGen, which comes out of Microsoft Research as open source, and CrewAI, a younger platform built with enterprise workflows in view. A third tool, AgentOps, adds an observability layer so that what the agents are doing, and what it costs, can be seen.

Roles instead of one big prompt

The conceptual shift comes before any tooling. In a single-agent setup, one system prompt has two jobs at once: defining a persona and foreseeing whatever the model might be asked. Multi-agent frameworks spread the load. Every agent gets a tighter job description made of a persona, a goal and, at times, a backstory that colours its approach.

This copies how human teams work. A senior engineer is not also the QA reviewer, project manager and technical writer. Splitting those functions across agents brings three practical gains:

• Specialisation lifts quality. An agent whose only purpose is checking code for security problems will inspect it more consistently than a generalist juggling several objectives.
• Feedback loops become explicit. Routing one agent's output to another whose job is to criticise it creates a deliberate review cycle, in place of hoping the same model catches its own errors.
• Parallel work becomes possible. In more complex systems, agents can tackle different parts of a larger goal at once, with a research agent and a writing agent handling separate subtasks.

The hard part, which each framework solves in its own way, is communication. How do agents exchange information? Do they share one conversation, or hold isolated exchanges that only occasionally intersect? The answers differ between AutoGen and CrewAI, and the difference shapes everything else.

AutoGen: everything is a conversation

Microsoft's AutoGen treats each agent interaction as a conversation. Its founding decision is that agents talk to each other in natural language, the way people do in a chat thread. That makes it intuitive: anyone who has watched two colleagues in a Slack channel go back and forth refining an idea already holds the mental model behind AutoGen's conversable agents.

Trying it in AutoGen Studio

Before any Python is written, AutoGen Studio offers a graphical way to experiment. It installs with pip, reads an API key from an environment variable and starts from a single command-line call. A browser interface then opens. Type a task there, and a user proxy agent works with one or more assistant agents until it is done.

The pattern that appears is worth learning, because it recurs everywhere. Say the request is to plot the popularity of a search term over time. The assistant agent begins producing code snippets for the subtasks. The user proxy agent then runs those snippets in a sandboxed environment and judges whether the result looks right. If the code fails or the output is wrong, the proxy sends feedback back, the assistant revises, and the cycle of code, execute, evaluate and revise continues until the proxy is satisfied.

That loop automates the human part of code review. In a normal session a developer writes code, runs it, watches it fail and fixes the bug personally. Here the proxy takes over the run-and-check step, so a person can walk away while the two agents sort it out. It is not flawless, since changed libraries or deprecated features sometimes trip the agent up, but for well-scoped problems it is remarkably effective. Image generation, data visualisation and short applications often finish within a couple of iterations.

One recommendation comes up repeatedly: run AutoGen and AutoGen Studio inside Docker whenever generated code could touch the underlying operating system. Agents are designed to write and execute arbitrary code, so a container protects the host from side effects. The advice gains weight as agents are given more autonomy.

Skills as extra abilities

Studio ships with only a few built-in tools, such as fetching web content or generating images. Its real strength lies in custom skills. A skill is an ordinary Python function with a clear name and a well-written docstring, and the framework reads that documentation to decide when and how to call it.

A worked example writes a describe_image skill, which sends an image to a model with vision abilities and gets a description back. Registered with the main assistant, it enables a pleasingly specific request: create a book cover for a given title, then use the image-description skill to check that the title text is spelled correctly. Image generators are notoriously poor at legible text, so this makes a natural verification loop. The assistant produces an image, the vision skill checks the lettering, and if it is wrong the assistant tries again. Composing small, well-documented tools yields behaviour that is surprisingly resilient.

A design philosophy sits underneath. Rather than counting on agents to write brand-new code for every need, it is often sturdier to hand them a fixed library of tested skills. Code an LLM writes on the fly can break when libraries evolve or dependencies shift, whereas a reviewed, packaged skill behaves predictably. Whether agents should write code dynamically or call prebuilt tools returns later in discussions of planning and action, and it is among the more consequential choices when designing an agent system.

Raw code with pyautogen

After Studio, the next step is writing Python against the pyautogen package. Two building blocks matter:

• ConversableAgent is a general-purpose agent that talks directly to an LLM.
• UserProxyAgent stands in for the human user and can execute code in a working directory.

A minimal setup connects the two and starts a conversation, for example asking for a one-line FizzBuzz solution. When run, the proxy asks for feedback after the assistant proposes something. Pressing Enter with no feedback tells it to go ahead and run the code itself. If a needed package such as Pygame is missing, the proxy installs it before executing the program. That self-provisioning is a small but telling sign of the freedom these systems may be given, with upsides and downsides alike.

Handy coding challenges for gauging a model include checking whether a number is prime, building a Snake game and building an Asteroids clone in Pygame. They are self-contained, testable and varied enough in difficulty to expose differences between models or configurations.

Adding a critic through nested chats

An assistant plus a proxy is useful, but multi-agent systems earn their keep with specialised personas. A second assistant can act as a code reviewer, with a system message that makes it thorough, strict about standards and focused on security and quality problems.

Rather than dropping the critic straight into the main conversation, AutoGen offers nested chats. The user proxy registers a nested chat that fires whenever the engineer agent produces new output. The code goes to the critic automatically, inside a side conversation of its own; the critic replies with a review, and that review is fed back into the main thread. A review step is inserted without the critic cluttering every turn, and it speaks only when there is something new to inspect.

On a task like writing a Snake game with Pygame, the difference from a plain engineer-plus-proxy run is noticeable. After the code executes, the critic arrives with a list of suggested improvements, effectively reproducing the pull-request review that human teams carry out daily.

Caching to control cost

Multi-agent conversations get expensive fast. Every exchange consumes tokens, and complicated tasks may need dozens of turns. AutoGen includes a caching system: by default, conversation state is saved to disk in a .cache folder, so a long or interrupted task can resume without paying for the same tokens twice.

The behaviour can be set explicitly by wrapping the chat call in a context manager that supplies a cache_seed. The point is easy to underrate. In agent development it is common to want to replay or audit an earlier run instead of regenerating it, whether to debug or to show stakeholders exactly how an agent reached an output.

Group chat and the telephone problem

Nested chats have a structural weakness that recalls the children's game of telephone. Information is relayed from one agent to the next in a chain, and details get lost, distorted or reinterpreted at each hop. If the critic never sees the full original task, only what the engineer decided to forward, its feedback can miss the point.

AutoGen's remedy is group chat. A GroupChat object keeps one shared pool of agents and messages, comparable to a team channel, in place of a series of point-to-point relays. A GroupChatManager coordinates turn-taking so agents do not all reply at once. The key property is that every member can see the entire conversation history, not only what was explicitly passed to it.

Rebuilding the engineer-and-critic example with group chat gives more coherent collaboration. The critic's feedback rests on the same full context the engineer had, and the engineer can answer specific critiques directly instead of working from a paraphrase. The price, unsurprisingly, is verbosity. Group conversations burn more tokens because every agent effectively listens to every exchange, which matters when paying per token at scale.

What the early examples teach

Taken together, the Studio sessions and the raw-code experiments make a few points that carry over to any agent project. A task should be small enough that success can be checked, because the proxy loop only works when something can say whether the output is right. Execution should be isolated, since the same autonomy that makes the loop useful also lets it install packages and run arbitrary programs. Reviews are cheap to add once roles exist, so a critic is nearly always worth trying. And cost belongs in the design from the start: caching, replay and a sense of how many turns a task needs are part of building the system, not afterthoughts.

There is also a lesson about where to put effort. Writing a good system message for the critic, or a clear docstring for a skill, changes behaviour far more than adding more agents does. Both frameworks reward precise, narrow descriptions of what each agent is for.

CrewAI: structure over improvisation

Where AutoGen leans into open-ended conversation, CrewAI is more structured and opinionated, clearly aimed at business and production settings. Instead of free-flowing dialogue, it asks for three explicit definitions: the agents, with roles, goals and backstories; the tasks they are assigned; and the crew that binds them together under a defined processing strategy.

What an agent is made of

A CrewAI agent is configured through a handful of parameters:

• role: a short label for the agent's function, such as Senior Joke Researcher.
• goal: a natural-language statement of what the agent tries to achieve, often templated for reuse with different inputs.
• backstory: a persona-building narrative that supplies context and personality, much like a system-prompt persona.
• memory and verbose: flags controlling whether the agent keeps context across interactions and whether it prints its reasoning to the console.
• allow_delegation: whether the agent may hand work off to others in the crew.

Tasks are defined separately. Each carries a description of the work, an expected_output field describing what success looks like to the agent and to the reader, a reference to the agent responsible, and options such as running asynchronously or writing the result to a file.

The Crew object finally assembles agents and tasks together with settings for how collaboration unfolds, sequential or hierarchical, plus options for sharing memory, caching, and a cap on requests per minute that keeps API usage in check.

A playful example: the joke crew

To make this concrete, a two-agent joke crew is built. A Senior Joke Researcher analyses what makes a topic funny and notes relevant social trends, and a Joke Writer turns that research into an actual joke. The researcher may delegate, while the writer may not. That is a sensible division, as the writer is meant to be the last step in the pipeline and not a hub that farms work back out.

Given a topic like AI engineer jokes, the crew produces genuinely amusing output through a research-then-write pipeline in place of one monolithic prompt. Though silly, it illustrates why separating understanding the domain from producing the creative result can give more thoughtful output. The researcher's groundwork acts as grounding context for the writer, like a miniature retrieval step built into the workflow.

AgentOps: watching the money go

Agent developers keep returning to a plain worry: what does this run cost, and where does the time go? Left unmonitored, multi-agent systems can produce startling bills, since every agent-to-agent exchange, delegation and tool call adds up. AgentOps is an observability platform built for LLM agent behaviour, unlike traditional MLOps tooling, which was not designed for autonomous, conversational agents.

Adding it to a CrewAI project takes little effort: install the package, get an API key, put the key in the environment configuration and initialise the library at the top of the script. Every crew run is then logged to a dashboard showing:

• the total duration of the run and the environment it ran in,
• prompt and completion token counts for each LLM call,
• timing for each individual call,
• an estimated dollar cost for the whole run.

The last item is eye-opening the first time. A single run of the joke crew, which feels trivial to a human, costs a non-trivial fraction of a dollar once all the intermediate reasoning, delegation and tool calls are added up. For anyone building agent systems with commercial ambitions that is a healthy reality check: orchestrating agents is powerful but not free, and observability turns an abstract cost into a number that can be budgeted and optimised.

A game development crew

For a direct comparison with the AutoGen coding examples, CrewAI is used to assemble a small game development team of three agents:

1. A Senior Software Engineer writes the Python implementation of whatever game is requested.
2. A Software Quality Control Engineer reviews the code for defects, from absent imports and unbalanced brackets to security holes and faulty logic.
3. A Chief QA Engineer may delegate and is ultimately responsible for confirming that the finished code fulfils the original request.

The tasks mirror that structure. One produces the initial implementation, a second audits it for defects, and a third merges both into a final, corrected version. This three-stage review pipeline of write, critique and finalise is a more elaborate echo of AutoGen's engineer-and-critic pattern, expressed through CrewAI's declarative separation of tasks from agents.

When run interactively, with the script asking what kind of game is wanted and how it should behave, the code tends to be noticeably more polished than from a single unsupervised coding agent. Part of the reason is that the Chief QA Engineer's oversight catches issues that might otherwise slip through.

Sequential versus hierarchical processing

CrewAI offers two ways to organise how a crew works through tasks, and picking correctly matters.

Sequential processing is the default and the simplest. Tasks run one after another in the order defined, and each agent finishes before handing off. It suits pipelines whose steps genuinely depend on each other in fixed order: research then write, or implement then review then finalise.

Hierarchical processing puts a manager over the crew, usually its own LLM connection used only for coordination, which supervises agents and tasks instead of letting them march in lockstep. Switching is easy: specify Process.hierarchical instead of Process.sequential and supply a manager_llm, commonly a ChatOpenAI instance with temperature zero for steadier oversight decisions.

On paper the hierarchical mode should win, since a manager role mirrors how larger human organisations operate. The experiments say otherwise. The same game task, run under a hierarchical manager, cost over twice as much according to AgentOps, and the code was no meaningfully better for it. It is a humbling data point. Adding coordination, oversight and layers of agents does not automatically improve results, and multi-agent systems can just as easily spiral into expensive, unproductive loops when nobody is watching closely.

Catching runaway agents

That finding links to a subtle failure mode: repetitive thought patterns. An agent not confident in its own output can circle through variations of the same idea instead of committing and moving on, burning tokens and money without real progress.

AgentOps has a Repeat Thoughts visualisation for exactly this, plotting how often an agent's reasoning returns to similar content during a run. Heavy repetition is a signal that something structural has to change. Maybe the task descriptions are too ambiguous, maybe too many agents are involved for the problem's complexity, or maybe the processing mode deserves a second look. Diagnostics like this separate casual experimentation from disciplined, production-grade work. It is better to see when things go wrong than to wait for a suspiciously large invoice.

Communication styles side by side

The question raised at the start, how agents pass information around, now has concrete answers. AutoGen offers two models. Nested chats relay material through side conversations, which keeps the main thread tidy but risks losing detail at each hop. Group chat gives everyone the full history, which improves coherence at the cost of tokens. CrewAI sidesteps the choice by making the hand-off explicit: each task names its agent and its expected output, and the process setting decides whether results move down a line or through a manager. One approach favours emergent collaboration and the other favours a pipeline that can be read in advance.

Neither removes the need to watch the bill. Both generate more model calls than a single prompt, and both can loop. That is why the observability tooling matters as much as the framework choice.

Picking between the two

Neither framework wins outright. Each reflects a different belief about how much scaffolding a multi-agent system should have. AutoGen lets structure arise out of the conversation itself, whereas CrewAI asks the builder to spell it out in advance.

AutoGen fits when:

• maximum flexibility is wanted and agents may improvise their approach through open dialogue;
• the task benefits from exploratory back-and-forth, such as brainstorming or iterative debugging, where the right sequence of steps is unknown in advance;
• an approachable visual entry point like AutoGen Studio is useful for non-technical experimentation before committing to code.

CrewAI fits when:

• predictable, auditable pipelines with clear roles and responsibilities are needed, as in enterprise workflows where consistency outweighs improvisation;
• built-in memory, caching and rate limiting are preferred over hand-rolled versions;
• first-class observability matters, given how nearly frictionless the AgentOps integration is.

In practice, many real projects will borrow from both: CrewAI's declarative clarity for the well-understood parts of a pipeline, and AutoGen's conversational flexibility for the messier, exploratory ones.