1 Overview: Agents That Talk to Each Other

Semantic Kernel's Agent Framework gave you agents, planners, and orchestration patterns built around a kernel of plugins and threads. AutoGen approaches the same problem — coordinating multiple AI agents toward a goal — from a different angle: agents are fundamentally conversable, and collaboration happens by agents exchanging messages in a conversation, with roles, tools, and termination rules layered on top of that simple idea. AutoGen has a .NET surface (AutoGen.NET) alongside its Python roots, so the concepts and much of the API shape carry directly into C#.

This advanced tutorial covers AutoGen fundamentals — conversable agents, AssistantAgent, and UserProxyAgent; agent collaboration patterns like two-agent chat and GroupChat; tool use and function calling in AutoGen, which mirrors what you built in tutorial 12 and automated in tutorial 17; debugging and controlling agents through chat history, human-in-the-loop modes, and termination conditions; and building a multi-agent problem-solving system with the classic Planner, Developer, Reviewer role split. Everything here is a second, contrasting answer to the same design questions Semantic Kernel's Agent Framework raised in the previous tutorial.

2 Learning Objectives

• Explain AutoGen fundamentals: conversable agents, AssistantAgent, UserProxyAgent, and how a conversation drives collaboration.
• Compare agent collaboration patterns — two-agent chat and GroupChat with speaker selection — and choose the right one for a task.
• Register and use tools/functions in AutoGen so agents can call real code, and relate it to tutorial 12's function calling.
• Debug and control AutoGen agents using chat history, human-in-the-loop modes, and termination conditions.
• Design agent roles — Planner, Developer, Reviewer — with distinct responsibilities and instructions.
• Build a multi-agent problem-solving system in .NET combining roles, tools, and controlled termination.

3 Prerequisites

• Tutorial 18 in full: agents, threads, planners, orchestration patterns, termination and selection strategies — the concepts this tutorial contrasts against.
• Tutorial 12's function-calling loop and its safety disciplines, since AutoGen's tool use rests on the same foundation.
• C# comfort with async/await and delegates/callbacks, used when registering functions with AutoGen agents.
• An Azure OpenAI chat deployment, reused here as the model backing AutoGen's AssistantAgent.

4 Key Concepts: Everything Is a Conversation

AutoGen's organizing idea is that a conversable agent is the one abstraction you need: an agent that can send and receive messages, optionally call tools, and participate in a conversation with other agents. Two built-in roles cover most needs: an AssistantAgent is model-backed and reasons, drafts, and responds; a UserProxyAgent represents the human or the execution environment, and can run code or tools and relay results back in. Multiple agents collaborate by exchanging messages — either directly (two-agent chat) or through a GroupChat with a manager that selects speakers and decides when to stop.

The practical upshot: nearly everything you learned about autonomy, orchestration, and guardrails in tutorial 18 transfers conceptually. What changes is the vocabulary and the default mental model — AutoGen nudges you to think in terms of who is talking to whom, while Semantic Kernel nudges you to think in terms of a kernel's capabilities and a thread's state. Neither is more correct; they are different, useful lenses on the same underlying problem.

5 Deep Dive 1: AutoGen Fundamentals and Agent Collaboration Patterns

An AssistantAgent wraps a chat model with a system message defining its role, exactly like a ChatCompletionAgent's instructions. A UserProxyAgent is the counterpart that can act on the assistant's behalf — running code, calling tools, or (in human-in-the-loop mode) actually pausing for a person's input — and relaying the outcome back into the conversation. The simplest collaboration pattern, two-agent chat, has exactly these two exchange messages until a termination condition fires.

using AutoGen.Core;
using AutoGen.OpenAI;

// AssistantAgent: model-backed, reasons and drafts.
var assistant = new OpenAIChatAgent(
    chatClient: azureOpenAIChatClient,
    name: "assistant",
    systemMessage: "You are a helpful assistant that writes concise C# code.")
    .RegisterMessageConnector();

// UserProxyAgent: represents the human/environment; can auto-reply or wait for input.
var userProxy = new UserProxyAgent(
    name: "user",
    humanInputMode: HumanInputMode.NEVER);   // fully automated for this run

// Two-agent chat: they exchange messages until a termination condition fires.
var conversation = await userProxy.InitiateChatAsync(
    receiver: assistant,
    message: "Write a C# method that reverses a string.",
    maxRound: 5);

