Understanding the Microsoft Agent Framework and OpenTelemetry

The Microsoft Agent Framework is designed to facilitate the development of intelligent agents that can interact with users and other systems. With the integration of OpenTelemetry, MAF now offers a robust solution for tracking and analyzing agent behavior, performance, and interactions. OpenTelemetry is a set of APIs, libraries, and tools that enable developers to collect and export telemetry data, such as logs and metrics, from their applications. This integration allows for a more comprehensive understanding of how AI agents operate in real-world scenarios.

Key Trends and Innovations

1. Unified Observability

One of the standout features of the MAF’s integration with OpenTelemetry is the support for OpenTelemetry conventions. This allows for a unified timeline of tasks across different agents and tools, which is crucial for understanding the interactions and performance of AI agents in production environments. By providing a coherent view of agent activities, developers can more easily identify patterns and correlations that may impact performance.

2. Instrumentation Layer

The MAF includes an automatic instrumentation layer that tracks various metrics, such as token consumption, interaction durations, and tool usage. This layer is essential for diagnosing issues and optimizing agent performance. By automatically capturing these metrics, developers can focus on building and improving their agents rather than spending time on manual logging and monitoring.

3. Integration with Azure

Another significant advantage of the MAF’s integration with OpenTelemetry is its ability to ship traces to Azure AI Foundry. This centralized monitoring and analysis capability allows teams to gain insights into agent behavior across different environments. By leveraging Azure’s powerful analytics tools, developers can visualize performance metrics and identify areas for improvement.

Real-World Use Cases

The integration of OpenTelemetry into the Microsoft Agent Framework opens up a range of practical applications for developers:

• Debugging and Evaluation: Developers can utilize OpenTelemetry to trace agent interactions, making it easier to identify bottlenecks or failures in real-time. This capability is invaluable for ensuring that agents perform as expected and for quickly addressing any issues that arise.
• Performance Monitoring: By tracking metrics such as latency and interaction counts, teams can optimize their agents for better user experiences. Understanding how agents perform under different conditions allows developers to make informed decisions about enhancements and adjustments.

Supporting Data and Quotes

The importance of OpenTelemetry in enhancing observability is underscored by insights from industry experts. According to a Microsoft Tech Community blog post, “OpenTelemetry for traces/spans + attributes (agent, tool, retrieval, latency, tokens)” enables detailed monitoring of agent activities. This level of granularity is essential for developers looking to improve their systems.

As of now, the framework is in public preview (version 1.0.0-rc1), with stable OpenTelemetry contracts guiding its development. This means that developers can start experimenting with these features and provide feedback to shape the future of the framework.

A Simple Explanation of OpenTelemetry

OpenTelemetry can be thought of as a toolkit that helps developers collect and export telemetry data from their applications. In the context of the Microsoft Agent Framework, it allows developers to track how their AI agents are performing, making it easier to spot issues and improve functionality. This is particularly important in complex systems where multiple agents interact with each other and with users.

Code Example: Using OpenTelemetry with the Microsoft Agent Framework

To illustrate how developers can leverage OpenTelemetry within the Microsoft Agent Framework, consider the following C# code example. This snippet demonstrates how to start an activity for an agent session and log interactions using OpenTelemetry:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using Microsoft.Extensions.Logging;

public class Agent
{
    private static readonly ActivitySource activitySource = new ActivitySource("Microsoft.Extensions.AI");

    public void StartSession(string sessionId, ILogger logger)
    {
        logger.LogInformation("Starting agent session with ID: {SessionId}", sessionId);
        using (var activity = activitySource.StartActivity("Agent Session"))
        {
            int interactionCount = 0;
            while (true)
            {
                Console.Write("You (or 'exit' to quit): ");
                var input = Console.ReadLine();
                if (string.IsNullOrWhiteSpace(input) || input.Equals("exit", StringComparison.OrdinalIgnoreCase))
                {
                    logger.LogInformation("User requested to exit the session");
                    break;
                }
                interactionCount++;
                logger.LogInformation("Processing interaction #{InteractionCount}", interactionCount);
                using (var interactionActivity = activitySource.StartActivity("Agent Interaction"))
                {
                    // Simulate processing the input
                }
            }
        }
    }
}

In this example, the StartSession method initiates an agent session and logs each interaction. Each interaction is tracked as a child span, allowing for detailed performance analysis. This approach not only enhances observability but also provides developers with the tools they need to optimize their agents effectively.

Conclusion

The integration of OpenTelemetry into the Microsoft Agent Framework represents a significant advancement in the monitoring and debugging of AI agents. By leveraging these tools, developers can gain valuable insights into their systems, leading to improved performance and user satisfaction.

Importance of Logging

1. Debugging and Monitoring

Logging serves as a vital tool for debugging and monitoring the behavior of agents within a multi-agent system. Given the complexity of interactions among agents, it is crucial to have a clear understanding of their operations. Logs provide insights into the flow of operations, enabling developers to identify issues and rectify them promptly. For instance, if an agent fails to respond to a user query, logs can help trace back the steps leading to the failure, allowing for quicker resolution.

2. Performance Metrics

In addition to aiding in debugging, logging is instrumental in gathering performance metrics. By logging various performance indicators, developers can analyze the efficiency of agents and optimize their operations. This is particularly important in systems where performance directly impacts user experience. For example, logging response times can help identify slow agents, leading to targeted optimizations that enhance overall system performance.

3. Audit Trails

Logging also plays a critical role in maintaining audit trails. In many applications, especially those dealing with sensitive data or compliance requirements, it is essential to have a historical record of actions taken by agents. This not only aids in accountability but also ensures that organizations can meet regulatory requirements. Logs can provide a detailed account of agent interactions, decisions made, and actions taken, which is invaluable during audits.

Key Trends and Innovations

Centralized Logging

One of the best practices in modern software development is the implementation of centralized logging systems. Centralized logging aggregates logs from multiple agents into a single repository, making it easier to analyze and monitor the entire system. This approach simplifies the process of identifying issues that may arise from interactions between agents, as developers can view all relevant logs in one place.

OpenTelemetry Integration

The Microsoft Agent Framework supports OpenTelemetry, a set of APIs, libraries, agents, and instrumentation to provide observability for applications. By integrating OpenTelemetry for tracing and logging, developers can create a coherent timeline of agent interactions and performance metrics. This integration allows for more sophisticated monitoring and analysis, enabling developers to gain deeper insights into their systems.

Real-World Use Cases

Agent Interaction Tracking

In customer service applications, logging can be used to track how agents respond to user queries. By analyzing these logs, organizations can identify patterns in agent behavior, assess the effectiveness of different response strategies, and ultimately improve customer satisfaction. For instance, if logs reveal that certain types of queries consistently lead to longer response times, organizations can provide additional training or resources to agents handling those queries.

Performance Analysis

In logistics and supply chain management, multi-agent systems are often employed to optimize workflows. Logging can help identify bottlenecks in these workflows by providing insights into agent performance. For example, if logs indicate that a particular agent is consistently slow in processing tasks, developers can investigate the underlying causes and implement optimizations to enhance efficiency.

Implementation Example

To illustrate how logging can be implemented in a Microsoft Agent Framework application, consider the following example using C# and OpenTelemetry. This example demonstrates a simple agent that logs its activities during a session.

using Microsoft.Extensions.Logging;
using System;
using System.Diagnostics;

public class Agent
{
    private readonly ILogger<Agent> _logger;
    private readonly ActivitySource _activitySource;

    public Agent(ILogger<Agent> logger)
    {
        _logger = logger;
        _activitySource = new ActivitySource("AgentActivitySource");
    }