foreach (var msg in conversation)
    Console.WriteLine($"{msg.From}: {msg.GetContent()}");

GroupChat generalizes two-agent chat to more participants: a GroupChatManager selects the next speaker (round-robin, a model-driven choice, or a custom rule — the same job as Semantic Kernel's selection strategy) and evaluates termination (the same job as a termination strategy). Choosing between two-agent chat and GroupChat mirrors tutorial 18's choice between a single agent and orchestration: use two-agent chat for a focused exchange (ask, execute, report back), and GroupChat when three or more distinct perspectives need to collaborate. Both are conversation patterns — reusable structures for how agents interact — and picking the right one for a given collaboration is a design decision, not a default.

6 Deep Dive 2: Tool Use and Function Calling in AutoGen

Tool use in AutoGen mirrors tutorial 12's function calling directly: you describe a function, the model requests it during the conversation, and your code executes it and returns the result as a message. AutoGen's mechanism is a function map — a registry connecting function names the model can request to the actual C# methods that run them — typically attached to the UserProxyAgent, since it is the agent that acts on the assistant's behalf.

// The function the model can request — same safety discipline as tutorial 12.
async Task<string> GetOrderStatusAsync(string orderNumber)
{
    if (!orderNumber.StartsWith("ORD-")) return "{\"error\":\"invalid order number\"}";
    var status = await OrderRepository.FindAsync(orderNumber);
    return status is null ? "{\"error\":\"not found\"}"
                          : $"{{\"stage\":\"{status.Stage}\",\"eta\":\"{status.Eta}\"}}";
}

// The function map: name the model uses -> the delegate that executes it.
var functionMap = new Dictionary<string, Func<string, Task<string>>>
{
    ["get_order_status"] = GetOrderStatusAsync
};

var userProxy = new UserProxyAgent(
    name: "user",
    humanInputMode: HumanInputMode.NEVER)
    .RegisterMessageConnector()
    // AutoGen wires the function map so tool calls the assistant requests get executed here.
    .RegisterFunctionMap(functionMap);

The assistant, given a description of get_order_status (name, description, parameters — the same information as a tutorial-12 JSON schema or a Semantic Kernel [KernelFunction]), can request it mid-conversation; the UserProxyAgent looks the name up in the function map, executes the corresponding delegate, and returns the result as the next message. The loop — request, execute, respond, continue — is the same tool-calling mechanism across tutorial 12, Semantic Kernel, and AutoGen; only the registration mechanics differ. A related capability, code execution, lets a UserProxyAgent run model-generated code directly (not just a pre-registered function) and feed the output back into the conversation — useful for open-ended tasks, but it demands the same sandboxing and validation caution as any function that executes arbitrary logic.

7 Deep Dive 3: Debugging and Controlling Agents

AutoGen's chat history is the primary debugging tool: the full ordered record of messages, including tool requests and results, that a conversation produced. Because collaboration is literally a sequence of messages, reading that sequence back tells you exactly what each agent said, when, and why the conversation ended — the same value tutorial 18's step-by-step logging provided, but built into the conversation object itself rather than added separately.

Control comes from two mechanisms. Human-in-the-loop mode on a UserProxyAgent — ALWAYS, NEVER, or TERMINATE (ask only when the conversation would otherwise end) — decides whether and when a human is consulted before the proxy acts, directly implementing tutorial 18's human-in-the-loop checkpoint concept as a first-class agent setting rather than custom code around a plan. Termination conditions — a keyword in a message, a maximum round count, or a custom function over the chat history — decide when the conversation stops, exactly mirroring tutorial 18's termination strategy, and exactly as non-negotiable: a semantic condition alone is not enough.

// maxRound is AutoGen's equivalent of Semantic Kernel's MaximumIterations —
// a hard backstop alongside any keyword/custom termination check.
var conversation = await userProxy.InitiateChatAsync(
    receiver: assistant,
    message: "Draft and refine a summary until it says APPROVED.",
    maxRound: 8);   // stops here even if APPROVED never appears

bool converged = conversation.Any(m => m.GetContent()?.Contains("APPROVED") == true);
logger.LogInformation("Conversation ended after {Rounds} messages; converged={Converged}",
    conversation.Count, converged);

8 Deep Dive 4: Agent Roles — Planner, Developer, Reviewer

A common, well-tested multi-agent problem-solving system assigns three specialized agent roles to a GroupChat. A Planner agent breaks a goal into a sequence of concrete steps. A Developer agent produces an artifact — typically code — implementing the current step. A Reviewer agent critiques the artifact, approving it or requesting specific changes. Each role is just an AssistantAgent with a system message narrowly scoped to that responsibility — the same 'narrow, specific instructions' discipline tutorial 18 recommended for every agent.

var planner = new OpenAIChatAgent(azureOpenAIChatClient, name: "planner",
    systemMessage: "Break the goal into a short numbered list of concrete steps. " +
                   "Do not write code yourself.")
    .RegisterMessageConnector();

var developer = new OpenAIChatAgent(azureOpenAIChatClient, name: "developer",
    systemMessage: "Implement the current step in C#. Wait for Reviewer approval " +
                   "before moving to the next step.")
    .RegisterMessageConnector();

var reviewer = new OpenAIChatAgent(azureOpenAIChatClient, name: "reviewer",
    systemMessage: "Review the Developer's code for correctness and clarity. " +
                   "Reply APPROVED or list specific required changes.")
    .RegisterMessageConnector();

var groupChat = new GroupChat(
    members: new[] { planner, developer, reviewer },
    admin: reviewer);   // e.g. reviewer's APPROVED can gate progress/termination

var manager = new GroupChatManager(groupChat) { MaxRound = 12 };   // hard backstop
var result = await manager.InitiateChatAsync(
    "Goal: implement and review a C# method that validates an email address.");

This role split maps directly onto tutorial 18's orchestration patterns: it is essentially a group chat orchestration with three specialized agents, a speaker-selection rule that lets Planner start, Developer act, and Reviewer gate progress, and a termination condition (Reviewer's approval, backstopped by MaxRound). Building a multi-agent problem-solving system, in AutoGen or Semantic Kernel, comes down to the same design sequence: define each role's narrow responsibility, choose how turns are sequenced, and set a termination condition with a hard cap before running anything.