    public void StartSession(string sessionId)
    {
        _logger.LogInformation("Starting agent session with ID: {SessionId}", sessionId);
        using (var activity = _activitySource.StartActivity("Agent Session"))
        {
            // Simulate agent interactions
            for (int i = 0; i < 5; i++)
            {
                ProcessInteraction(i);
            }
        }
    }

    private void ProcessInteraction(int interactionCount)
    {
        _logger.LogInformation("Processing interaction #{InteractionCount}", interactionCount);
        // Simulate processing logic
    }
}

Explanation of the Code

In this example, we define an Agent class that utilizes the ILogger interface for logging. The StartSession method initiates a new session and logs the session ID. Within this method, we create an Activity using ActivitySource, which allows us to trace the session’s activities. The ProcessInteraction method simulates processing interactions and logs each interaction count.

This simple implementation showcases how logging can be seamlessly integrated into an agent’s workflow, providing valuable insights into its operations.

Conclusion

Adding logging to a multi-agent application using the Microsoft Agent Framework is essential for effective monitoring, debugging, and performance analysis. By leveraging centralized logging and tools like OpenTelemetry, developers can gain valuable insights into their systems, leading to improved agent performance and user satisfaction. As multi-agent systems continue to grow in complexity, the importance of robust logging practices will only increase, making it a critical component of successful application development.

Incorporating logging not only enhances the reliability of multi-agent systems but also empowers developers to make informed decisions based on real-time data, ultimately driving innovation and efficiency in their applications.

In the next blog post I’ll add this to the Blogger application we saw here.

In the rapidly evolving landscape of software development and productivity tools, understanding the distinctions between various Microsoft AI-assisted applications is crucial for developers and users alike. This post will delve into the differences between Copilot, Copilot Studio, GitHub Copilot, and the GitHub Copilot App, highlighting their unique features, use cases, and how they can enhance your workflow.

1. GitHub Copilot

GitHub Copilot is an AI-powered code completion tool developed by GitHub in collaboration with OpenAI. It functions as a virtual pair programmer, providing real-time suggestions for code snippets, functions, and even entire algorithms based on the context of the code being written. Integrated into popular Integrated Development Environments (IDEs) such as Visual Studio Code and JetBrains IDEs, GitHub Copilot is designed to streamline the coding process.

Key Features:

• Contextual Suggestions: GitHub Copilot analyzes the surrounding code and offers relevant code completions, making it easier for developers to write code efficiently.
• Multi-language Support: It supports a wide range of programming languages, including C#, Python, JavaScript, TypeScript, Ruby, and more, catering to diverse development needs.
• Learning from Open Source: Trained on a vast dataset of public code repositories, GitHub Copilot can suggest best practices and common coding patterns.

Use Case:

A developer working on a web application can leverage GitHub Copilot to quickly generate boilerplate code, implement functions, or debug existing code, significantly accelerating the development process.

2. GitHub Copilot App

The GitHub Copilot App is a standalone application that provides a user-friendly interface for interacting with GitHub Copilot’s features. This app allows users to access Copilot’s functionalities outside of traditional IDEs, making it easier to integrate AI assistance into various workflows.

Key Features:

• User-Friendly Interface: The app offers a more accessible way to interact with Copilot’s suggestions, making it suitable for users who prefer a visual interface rather than working a the CLI.
• Integration with GitHub: It seamlessly connects with GitHub repositories, allowing users to pull in code and suggestions directly from their projects.

Use Case:

A developer who prefers a more visual approach can utilize the GitHub Copilot App to manage coding tasks, receive suggestions, and collaborate with team members without being confined to a specific IDE.

3. Copilot Studio

Copilot Studio is a more advanced platform that empowers developers and non-developers to create and customize their own AI solutions in a low-code or no-code development platform. It provides tools for building tailored AI applications that can integrate with various APIs and processes, enabling users to develop specific functionalities that meet their unique needs.

Key Features:

• Customization: Users can create custom AI models and workflows tailored to their specific requirements, allowing for greater flexibility in application development.
• API Integration: Copilot Studio supports calling external APIs and processes, facilitating more complex interactions and functionalities.

Use Case:

A data scientist might use Copilot Studio to build a custom AI model that analyzes data from a specific source, providing insights and recommendations based on that data.

4. Microsoft 365 Copilot

Microsoft 365 Copilot focuses on enhancing productivity within the Microsoft 365 suite (Word, Excel, PowerPoint, etc.). This tool uses AI to assist users in automating tasks, generating content, and summarizing information.

Key Features:

• Office Integration: Microsoft 365 Copilot works within Microsoft Office applications to streamline workflows and enhance user experience.
• Task Automation: It helps automate repetitive tasks, allowing users to focus on more critical aspects of their work.

Use Case:

A business professional can utilize Microsoft 365 Copilot to draft emails, create presentations, or analyze data in Excel, significantly improving productivity.

Summary of Differences

• Scope of Use: GitHub Copilot is specifically designed for coding, while Copilot Studio allows for use by a broader audience. The GitHub Copilot App serves as a user-friendly interface for GitHub Copilot, and Microsoft 365 Copilot focuses on productivity within the Microsoft Office ecosystem.
• Integration: GitHub Copilot integrates with IDEs, while the GitHub Copilot App provides a standalone experience. Microsoft 365 Copilot integrates with Office applications to enhance productivity.

Conclusion

While all these tools share the common goal of enhancing productivity through AI, they cater to different audiences and use cases. GitHub Copilot and its app focus on coding assistance, Copilot Studio allows for low-code AI development, and Microsoft 365 Copilot enhances productivity in office applications.

As artificial intelligence continues to evolve, ensuring the safety and security of AI agents has become more important. The Microsoft Learn documentation on agent safety provides a comprehensive overview of best practices and guidelines for developers.

The concept of shared responsibility is central to agent safety. While the Microsoft Agent Framework offers foundational tools and abstractions, it is ultimately the responsibility of application developers to ensure secure data flows. This includes validating inputs, configuring tools appropriately, and understanding the specific security needs of their applications.

Best Practices for Safe Agents

To create safe AI agents, developers should adhere to several best practices:

• Deterministic Defenses: Implement label-based defenses to protect against prompt injection and data exfiltration. This proactive approach helps mitigate risks associated with adversarial inputs.
• Data Flow Understanding: Gain a thorough understanding of how data flows through various components of the agent, including user input, chat history, and context providers. This knowledge is crucial for identifying potential vulnerabilities.

Data Security Measures

Robust data security is essential, especially when handling sensitive information such as Personally Identifiable Information (PII). Developers must implement stringent security measures to protect this data throughout its lifecycle.

Awareness of Indirect Prompt Injection

Developers should be vigilant about the risks of indirect prompt injection, where adversarial content can manipulate the behavior of the language model (LLM). Recognizing these risks is vital for maintaining the integrity of AI agents.

Integration with Microsoft Security Tools

The documentation highlights the integration of Microsoft Agent Framework with existing security infrastructures, such as Microsoft Defender and Microsoft Entra. This integration enhances the overall security posture of AI agents, providing additional layers of protection.

Real-World Applications

The insights from the documentation have practical applications…

• Enterprise AI Operations: Organizations can leverage AI agents to manage operations at scale, transforming fragmented experimentation into trusted, reliable processes.
• Automating Security Tasks: Tools like Microsoft Security Copilot automate repetitive security tasks, allowing teams to focus on more strategic initiatives.

Supporting Data and Monitoring

Centralized visibility into AI agents is crucial for administrators. By monitoring usage and security signals, organizations can proactively manage their AI agents, ensuring they operate safely and effectively.

For more detailed information, refer to the Microsoft Learn documentation on Agent Safety.

* This article was generated by a collection of agents I wrote and documented in a previous blog post, and was then edited by me.

To accomplish this, your agents will need, at a minimum, structured logs of its plans, what tools it calls and an audit trail of the steps it takes.

There are four characteristics of valuable transparency:

• The information from the system accurately reflect the actual reasoning
• The audit report must be understandable by the reader
• The audit report must be updated in a timely manner
• There must be actions you can take to adjust the actions and plans as they develop

If the information is accurate but you can’t understand it, it is worthless. Similarly, if it comes too late or there is nothing you can do with it, it is also worthless.

With a good audit trail that tells you step by step what the agent is doing and why, you can view the outcome with a greater degree of trust. However, you must beware of the agent rationalizing its actions after performing them (don’t we all!).

To avoid thesse pitfalls, log extensively and frequently and make sure the agent is providing step by step rationle for its actions and ask it to surface any uncertainty: “For every action you take, provide a brief explanation of why you chose it, what the alternatives were and what uncertainties exist.”

Note, the updated source code for the .NET version of this demo application is available at https://github.com/JesseLiberty/blogMigration—public

The Microsoft Agent Framework (MAF) is an open-source software development kit (SDK) designed to facilitate the creation of agentic AI solutions and multi-agent workflows, primarily utilizing Python or C#.

Enterprise Focus

The framework is tailored to meet the complexities of deploying agentic AI in enterprise settings. It incorporates observability, security, and compliance.

Multi-Agent Workflows

MAF supports advanced orchestration of multiple agents. This capability enables different AI agents to collaborate effectively, which is crucial for applications that demand coordinated efforts across various tasks and functions. This is perfect for the application we’ve been working on.

Integration with Azure

MAF is deeply integrated with Azure services, allowing developers to harness cloud capabilities for enhanced scalability and performance. This integration ensures that applications built with MAF can efficiently handle varying workloads and user demands.

Agentic AI refers to AI systems capable of acting autonomously and making decisions based on their environment. The Microsoft Agent Framework simplifies the development and management of these systems by providing a comprehensive set of tools and libraries

With all that in mind, let’s look at modifying the raw C# to leverage the MAF…

Note: as part of this port to Microsoft Agent Framework I made good use of the extraordinary utility MAF-Doctor, which you can learn more about in my video interview with its author here, or the podcast here.

File Changes:

Prompts.cs Split each node’s prompt into a static instructions constant (the agent’s system prompt) — removed the {token} placeholder templating.

ResearcherAgent.cs Now a ChatClientAgent with Tavily attached as a tool — the model searches and summarizes in one run. Deleted ~40 lines of manual tool invocation + JsonDocument parsing + the second summarize call.