9 Ecosystem and Tools

AutoGen and Semantic Kernel's Agent Framework are not mutually exclusive in an organization's toolkit — some teams use Semantic Kernel where deep integration with plugins, memory, and the wider kernel ecosystem matters, and AutoGen where its conversation-first model and role-based patterns (Planner/Developer/Reviewer) fit the problem more naturally. Both ultimately call the same underlying Azure OpenAI deployments and need the same guardrails.

10 Use Cases

• Code generation and review: a Planner/Developer/Reviewer GroupChat produces, critiques, and refines a small piece of code from a natural-language goal.
• Automated research assistant: a two-agent chat where an AssistantAgent researches and a UserProxyAgent executes search/tool calls and relays results back.
• Data analysis pipelines: an agent proposes an analysis approach, a tool-using agent executes it against real data, and a reviewer agent checks the output.
• Human-supervised automation: a UserProxyAgent in TERMINATE human-input mode lets agents run autonomously but pauses for approval at natural conversation endpoints.
• Debugging support tools: an AssistantAgent proposes a fix, a UserProxyAgent runs tests via a registered function, and results feed back for another round.
• Comparative prototyping: teams prototype the same multi-agent idea in both AutoGen and Semantic Kernel to evaluate which framework's model fits their system better before committing.
• Structured problem decomposition: any goal too broad for one prompt (build a feature, produce a report, resolve an incident) benefits from a Planner breaking it down before other agents act.

As with Semantic Kernel orchestration, the throughline is coordination: whenever a task benefits from distinct roles conversing toward a goal, AutoGen provides a conversation-native way to build it, with the same guardrail requirements as any autonomous multi-agent system.

11 Code Examples

These examples assemble AutoGen's pieces into one flow: a tool-using UserProxyAgent, an AssistantAgent, and a controlled conversation with logging.

var assistant = new OpenAIChatAgent(azureOpenAIChatClient, name: "assistant",
    systemMessage: "Answer order questions using get_order_status. Never invent details.")
    .RegisterMessageConnector();

var userProxy = new UserProxyAgent(name: "user", humanInputMode: HumanInputMode.NEVER)
    .RegisterMessageConnector()
    .RegisterFunctionMap(new Dictionary<string, Func<string, Task<string>>>
    {
        ["get_order_status"] = GetOrderStatusAsync
    });