BloggerChain.cs LLM fallback uses structured output (RunAsync) — removed the “`-fence stripping and JsonSerializer.Deserialize. Deterministic routing preserved; comments clarify the workflow edges are the real router.

AuthorChain.cs Converted to a ChatClientAgent; role in Instructions, state as the per-turn message.

ReviewerChain.cs Converted to a ChatClientAgent + correctness fix: a failed review no longer auto-APPROVEDs — it requests revision instead (still bounded by MaxRevisions).

Program.cs Added .UseFunctionInvocation() to the IChatClient pipeline — required for the researcher’s tool calls to actually execute.

BlogWorkflow.cs Switched to RunStreamingAsync + WatchStreamAsync() to stream executor lifecycle events live; identical topology.

Let’s start with Prompt.cs. The comments show all the changes and the justification:

namespace BlogMigration;

/// <summary>
/// Prompt library for the blog-creation agents.
///
/// MAF idiom change (was: one big template per node mixing role + data):
/// each agent now has a *static* INSTRUCTIONS string (its system prompt / role)
/// that is set once on the <c>ChatClientAgent</c>, while the *dynamic* state
/// (task, findings, draft, review notes) is passed per-turn as the user message.
/// Separating the durable role from the volatile input is the recommended
/// Microsoft Agent Framework pattern: it keeps the system prompt cacheable,
/// lets the model treat instructions with higher priority than user input,
/// and removes the brittle <c>string.Replace("{token}", ...)</c> templating.
/// </summary>
public static class Prompts
{
    /// <summary>
    /// Blogger system prompt. The concrete state is supplied as the user message;
    /// the decision is returned via MAF structured output (typed
    /// <see cref="BloggerDecision"/>), so this prompt no longer needs to describe
    /// the exact JSON shape or beg the model for "no extra text" — the schema is
    /// enforced by the framework.
    /// </summary>
    public const string BloggerInstructions = """
You are a blogger managing a blog post creation workflow.

Your goal is to ensure a clear, engaging, and valuable blog post targeted at
software developers. Based on the current workflow state provided in the user
message, decide the next step.

Decision Rules:
- If no research exists, choose "researcher"
- If research exists but no draft, choose "author"
- If a draft exists and the reviewer said "APPROVED", choose "END"
- If the draft needs revision, choose "author"
- If revision_number >= 4, choose "END"

Return the next step and a brief task description.
""";

    /// <summary>
    /// Researcher system prompt. The topic to research is supplied as the user
    /// message. The Tavily web-search tool is attached to the agent, so the model
    /// itself decides when to call it and then summarises the results — there is
    /// no longer any hand-written search-call + JSON-parsing orchestration.
    /// </summary>
    public const string ResearcherInstructions = """
You are a researcher for a technical blog
focused on .NET and AI with examples in C# and Python.

You have access to a web-search tool. Use it to find relevant, up-to-date
insights for the topic given in the user message. Focus on:
- Key trends, challenges, or innovations
- Real-world use cases
- Supporting data or quotes from credible sources
- Simple explanations
- Short code examples in C# or Python

Call the search tool as needed, then summarize your findings concisely.
""";

    /// <summary>
    /// Author system prompt. The task, research findings, current draft and review
    /// notes are supplied as the user message each turn.
    /// </summary>
    public const string AuthorInstructions = """
You are a professional blogger.

The user message contains the main task, the research findings, the current
draft (if any) and any reviewer notes.

Instructions:
- If this is the first draft (no current draft), create a comprehensive post based on the findings
- If there is a current draft and review notes, revise the draft to address all feedback
- Use a professional tone
- Make the post concise (aim for 250-500 words)

Write the complete post.
""";

    /// <summary>
    /// Reviewer system prompt. The task and the draft to review are supplied as the
    /// user message.
    /// </summary>
    public const string ReviewerInstructions = """
You are a reviewer evaluating content for a blog post.

The user message contains the main task and the draft to review.

Evaluate the draft based on:
1. Hook Strength – Does the opening grab attention?
2. Clarity – Is the message easy to understand?
3. Value – Does the post offer real insights or lessons?
4. Structure – Are paragraphs short?
5. Tone – Is it authentic and professional?

Respond with one of:
- If the draft is satisfactory (minor issues are okay): "APPROVED - [brief positive comment]"
- If the draft needs improvement: provide specific, actionable feedback for revision
""";
}

With that in place, we can turn to Researcher. The most important change here is the conversion to a ChatClientAgent – the heart of MAF. Tavily is now attached as a tool. This allowed me to remove about 40 lines of tool invocation and JSON parsing. It also eliminated a second call as shown in the comments:

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

namespace BlogMigration;

/// <summary>
/// Researcher backed by a Microsoft Agent Framework <see cref="ChatClientAgent"/>.
///
/// MAF idiom change: previously this class manually invoked the Tavily tool,
/// hand-parsed the JSON response, then made a SECOND LLM call to summarise it.
/// Now the Tavily function is registered as a *tool on the agent*, so the model
/// itself decides when to search and produces the summary in a single agent run.
/// This requires the underlying <see cref="IChatClient"/> to have
/// function-invocation middleware enabled (wired in <c>Program.cs</c> via
/// <c>UseFunctionInvocation()</c>), which actually executes the tool calls the
/// model requests.
/// </summary>
public class ResearcherAgent : IResearcherAgent
{
    // The agent is built once and reused for every research turn. It is stateless
    // across turns (no AgentSession is retained), which matches the original
    // per-call behaviour while gaining tool-calling for free.
    private readonly ChatClientAgent _agent;

    public ResearcherAgent(IChatClient llm, ChatOptions chatOptions, AIFunction tavilyTool)
    {
        _agent = new ChatClientAgent(llm, new ChatClientAgentOptions
        {
            // Name surfaces in OpenTelemetry traces and agent logs.
            Name = "Researcher",
            ChatOptions = new ChatOptions
            {
                // Static role/system prompt lives here instead of being concatenated
                // into every request body.
                Instructions = Prompts.ResearcherInstructions,
                // Preserve the original sampling/cost settings.
                Temperature = chatOptions.Temperature,
                MaxOutputTokens = chatOptions.MaxOutputTokens,
                // Attaching the tool lets the model call it autonomously.
                Tools = [tavilyTool],
            },
        });
    }

    /// <summary>Execute research by letting the agent search and summarise.</summary>
    public async Task<string> InvokeAsync(string query)
    {
        try
        {
            // A single agent run: the model may call tavily_search one or more
            // times, read the results, and return a concise summary as its text.
            AgentResponse response = await _agent.RunAsync(query);
            string summary = response.Text;

            return !string.IsNullOrEmpty(summary)
                ? summary
                : $"Research completed on: {query}. Key information has been gathered from web sources.";
        }
        catch (Exception e)
        {
            Console.WriteLine($"Research error: {e.Message}");
            return $"Research completed on: {query}. Key information has been gathered from web sources.";
        }
    }

    /// <summary>Research node that gathers information.</summary>
    public async Task<ResearchState> ResearchNodeAsync(ResearchState state)
    {
        Console.WriteLine("\n>>>RESEARCHER");

        string subTask = !string.IsNullOrEmpty(state.CurrentSubTask) ? state.CurrentSubTask : state.MainTask;
        Console.WriteLine($"Researching: {subTask}");

        string findings;
        try
        {
            findings = await InvokeAsync(subTask);
            string preview = findings.Length > 100 ? findings[..100] : findings;
            Console.WriteLine($"Found: {preview}...");
        }
        catch (Exception e)
        {
            Console.WriteLine($"Research error: {e.Message}");
            findings = $"Research on {subTask} - information gathered";
        }

        state.ResearchFindings.Add(findings);
        return state;
    }
}

Let’s turn to the Author. Again, we convert to ChatClientAgent,

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

namespace BlogMigration;

/// <summary>
/// Author chain backed by a Microsoft Agent Framework <see cref="ChatClientAgent"/>.
///
/// MAF idiom change: the writing role now lives in the agent's Instructions
/// (set once), and only the volatile state (task, findings, draft, review notes)
/// is sent as the per-turn user message — replacing the previous
/// <c>string.Replace("{token}", ...)</c> templating against the raw IChatClient.
/// </summary>
public class AuthorChain : IAuthorChain
{
    private readonly ChatClientAgent _agent;

    public AuthorChain(IChatClient llm, ChatOptions chatOptions)
    {
        _agent = new ChatClientAgent(llm, new ChatClientAgentOptions
        {
            Name = "Author",
            ChatOptions = new ChatOptions
            {
                Instructions = Prompts.AuthorInstructions,
                Temperature = chatOptions.Temperature,
                MaxOutputTokens = chatOptions.MaxOutputTokens,
            },
        });
    }

    public async Task<string> InvokeAsync(ResearchState state)
    {
        List<string> research = state.ResearchFindings;
        string researchText = research.Count > 0 ? string.Join("\n\n", research) : "No research available.";

        // Per-turn input only — the role/instructions are already on the agent.
        string message = $"""
            Main Task: {state.MainTask}

            Research Findings:
            {researchText}

            Current Draft: {(string.IsNullOrEmpty(state.Draft) ? "(none — write the first draft)" : state.Draft)}

            Review Notes: {(string.IsNullOrEmpty(state.ReviewNotes) ? "(none)" : state.ReviewNotes)}
            """;

        try
        {
            AgentResponse response = await _agent.RunAsync(message);
            string content = response.Text;
            return !string.IsNullOrEmpty(content) ? content : "Draft in progress...";
        }
        catch (Exception e)
        {
            Console.WriteLine($"Author error: {e.Message}");
            return "Error generating draft. Please try again.";
        }
    }

    /// <summary>Author node that creates or revises draft.</summary>
    public async Task<ResearchState> AuthorNodeAsync(ResearchState state)
    {
        Console.WriteLine("\n>>>Author");

        string draft = await InvokeAsync(state);
        Console.WriteLine($"Draft created: {draft.Length} characters");

        state.Draft = draft;
        state.RevisionNumber += 1;
        return state;
    }
}

To close the circle, let’s look at the changes in Reviewer. In addition to changing to ChatClientAgent, we fix the code so that if a review fails it no longer approves, instead it requests revision (which was supposed to happen in the first place):

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

namespace BlogMigration;

/// <summary>
/// Reviewer chain backed by a Microsoft Agent Framework <see cref="ChatClientAgent"/>.
///
/// MAF idiom change: the evaluation role lives in the agent's Instructions; only
/// the task + draft are sent as the per-turn user message.
///
/// Correctness fix: the previous version's <c>catch</c> returned
/// "APPROVED - Error in review..." — meaning any transient LLM/transport failure
/// would silently approve an unreviewed draft. It now returns a revision request
/// instead, so a failed review re-loops to the author (bounded by
/// <see cref="ResearchState.MaxRevisions"/>) rather than shipping unchecked content.
/// </summary>
public class ReviewerChain : IReviewerChain
{
    private readonly ChatClientAgent _agent;

    public ReviewerChain(IChatClient llm, ChatOptions chatOptions)
    {
        _agent = new ChatClientAgent(llm, new ChatClientAgentOptions
        {
            Name = "Reviewer",
            ChatOptions = new ChatOptions
            {
                Instructions = Prompts.ReviewerInstructions,
                Temperature = chatOptions.Temperature,
                MaxOutputTokens = chatOptions.MaxOutputTokens,
            },
        });
    }

    public async Task<string> InvokeAsync(ResearchState state)
    {
        string draft = state.Draft;
        int revisionNum = state.RevisionNumber;

        if (draft.Trim().Length < 100)
        {
            return "APPROVED - Draft is minimal but acceptable.";
        }

        if (revisionNum >= ResearchState.MaxRevisions)
        {
            return "APPROVED - Maximum revisions reached. The report is satisfactory.";
        }

        // Per-turn input only — the evaluation criteria are on the agent.
        string message = $"""
            Main Task: {state.MainTask}

            Draft to Review:
            {draft}
            """;

        try
        {
            AgentResponse response = await _agent.RunAsync(message);
            string content = response.Text;
            return !string.IsNullOrEmpty(content) ? content : "APPROVED";
        }
        catch (Exception e)
        {
            // Do NOT approve on failure — that would ship an unreviewed draft.
            // Returning feedback (not "APPROVED") routes back to the author for
            // another attempt; the revision cap still guarantees termination.
            Console.WriteLine($"Review error: {e.Message}");
            return "Review could not be completed due to a transient error. Please revise and resubmit the draft.";
        }
    }

    /// <summary>Node that reviews the draft.</summary>
    public async Task<ResearchState> ReviewerNodeAsync(ResearchState state)
    {
        Console.WriteLine("\n>>REVIEWER");

        string review = await InvokeAsync(state);
        string preview = review.Length > 100 ? review[..100] : review;
        Console.WriteLine($"Review: {preview}...");

        bool isApproved = review.ToUpperInvariant().Contains("APPROVED");

        if (isApproved)
        {
            Console.WriteLine("\u2713 Draft APPROVED");
            state.ReviewNotes = "APPROVED";
            state.NextStep = "END";
        }
        else
        {
            Console.WriteLine("\u2717 Revisions needed");
            state.ReviewNotes = review;
            state.NextStep = "author";
        }

        return state;
    }
}

We’re ready to look at the changes to Blogger…

using System.Text.Json;
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

namespace BlogMigration;

/// <summary>
/// Blogger decision chain.
///
/// MAF idiom change: the LLM fallback used to ask the model for raw JSON, then
/// manually strip ```-fences and call <c>JsonSerializer.Deserialize</c>. That is
/// now replaced by MAF structured output — <c>RunAsync&lt;BloggerDecision&gt;</c>
/// returns a typed, schema-validated <see cref="BloggerDecision"/> directly.
///
/// Routing note: the actual control flow is owned by the workflow edges in
/// <see cref="BlogWorkflow"/> (Blogger → Researcher → Author → Reviewer with a
/// bounded revision loop). The <c>NextStep</c> this class computes is advisory;
/// its still-meaningful output is <c>CurrentSubTask</c>, which seeds the
/// researcher. The deterministic rules below are kept because they faithfully
/// preserve the original LangGraph decision logic and avoid an LLM call in the
/// common cases.
/// </summary>
public class BloggerChain : IBloggerChain
{
    // Built once and reused. Holds the static Blogger instructions; the volatile
    // state is passed per-turn as the user message.
    private readonly ChatClientAgent _agent;

    // Web-style options are sufficient: BloggerDecision carries explicit
    // [JsonPropertyName] attributes (next_step / task_description) that drive the
    // generated schema regardless of naming policy.
    private readonly JsonSerializerOptions _jsonOptions = new(JsonSerializerDefaults.Web);

    public BloggerChain(IChatClient llm, ChatOptions chatOptions)
    {
        _agent = new ChatClientAgent(llm, new ChatClientAgentOptions
        {
            Name = "Blogger",
            ChatOptions = new ChatOptions
            {
                Instructions = Prompts.BloggerInstructions,
                Temperature = chatOptions.Temperature,
                MaxOutputTokens = chatOptions.MaxOutputTokens,
            },
        });
    }

    public async Task<BloggerDecision> InvokeAsync(ResearchState state)
    {
        List<string> research = state.ResearchFindings;
        string researchText = research.Count > 0 ? string.Join("\n", research) : "No research yet.";
        int revision = state.RevisionNumber;
        bool hasResearch = research.Count > 0;
        bool hasDraft = !string.IsNullOrWhiteSpace(state.Draft);
        string review = state.ReviewNotes;

        if (review.ToUpperInvariant().Contains("APPROVED") && hasDraft)
        {
            Console.WriteLine("Blogger: Draft approved, ending workflow");
            return new BloggerDecision("END", "Report approved and complete");
        }

        if (!hasResearch)
        {
            Console.WriteLine("Blogger: No research yet, directing to researcher");
            return new BloggerDecision("researcher", $"Research the topic: {state.MainTask}");
        }

        if (hasResearch && !hasDraft)
        {
            Console.WriteLine("Blogger: Have research, creating first draft");
            return new BloggerDecision("author", "Write the first draft based on research findings");
        }

        if (hasDraft && string.IsNullOrEmpty(review))
        {
            Console.WriteLine("Blogger: Have draft, sending to reviewer");
            return new BloggerDecision("reviewer", "Prepare draft for review");
        }

        if (!string.IsNullOrEmpty(review) && !review.ToUpperInvariant().Contains("APPROVED") && revision < ResearchState.MaxRevisions)
        {
            Console.WriteLine($"Blogger: Revision {revision}, sending back to author");
            return new BloggerDecision("author", "Revise the draft based on review feedback");
        }

        // Max revisions reached
        if (revision >= ResearchState.MaxRevisions)
        {
            Console.WriteLine("Blogger: Max revisions reached! Ending");
            return new BloggerDecision("END", "Maximum revisions reached! Finalizing report");
        }

        // LLM decision as fallback. The dynamic state is the user message; the
        // static role lives in the agent's Instructions. MAF structured output
        // hands back a typed BloggerDecision — no fenced-block cleanup, no manual
        // JsonSerializer.Deserialize.
        string stateSummary = $"""
            Current Task: {state.MainTask}
            Research Findings: {researchText}
            Blog Draft: {(string.IsNullOrEmpty(state.Draft) ? "No draft yet." : state.Draft)}
            Reviewer Feedback: {(string.IsNullOrEmpty(review) ? "No review yet." : review)}
            Revision Number: {revision}
            """;

        try
        {
            AgentResponse<BloggerDecision> response =
                await _agent.RunAsync<BloggerDecision>(stateSummary, serializerOptions: _jsonOptions);

            BloggerDecision decision = response.Result;
            if (decision is not null && !string.IsNullOrEmpty(decision.NextStep))
            {
                return decision;
            }
        }
        catch (Exception e)
        {
            Console.WriteLine($"LLM decision error: {e.Message}");
        }

        // Final fallback - continue with author
        Console.WriteLine("Blogger: Using final fallback - continuing with author");
        return new BloggerDecision("author", "Continue with draft creation");
    }

    /// <summary>Blogger decides the next step.</summary>
    public async Task<ResearchState> BloggerNodeAsync(ResearchState state)
    {
        Console.WriteLine("\n>>>Blogger");

        BloggerDecision decision = await InvokeAsync(state);

        string nextStep = string.IsNullOrEmpty(decision.NextStep) ? "researcher" : decision.NextStep;
        string taskDesc = string.IsNullOrEmpty(decision.TaskDescription) ? "Continue work" : decision.TaskDescription;

        Console.WriteLine($"Decision: {nextStep}");
        Console.WriteLine($"Task: {taskDesc}");

        state.NextStep = nextStep;
        state.CurrentSubTask = taskDesc;
        return state;
    }
}

We’re down to the BlogWorkflow and Program.cs. Let’s start with the former. BlogWorkflow switches to RunStreamingAsync and WatchStreamAsync to stream the executor lifecycle events, while maintaining the topology:

using Microsoft.Agents.AI.Workflows;

namespace BlogMigration;