var conversation = await userProxy.InitiateChatAsync(
    receiver: assistant, message: "Where is ORD-1042?", maxRound: 5);

foreach (var msg in conversation)
    logger.LogInformation("{From}: {Content}", msg.From, msg.GetContent());

// TERMINATE mode: a human is asked only when the conversation would otherwise end,
// which naturally happens right before a high-stakes action is finalized.
var supervisedProxy = new UserProxyAgent(
    name: "user",
    humanInputMode: HumanInputMode.TERMINATE)
    .RegisterMessageConnector()
    .RegisterFunctionMap(new Dictionary<string, Func<string, Task<string>>>
    {
        ["cancel_order"] = CancelOrderAsync   // an irreversible action
    });

var conversation = await supervisedProxy.InitiateChatAsync(
    receiver: assistant, message: "Cancel order ORD-1042.", maxRound: 6);
// A human is prompted before the conversation concludes, giving a real
// checkpoint before cancel_order's effects are treated as final.

var groupChat = new GroupChat(members: new[] { planner, developer, reviewer }, admin: reviewer);
var manager = new GroupChatManager(groupChat)
{
    MaxRound = 12,   // hard backstop
    // Custom check alongside the round cap -- stop early if Reviewer approves.
    IsTerminationMessage = msg => msg.GetContent()?.Contains("APPROVED") == true
                                   && msg.From == "reviewer"
};

var result = await manager.InitiateChatAsync(
    "Goal: implement and review a C# email validator method.");

12 Step by Step: A Planner/Developer/Reviewer Problem-Solving System

This walkthrough builds a small but complete multi-agent problem-solving system in AutoGen, then compares it directly against tutorial 18's Semantic Kernel group-chat equivalent.

1. In a project with the AutoGen.NET package installed, configure an OpenAIChatAgent-based connector against your existing Azure OpenAI chat deployment.
2. Define the Planner agent: system message restricting it to producing a short numbered step list, explicitly forbidding it from writing code itself.
3. Define the Developer agent: system message instructing it to implement the current step in C# and wait for Reviewer approval before proceeding.
4. Define the Reviewer agent: system message instructing it to reply APPROVED or list specific required changes — explicit, checkable language, not open-ended critique.
5. Assemble a GroupChat with all three agents and a GroupChatManager configured with both a custom termination check (Reviewer says APPROVED) and a hard MaxRound backstop.
6. Send an initial goal message ('implement and review a C# method that validates an email address') and invoke the chat, printing each agent's turn from the returned conversation/chat history.
7. Confirm the conversation actually stops on Reviewer's APPROVED; then instruct the Reviewer to never approve and confirm MaxRound stops it instead — the same two-sided termination test as tutorial 18.
8. Add a tool: register a function (e.g. a mock code-analysis check) in the UserProxyAgent's function map so the Developer's code can be automatically checked before the Reviewer comments.
9. Add a human-in-the-loop checkpoint: switch the relevant UserProxyAgent to HumanInputMode.TERMINATE and observe that a person is consulted at the natural end of the conversation.
10. Compare against tutorial 18: rebuild the same Planner/Developer/Reviewer system as a Semantic Kernel GroupChatOrchestration and note which felt more natural to configure — the conversation-first API or the kernel-and-strategy API — for this particular team and task.

13 Limitations and Caveats

• API surface caveat: AutoGen.NET's exact types and method names (OpenAIChatAgent, RegisterMessageConnector, RegisterFunctionMap, GroupChat, GroupChatManager, HumanInputMode values) are illustrative of shape and intent here and have moved across AutoGen versions and its Python/.NET parity efforts — verify against the installed package before relying on them.
• Framework choice is not free: adopting both Semantic Kernel and AutoGen in one system adds two mental models and two sets of dependencies; most teams should pick one per system rather than mixing them within a single agent workflow.
• Tool use safety is unchanged from tutorial 12: AutoGen's function map executes real code with real effects, so validation, authorization, idempotency, and structured errors are still entirely your responsibility.
• Termination conditions share Semantic Kernel's caveat exactly: a keyword or custom check can misfire or never trigger, so a hard maxRound/MaxRound backstop is mandatory, not optional.
• Human-in-the-loop modes are a control surface, not a substitute for reviewing what they actually gate: ALWAYS mode that a person rubber-stamps without reading provides no real safety.
• Debugging still requires deliberate logging discipline: chat history captures messages, but interpreting why a GroupChat's speaker selection or a custom termination check behaved a certain way often needs additional instrumentation.
• Cost and latency scale with agent count and rounds exactly as in Semantic Kernel orchestration: each message is a model call, so role count and MaxRound double as cost controls.
• AutoGen's Python ecosystem is more mature than its .NET surface at present; some capabilities or community examples may only exist in Python and require translation to C# concepts.