/// <summary>
/// Blog creation workflow built on the Microsoft Agent Framework workflow engine.
///
/// Topology (faithful to the original LangGraph StateGraph):
///   Blogger → Researcher → Author → Reviewer
///   Reviewer ⇄ Author  (bounded revision loop)
///   Reviewer → Output  (on approval or revision cap)
///
/// The revision loop is bounded by <see cref="ResearchState.MaxRevisions"/>: the
/// loop-back edge only fires while the draft is unapproved AND the revision count
/// is below the cap, so the workflow is guaranteed to terminate even if the
/// reviewer never returns "APPROVED".
/// </summary>
public class BlogWorkflow(
    IBloggerChain blogger,
    IResearcherAgent researcher,
    IAuthorChain author,
    IReviewerChain reviewer) : IBlogWorkflow
{
    public async Task<ResearchState> RunAsync(ResearchState state)
    {
        var bloggerExecutor = new BloggerExecutor(blogger);
        var researcherExecutor = new ResearcherExecutor(researcher);
        var authorExecutor = new AuthorExecutor(author);
        var reviewerExecutor = new ReviewerExecutor(reviewer);

        Workflow workflow = new WorkflowBuilder(bloggerExecutor)
            .AddEdge(bloggerExecutor, researcherExecutor)
            .AddEdge(researcherExecutor, authorExecutor)
            .AddEdge(authorExecutor, reviewerExecutor)
            // Bounded revision loop: route back to the author only while the draft
            // still needs work and the revision cap has not been reached. When the
            // condition is false the reviewer instead yields the final output.
            .AddEdge<ResearchState>(reviewerExecutor, authorExecutor, condition: s => s?.NeedsRevision == true)
            .WithOutputFrom(reviewerExecutor)
            .Build();

        // Stream execution instead of running to completion in one shot. The
        // topology is identical to before (proven terminating, MAF-Doctor grade A);
        // streaming simply surfaces each executor's lifecycle as it happens, giving
        // live progress and replacing the scattered Console.WriteLine tracing that
        // previously lived inside the node classes. The final ResearchState is
        // captured from the WorkflowOutputEvent emitted by the reviewer.
        StreamingRun run = await InProcessExecution.RunStreamingAsync(workflow, state);

        ResearchState? result = null;

        await foreach (WorkflowEvent evt in run.WatchStreamAsync())
        {
            switch (evt)
            {
                case ExecutorInvokedEvent invoked:
                    Console.WriteLine($"[workflow] → {invoked.ExecutorId} started");
                    break;

                case ExecutorCompletedEvent completed:
                    Console.WriteLine($"[workflow] ✓ {completed.ExecutorId} completed");
                    break;

                case ExecutorFailedEvent failed:
                    Console.WriteLine($"[workflow] ✗ {failed.ExecutorId} failed: {(failed.Data as Exception)?.Message}");
                    break;

                case WorkflowOutputEvent { Data: ResearchState finalState }:
                    // The reviewer yielded the final, approved (or revision-capped) state.
                    result = finalState;
                    break;
            }
        }

        // Fall back to the input state only if no output event was ever produced.
        return result ?? state;
    }
}

Finally, we’re ready to update Program.cs. Here we add UseFunctionInvocation to the IChatClient pipeline which is required for the researcher’s tool calls to execute:

using System.ClientModel;
using System.Net.Http.Headers;
using System.Net.Http.Json;
using System.Text.Json;
using BlogMigration;
using Microsoft.Extensions.AI;
using OpenAI;

const string fileName = "config.json";

using var stream = File.OpenRead(fileName);
using var document = JsonDocument.Parse(stream);
JsonElement config = document.RootElement;

string? GetValue(string key) =>
    config.TryGetProperty(key, out JsonElement value) ? value.GetString() : null;

Environment.SetEnvironmentVariable("OPENAI_API_KEY", GetValue("API_KEY"));
Environment.SetEnvironmentVariable("OPENAI_BASE_URL", GetValue("OPENAI_API_BASE"));
Environment.SetEnvironmentVariable("TAVILY_API_KEY", GetValue("TAVILY_API_KEY"));

string modelName = "gpt-4o-mini";

var openAIClient = new OpenAIClient(
    new ApiKeyCredential(Environment.GetEnvironmentVariable("OPENAI_API_KEY")!),
    new OpenAIClientOptions
    {
        Endpoint = new Uri(Environment.GetEnvironmentVariable("OPENAI_BASE_URL")!)
    });

// Build the IChatClient pipeline once and share it across all agents.
// UseFunctionInvocation() adds the middleware that actually *executes* the tool
// calls the model requests — without it, attaching the Tavily tool to the
// Researcher agent would let the model ask for a search but nothing would run it.
// Middleware is applied inner-to-outer, so function invocation wraps the raw
// OpenAI client. (To add distributed tracing later, chain .UseOpenTelemetry()
// here and register the source with a TracerProvider.)
IChatClient llm = openAIClient
    .GetChatClient(modelName)
    .AsIChatClient()
    .AsBuilder()
    .UseFunctionInvocation()
    .Build();

var chatOptions = new ChatOptions
{
    Temperature = 0,
    MaxOutputTokens = 4096
};

var tavilyHttpClient = new HttpClient { BaseAddress = new Uri("https://api.tavily.com/") };
tavilyHttpClient.DefaultRequestHeaders.Authorization =
    new AuthenticationHeaderValue("Bearer", Environment.GetEnvironmentVariable("TAVILY_API_KEY"));

AIFunction tavilyTool = AIFunctionFactory.Create(
    async (string query) =>
    {
        var request = new
        {
            query,
            max_results = 5,
            topic = "general",
            include_answer = false,
            include_raw_content = false,
            search_depth = "basic"
        };

        using HttpResponseMessage response = await tavilyHttpClient.PostAsJsonAsync("search", request);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    },
    name: "tavily_search",
    description: "A search engine optimized for comprehensive, accurate, and trusted results.");

// Creating a callable object
var bloggerChain = new BloggerChain(llm, chatOptions);
var researcherAgent = new ResearcherAgent(llm, chatOptions, tavilyTool);
var authorChain = new AuthorChain(llm, chatOptions);
var reviewerChain = new ReviewerChain(llm, chatOptions);
var app = new BlogWorkflow(bloggerChain, researcherAgent, authorChain, reviewerChain);

// Run the workflow for a sample topic
var initialState = new ResearchState
{
    MainTask = "use of multiagents in writing a C# application"
};

ResearchState result = await app.RunAsync(initialState);

Console.WriteLine("\n========== RESULTS ==========");
Console.WriteLine($"Task: {result.MainTask}");

Console.WriteLine($"\nResearch Findings ({result.ResearchFindings.Count}):");
foreach (string finding in result.ResearchFindings)
{
    Console.WriteLine($"- {finding}");
}

Console.WriteLine($"\nDraft:\n{result.Draft}");
Console.WriteLine($"\nReview Notes: {result.ReviewNotes}");
Console.WriteLine($"Revision Number: {result.RevisionNumber}");
Console.WriteLine("=============================");

I’ll have a lot more to say about the Microsoft Agent Framework in coming blog posts, often pointing back to this code.

Agents, tools, executors and workflows all depend on interfaces, and DI depends on registering the relationship between these interfaces and the concrete class that implements them.

For example, here is how you create a workflow

services.AddSingleton<Workflow>(sp =>
{
    var blogger = sp.GetRequiredService<BloggerExecutor>();
    var researcher = sp.GetRequiredService<ResearcherExecutor>();
    var author = sp.GetRequiredService<AuthorExecutor>();
    var reviewer = sp.GetRequiredService<ReviewerExecutor>();

    return new WorkflowBuilder(blogger)
        .AddEdge(blogger, researcher)
        .AddEdge(researcher, author)
        .AddEdge(author, reviewer)
        .AddEdge<ResearchState>(reviewer, author, s => s?.NeedsRevision == true)
        .WithOutputFrom(reviewer)
        .Build();
});

In our console application we would then register the interfaces, agents, executors, and workflows in .configureServices:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = Host.CreateDefaultBuilder(args)
    .ConfigureServices(services =>
    {
        // Register your interfaces here
        services.AddSingleton<IResearchService, ResearchService>();
        services.AddSingleton<IAuthorTools, AuthorTools>();
        services.AddSingleton<IReviewerLogic, ReviewerLogic>();

        // Register agents
        services.AddSingleton<ResearchAgent>();
        services.AddSingleton<AuthorAgent>();
        services.AddSingleton<BloggerAgent>();
        services.AddSingleton<ReviewerAgent>();

        // Register executors
        services.AddSingleton<ResearcherExecutor>();
        services.AddSingleton<AuthorExecutor>();
        services.AddSingleton<BloggerExecutor>();
        services.AddSingleton<ReviewerExecutor>();

        // Register workflow
        services.AddSingleton<Workflow>(sp =>
        {
            var blogger = sp.GetRequiredService<BloggerExecutor>();
            var researcher = sp.GetRequiredService<ResearcherExecutor>();
            var author = sp.GetRequiredService<AuthorExecutor>();
            var reviewer = sp.GetRequiredService<ReviewerExecutor>();

            return new WorkflowBuilder(blogger)
                .AddEdge(blogger, researcher)
                .AddEdge(researcher, author)
                .AddEdge(author, reviewer)
                .AddEdge<ResearchState>(reviewer, author, s => s?.NeedsRevision == true)
                .WithOutputFrom(reviewer)
                .Build();
        });
    })
    .Build();

// Resolve your entry point service
var workflow = host.Services.GetRequiredService<Workflow>();

This has all the advantages of DI as used anywhere, principally decoupling objects from their dependencies. This allows for greater flexibility (e.g., swapping out executors, etc.) and especially for testing (where moq objects can be used).

DI will inject all the following relationships:

• Agents depend on services
• Tools depend on services
• Executors depend on agents
• Workflows depend on executors

And your console app resolves the workflow.

In an ASP application you do the same, but in the usual place (startup.cs for ASP.NET Core and in program.cs for Minimal API)

Note, the complete source code for the .NET version of this demo application is now available at https://github.com/JesseLiberty/blogMigration—public

In the previous post we finished up creating our agents. You’ll remember that each of the agents declared nodes. We’re finally going to put them to use in a class BlogWorkflow. However, up to now we’ve not fully taken advantage of the Microsoft Agent Framework (MAF). Let’s fix that up first. To do so we’ll add a class BlogExecutors. We’ll create MAF workflow executors that will wrap existing “node” chains so that the business logic is reused unchanged.

Note: In this post we’re only going to move towards Microsoft Agent Framework from where things currently stand. To see this fully migrated to an application that truly utilizes MAF, navigate to here

Let’s start with the BloggerExecutor which will allow the blogger to plan the task and seed the sub-task:

using Microsoft.Agents.AI.Workflows;

namespace BlogMigration;

/// <summary>Entry executor: lets the blogger plan the task and seed the sub-task.</summary>
internal sealed partial class BloggerExecutor(IBloggerChain blogger) : Executor("Blogger")
{
    [MessageHandler]
    private async ValueTask<ResearchState> HandleAsync(ResearchState state, IWorkflowContext context)
        => await blogger.BloggerNodeAsync(state);
}

An executor is a node in Microsoft Agent Framework. Each executor can receive messages, process them and emit new messages. In this case, whenever the workflow engine routes a ResearchState message to the executor, this method is invoked. The method takes the current workflow state and the workflow context and returns the updated ResearchState.

The executor is just a thin wrapper around the Blogger agent. The handler calls the Blogger node and the node updates the state.

Let’s go ahead and create the other Executors

/// <summary>Gathers research findings.</summary>
internal sealed partial class ResearcherExecutor(IResearcherAgent researcher) : Executor("Researcher")
{
    [MessageHandler]
    private async ValueTask<ResearchState> HandleAsync(ResearchState state, IWorkflowContext context)
        => await researcher.ResearchNodeAsync(state);
}

/// <summary>Writes or revises the draft (increments the revision counter).</summary>
internal sealed partial class AuthorExecutor(IAuthorChain author) : Executor("Author")
{
    [MessageHandler]
    private async ValueTask<ResearchState> HandleAsync(ResearchState state, IWorkflowContext context)
        => await author.AuthorNodeAsync(state);
}