14 Best Practices

• Give each agent role (Planner, Developer, Reviewer, or any custom role) a narrow, explicit system message — the same specificity discipline as every prior tutorial's instructions and tool descriptions.
• Make Reviewer-style approval language explicit and checkable ('reply APPROVED or list changes'), not open-ended, so termination conditions can match it reliably.
• Always pair a semantic termination condition with a hard maxRound/MaxRound backstop, exactly as in Semantic Kernel orchestration.
• Keep tutorial 12's function-level safety inside every function registered in a function map — tool use is still function calling, with the same stakes.
• Use HumanInputMode.TERMINATE (or ALWAYS for higher-stakes systems) for any workflow with irreversible or consequential actions, and ensure a human actually reviews the content, not just clicks approve.
• Log the full chat history for every run in development, and keep structured logging (agent, message, tool calls, termination outcome) in production.
• Choose two-agent chat for focused ask/execute/report exchanges and GroupChat only when three or more distinct perspectives genuinely improve the outcome.
• When a team already has deep Semantic Kernel investment (plugins, memory, Foundry integration), prefer extending that rather than introducing AutoGen for the same problem, and vice versa — avoid running both for one workflow without a clear reason.

20 Summary

• AutoGen's fundamental abstraction is the conversable agent — collaboration happens through message exchange, with AssistantAgent (model-backed) and UserProxyAgent (executes tools, relays results) as the two core built-in roles.
• Agent collaboration patterns run from focused two-agent chat to GroupChat, where a GroupChatManager handles speaker selection and termination for three or more participants.
• Tool use and function calling in AutoGen mirror tutorial 12's loop exactly, registered via a function map — the same safety discipline (validation, authorization, idempotency, structured errors) applies unchanged.
• Debugging and controlling agents rests on chat history (the built-in message record), human input modes (ALWAYS/TERMINATE/NEVER), and termination conditions — always backstopped by a hard round cap.
• The Planner/Developer/Reviewer role pattern decomposes a goal, implements it, and reviews it in a GroupChat, converging reliably only when the Reviewer's approval language is explicit and checkable.
• Every AutoGen concept maps directly onto Semantic Kernel's Agent Framework from tutorial 18 — the two frameworks are different, largely interchangeable answers to the same multi-agent coordination problem, and a team should pick one per system rather than mixing them.

You now have two complete, contrasting toolkits for building autonomous multi-agent systems in .NET — Semantic Kernel's kernel-and-plugin philosophy and AutoGen's conversation-and-role philosophy — and, more importantly, the underlying design vocabulary (agents, tools, orchestration/collaboration patterns, termination, human-in-the-loop) that transfers to whatever framework you encounter next. With both approaches to multi-agent coordination in hand, the course now turns from framework mechanics to architecture: how agent-first thinking reshapes application design at a higher level.

21 Next Steps

Next tutorial: Agent-First Architecture (agent-first-architecture). Having built agents in both Semantic Kernel and AutoGen, the next tutorial steps back from framework-specific mechanics to the architectural question: how do you design an application around agents as the primary unit of functionality, rather than bolting agent capability onto an existing request/response design?

• Practice: rebuild tutorial 18's Writer/Reviewer group chat orchestration as an AutoGen GroupChat, and compare which framework's configuration felt clearer for your team.
• Practice: build the full Planner/Developer/Reviewer system from the walkthrough, then deliberately give the Reviewer vague instructions and observe the convergence failure before fixing it.
• Practice: add a function map tool to a two-agent chat, then switch the UserProxyAgent to HumanInputMode.TERMINATE and observe the checkpoint before the conversation concludes.
• Practice: log a full chat history to a file for one run and use it to answer 'why did this conversation take exactly this many rounds' without adding any extra instrumentation.
• Read: the official AutoGen documentation for 'AutoGen.NET', 'Conversable agents', 'GroupChat', and the AutoGen function-calling/tool-use guide.