/// <summary>
/// Reviews the draft and records approval / revision notes. Acts as the terminal
/// output node: when no further revision is needed it yields the final state.
/// </summary>
internal sealed partial class ReviewerExecutor(IReviewerChain reviewer) : Executor("Reviewer")
{
    [MessageHandler]
    private async ValueTask<ResearchState> HandleAsync(ResearchState state, IWorkflowContext context)
    {
        state = await reviewer.ReviewerNodeAsync(state);

        if (!state.NeedsRevision)
        {
            // Approved, or the revision cap was hit — emit the final result.
            await context.YieldOutputAsync(state);
        }

        // Returned state is routed back to the author only when the loop edge
        // condition (NeedsRevision) is satisfied; otherwise it goes nowhere.
        return state;
    }

With that in place we can build the workflow. We begin by creating the executors as wrappers around our agents,

/// <summary>
///   Blogger → Researcher → Author → Reviewer
///   Reviewer ⇄ Author  (bounded revision loop)
///   Reviewer → Output  (on approval or revision cap)
///
/// The revision loop is bounded by <see cref="ResearchState.MaxRevisions"/>: the
/// loop-back edge only fires while the draft is unapproved AND the revision count
/// is below the cap, so the workflow is guaranteed to terminate even if the
/// reviewer never returns "APPROVED".
/// </summary>

public class BlogWorkflow(
    IBloggerChain blogger,
    IResearcherAgent researcher,
    IAuthorChain author,
    IReviewerChain reviewer) : IBlogWorkflow
{
    public async Task<ResearchState> RunAsync(ResearchState state)
    {
        var bloggerExecutor = new BloggerExecutor(blogger);
        var researcherExecutor = new ResearcherExecutor(researcher);
        var authorExecutor = new AuthorExecutor(author);
        var reviewerExecutor = new ReviewerExecutor(reviewer);

Now we create a Workflow object and add edges between our nodes

 Workflow workflow = new WorkflowBuilder(bloggerExecutor)
            .AddEdge(bloggerExecutor, researcherExecutor)
            .AddEdge(researcherExecutor, authorExecutor)
            .AddEdge(authorExecutor, reviewerExecutor)
            .AddEdge<ResearchState>(reviewerExecutor, authorExecutor, condition: s => s?.NeedsRevision == true)
            .WithOutputFrom(reviewerExecutor)
            .Build();

Notice the conditional edge. This final AddEdge says “if the condition is not null and the draft needs revision (remember, the Reviewer caps the number of revisions at 4) then follow this edge. If NeedsRevision equals false, this edge is ignored.

We’re ready to let ‘er rip

     Run run = await InProcessExecution.RunAsync(workflow, state);

        foreach (WorkflowEvent evt in run.NewEvents)
        {
            if (evt is WorkflowOutputEvent { Data: ResearchState result })
            {
                return result;
            }
        }

        return state;
    }

All that’s left is to create Program.cs. We’ll begin by initializing the environment we need

using System.ClientModel;
using System.Net.Http.Headers;
using System.Net.Http.Json;
using System.Text.Json;
using BlogMigration;
using Microsoft.Extensions.AI;
using OpenAI;

const string fileName = "config.json";

using var stream = File.OpenRead(fileName);
using var document = JsonDocument.Parse(stream);
JsonElement config = document.RootElement;

string? GetValue(string key) =>
    config.TryGetProperty(key, out JsonElement value) ? value.GetString() : null;

Environment.SetEnvironmentVariable("OPENAI_API_KEY", GetValue("API_KEY"));
Environment.SetEnvironmentVariable("OPENAI_BASE_URL", GetValue("OPENAI_API_BASE"));
Environment.SetEnvironmentVariable("TAVILY_API_KEY", GetValue("TAVILY_API_KEY"));

string modelName = "gpt-4o-mini";

var openAIClient = new OpenAIClient(
    new ApiKeyCredential(Environment.GetEnvironmentVariable("OPENAI_API_KEY")!),
    new OpenAIClientOptions
    {
        Endpoint = new Uri(Environment.GetEnvironmentVariable("OPENAI_BASE_URL")!)
    });

Now let’s instantiate our IChatClient (the LLM) and set the options. We’ll set temperature to 0 to have minimum variability and we’ll set the maximum output tokens.

IChatClient llm = openAIClient.GetChatClient(modelName).AsIChatClient();

var chatOptions = new ChatOptions
{
    Temperature = 0,
    MaxOutputTokens = 4096
};

Tavily is the library we’ll use for searching the web. You can learn more about it at https://tavily.com.

var tavilyHttpClient = new HttpClient { BaseAddress = new Uri("https://api.tavily.com/") };
tavilyHttpClient.DefaultRequestHeaders.Authorization =
    new AuthenticationHeaderValue("Bearer", Environment.GetEnvironmentVariable("TAVILY_API_KEY"));

AIFunction tavilyTool = AIFunctionFactory.Create(
    async (string query) =>
    {
        var request = new
        {
            query,
            max_results = 5,
            topic = "general",
            include_answer = false,
            include_raw_content = false,
            search_depth = "basic"
        };

        using HttpResponseMessage response = await tavilyHttpClient.PostAsJsonAsync("search", request);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    },
    name: "tavily_search",
    description: "A search engine optimized for comprehensive, accurate, and trusted results.");

Let’s set up all the agents and the BlogWorkflow

var bloggerChain = new BloggerChain(llm, chatOptions);
var researcherAgent = new ResearcherAgent(llm, chatOptions, tavilyTool);
var authorChain = new AuthorChain(llm, chatOptions);
var reviewerChain = new ReviewerChain(llm, chatOptions);

var app = new BlogWorkflow(bloggerChain, researcherAgent, authorChain, reviewerChain);

We’ll run the workflow for a sample topic

var initialState = new ResearchState
{
    MainTask = "use of multiagents in writing a C# application"
};

ResearchState result = await app.RunAsync(initialState);

Console.WriteLine("\n========== RESULTS ==========");
Console.WriteLine($"Task: {result.MainTask}");

Console.WriteLine($"\nResearch Findings ({result.ResearchFindings.Count}):");
foreach (string finding in result.ResearchFindings)
{
    Console.WriteLine($"- {finding}");
}

Console.WriteLine($"\nDraft:\n{result.Draft}");
Console.WriteLine($"\nReview Notes: {result.ReviewNotes}");
Console.WriteLine($"Revision Number: {result.RevisionNumber}");
Console.WriteLine("=============================");

Before we run this, here’s a look at the csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Agents.AI.Workflows" Version="1.10.0" />
    <PackageReference Include="Microsoft.Agents.AI.Workflows.Generators" Version="1.10.0">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Microsoft.Extensions.AI" Version="10.7.0" />
    <PackageReference Include="Microsoft.Extensions.AI.OpenAI" Version="10.7.0" />
    <PackageReference Include="OpenAI" Version="2.11.0" />
  </ItemGroup>

</Project>

That’s it. Easy Peasy.

Here is the output of running the above…

>>>Blogger
Blogger: No research yet, directing to researcher
Decision: researcher
Task: Research the topic: use of multiagents in writing a C# application

>>>RESEARCHER
Researching: Research the topic: use of multiagents in writing a C# application
Found: The search results highlight various resources and insights on developing multi-agent applications i...

>>>Author
Draft created: 3140 characters

>>REVIEWER
Review: APPROVED - The draft effectively introduces the concept of multi-agent systems in C# and provides va...
✓ Draft APPROVED

========== RESULTS ==========
Task: use of multiagents in writing a C# application

Research Findings (1):
- The search results highlight various resources and insights on developing multi-agent applications in C#.

1. **Creating a Multi-Agent Application**: Jesse Liberty's blog post introduces the concept of a multi-agent application, showcasing a test run of an application designed to generate blog posts. The post promises a detailed breakdown of the application in subsequent entries, indicating a focus on practical implementation.

2. **Semantic Kernel Framework**: A YouTube video discusses building a multi-agent application using the Semantic Kernel framework in C#. This resource likely provides a hands-on approach to leveraging this framework for multi-agent systems, emphasizing its capabilities and features.

3. **Microsoft Agent Framework**: Another YouTube tutorial presents the Microsoft Agent Framework as a robust alternative for creating multi-agent architectures in .NET. This resource suggests that the framework offers significant tools and functionalities for developers looking to implement multi-agent systems.

Overall, these findings suggest a growing interest in multi-agent systems within the C# ecosystem, with various frameworks and tutorials available to assist developers in creating sophisticated applications.

Draft:
# Harnessing Multi-Agent Systems in C#: A Comprehensive Guide

In the evolving landscape of software development, multi-agent systems (MAS) have emerged as a powerful paradigm, particularly in the realm of C#. These systems consist of multiple interacting agents, each capable of autonomous decision-making, which can lead to more efficient and scalable applications. This post explores the key resources and frameworks available for developing multi-agent applications in C#, providing a roadmap for developers interested in this innovative approach.

## Understanding Multi-Agent Applications

Multi-agent applications are designed to solve complex problems by distributing tasks among various agents. Each agent operates independently, yet they can collaborate to achieve common goals. Jesse Liberty's blog post serves as an excellent introduction to this concept, showcasing a practical example of a multi-agent application that generates blog posts. Liberty promises a detailed breakdown of the application in future entries, making it a valuable resource for developers looking to implement similar functionalities.

## Leveraging the Semantic Kernel Framework

For those seeking a hands-on approach, the Semantic Kernel framework offers a robust environment for building multi-agent applications in C#. A recent YouTube video delves into the capabilities of this framework, highlighting its features that facilitate the development of intelligent agents. The Semantic Kernel is particularly beneficial for developers aiming to integrate natural language processing and machine learning into their applications, allowing agents to understand and respond to user inputs more effectively.

## Exploring the Microsoft Agent Framework

Another noteworthy resource is the Microsoft Agent Framework, which provides a comprehensive set of tools for creating multi-agent architectures within the .NET ecosystem. A tutorial available on YouTube outlines the framework's functionalities, demonstrating how it can be utilized to develop sophisticated multi-agent systems. This framework is particularly advantageous for developers who are already familiar with the Microsoft stack, as it seamlessly integrates with existing .NET applications.

## Conclusion

The interest in multi-agent systems within the C# ecosystem is on the rise, driven by the need for more intelligent and responsive applications. With resources like Jesse Liberty's blog, the Semantic Kernel framework, and the Microsoft Agent Framework, developers have access to a wealth of knowledge and tools to create innovative multi-agent applications. As you embark on your journey into multi-agent development, these resources will serve as invaluable guides, helping you harness the full potential of this exciting technology.

By embracing multi-agent systems, you can elevate your applications, making them more dynamic and capable of handling complex tasks with ease. Whether you're generating content, automating processes, or enhancing user interactions, the possibilities are endless. Start exploring today and unlock the future of intelligent software development in C#.

Review Notes: APPROVED
Revision Number: 1

Note, I did not tell it to use my blog or what to say about it.

Find my YouTube channel here.