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 and .NET.

MAF consolidates various tools and frameworks, including AutoGen and Semantic Kernel, into a single, cohesive development environment.

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

One of the standout features of MAF is its support for 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.

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: We’re only going to move towards Microsoft Agent Framework from where things 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.

The Author is handed two objects when instantiated: the llm (an IChatClient object) and the chatOptions. Its primary method is InvokeAsync, which is passed the current ResearchState.

public class AuthorChain(IChatClient llm, ChatOptions chatOptions) : IAuthorChain
{
    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.";

Its expectation is that the state object will have research information from the Researcher. It creates its prompt based on the state and then sends that prompt, along with its options, to the llm. What it gets back is its first draft which it will pass to the Reviewer

       string prompt = Prompts.AuthorPromptTemplate
            .Replace("{main_task}", state.MainTask)
            .Replace("{research_findings}", researchText)
            .Replace("{draft}", state.Draft)
            .Replace("{review_notes}", state.ReviewNotes);

        try
        {
            ChatResponse response = await llm.GetResponseAsync(prompt, chatOptions);
            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.";
        }
    }

All that’s left for the Author is to create its node

    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;
    }

That was short enough that we should look at the Reviewer while we’re here.

Like the Author, the Reviewer is passed the llm and the chatOptions. InvokeAsync gets the ResearchState and from the state it can get the current draft that the author created.

   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 >= 4)
        {
            return "APPROVED - Maximum revisions reached. The report is satisfactory.";
        }

        string prompt = Prompts.ReviewerPromptTemplate
            .Replace("{main_task}", state.MainTask)
            .Replace("{draft}", draft);

        try
        {
            ChatResponse response = await llm.GetResponseAsync(prompt, chatOptions);
            string content = response.Text;
            return !string.IsNullOrEmpty(content) ? content : "APPROVED";
        }
        catch (Exception e)
        {
            Console.WriteLine($"Review error: {e.Message}");
            return "APPROVED - Error in review, proceeding with current draft.";
        }
    }

Notice that the Reviewer is quite generous in marking drafts as APPROVED. You may want to handle some conditions differently.

Let’s create the Reviewer’s node and in the next post we can finally see how these nodes are used.

   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;
    }

The Blogger invokes the Researcher, so let’s go there next.

The Researcher class is created with an IChatClient (the principal object for llms), a set of options and the search tool (Tavily)

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

namespace BlogMigration;

/// <summary>Creates a researcher agent that uses Tavily search.</summary>
public class ResearcherAgent(IChatClient llm, ChatOptions chatOptions, AIFunction tavilyTool) : IResearcherAgent
{

The main method is InvokeAsync which gets a copy of the query and uses Tavily to search the web using that query. The results are JSON, and the next step is to extract a JsonDocument object by parsing these results.

try
        {
            object? searchResult = await tavilyTool.InvokeAsync(
                new AIFunctionArguments { ["query"] = query });

            string searchJson = searchResult switch
            {
                JsonElement je => je.ValueKind == JsonValueKind.String ? je.GetString() ?? "{}" : je.GetRawText(),
                string s => s,
                _ => searchResult?.ToString() ?? "{}"
            };

            var formattedResults = new List<string>();

            using (JsonDocument document = JsonDocument.Parse(searchJson))
            {
                if (document.RootElement.TryGetProperty("results", out JsonElement results)
                    && results.ValueKind == JsonValueKind.Array)
                {
                    foreach (JsonElement result in results.EnumerateArray().Take(3))
                    {
                        string title = result.TryGetProperty("title", out JsonElement t) ? t.GetString() ?? "Untitled" : "Untitled";
                        string url = result.TryGetProperty("url", out JsonElement u) ? u.GetString() ?? "N/A" : "N/A";
                        string content = result.TryGetProperty("content", out JsonElement c) ? c.GetString() ?? "" : "";
                        string snippet = content.Length > 250 ? content[..250] : content;
                        formattedResults.Add($">>{title}\nSource: {url}\n{snippet}...\n");
                    }
                }
            }

            string rawOutput = formattedResults.Count > 0
                ? string.Join("\n", formattedResults)
                : "No results found";

We next instruct the llm using a system prompt, passing in the raw output we just created. We get back the summary of the findings and if that is not empty we return it.

           string summaryPrompt = $"""
                Based on these search results about '{query}',
                provide a concise summary of key findings:
                {rawOutput}
                """;

            ChatResponse summaryResponse = await llm.GetResponseAsync(summaryPrompt, chatOptions);
            string summary = summaryResponse.Text;

            return !string.IsNullOrEmpty(summary) ? summary : rawOutput;

Finally, we handle any exceptions raised

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

As we did with Blogger, we also create a Node, passing in the state and getting back the updated state.

   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;
    }

In the next blog post we’ll look at the Author

In the python version of our program the blogger_prompt_template is in its own cell and fairly short. In the C# version we create a file Prompts.cs. The class is static and has a const string for each prompt. Let’s start with the Blogger prompt:

namespace BlogMigration;

public static class Prompts
{
    public const string BloggerPromptTemplate = """
You are a blogger managing a blog post creation workflow.

Current Task: {main_task}

Current State:
- Research Findings: {research_findings}
- Blog Draft: {draft}
- Reviewer Feedback: {review_notes}
- Revision Number: {revision_number}

Your goal is to ensure a clear, engaging, and valuable blog post targeted at software developers.

Decide the next step and respond only with a JSON object (no extra text):
{
    "next_step": "researcher" or "author" or "END",
  "task_description": "Brief description of what needs to be done next"
}

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

The triple quotes in a C# string create a raw string literal, introduced in C# 11. With this no escaping is needed and the string can be multi-line. There’s more to it, and I’ll refer you to the C# documentation.

With that, we’re ready to create the BloggerChain. The structure matches the Python code closely, of course using C# syntax.

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

namespace BlogMigration;

/// <summary>Creates the blogger decision chain.</summary>
public class BloggerChain(IChatClient llm, ChatOptions chatOptions) : IBloggerChain
{
    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 <= 4)
        {
            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 >= 4)
        {
            Console.WriteLine("Blogger: Max revisions reached! Ending");
            return new BloggerDecision("END", "Maximum revisions reached! Finalizing report");
        }

        // LLM decision as fallback
        string prompt = Prompts.BloggerPromptTemplate
            .Replace("{main_task}", state.MainTask)
            .Replace("{research_findings}", researchText)
            .Replace("{draft}", string.IsNullOrEmpty(state.Draft) ? "No draft yet." : state.Draft)
            .Replace("{review_notes}", string.IsNullOrEmpty(review) ? "No review yet." : review)
            .Replace("{revision_number}", revision.ToString());

        try
        {
            ChatResponse response = await llm.GetResponseAsync(prompt, chatOptions);
            string content = response.Text;

            // Try to parse JSON
            string text = content.Trim();
            if (text.StartsWith("```"))
            {
                IEnumerable<string> lines = text.Split('\n').Where(l => !l.TrimStart().StartsWith("```"));
                text = string.Join("\n", lines);
            }
            text = text.Trim();

            BloggerDecision? decision = JsonSerializer.Deserialize<BloggerDecision>(text);

            if (decision is not null && !string.IsNullOrEmpty(decision.NextStep))
            {
                return decision;
            }
        }
        catch (Exception e)
        {
            Console.WriteLine($"LLM parsing 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");
    }

It is in this class that we can create the BloggerNode, which will be used in the same way as it is in the Python example:

    /// <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;
    }
}

Notice the use of a BloggerDecision object. Let’s create that in a file BloggerDecision.cs

using System.Text.Json.Serialization;

namespace BlogMigration;

public record BloggerDecision(
    [property: JsonPropertyName("next_step")] string NextStep,
    [property: JsonPropertyName("task_description")] string TaskDescription);

Program.cs has more to do than we’ve seen so far. Among other things, it will instantiate a BloggerChain object, which we’ll see after we create the Author, Researcher, and Reviewer related classes.

We’ll tackle the Author files in the next installment.

Note: to make sense of this code, you’ll want to start with the Python example. The code for that begins here.

We begin with bringing in the config.json file. We’ll use the identical file, and bring it into Program.cs

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")!)
    });

Next, we set up the Tavily search tool:

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.");

A little more verbose, but we’re doing a bit of extra work along the way. Let’s go down to where we create the ResearchState. To do that, we’ll create ResearchState.cs:

namespace BlogMigration;

/// <summary>State for the research workflow.</summary>
public class ResearchState
{
    public string MainTask { get; set; } = "";
    public List<string> ResearchFindings { get; set; } = [];
    public string Draft { get; set; } = "";
    public string ReviewNotes { get; set; } = "";
    public int RevisionNumber { get; set; }
    public string NextStep { get; set; } = "";
    public string CurrentSubTask { get; set; } = "";
}

In the next blog post we’ll create the first of our agents: Blogger. We’ll mimic BloggerChain, passing in the llm (IChatClient) and the chat options.

Here’s the set of files we’ll create:

And here is the output after running it as a test using the prompt Use of multi-agents in writing a C# application:

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 several key findings regarding the use of multi-agent systems in C# app…

Author Draft created: 3066 characters

REVIEWER Review: APPROVED – The draft effectively introduces the concept of multi-agent systems in C# applications an… ✓ Draft APPROVED

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

Research Findings (1):

• The search results highlight several key findings regarding the use of multi-agent systems in C# applications:

1. Creating Multi-Agent Applications: Jesse Liberty discusses the development of a multi-agent application designed to generate blog posts. The article suggests a step-by-step approach to understanding the application, indicating that the process involves both design and implementation phases.
2. Creative Writing Assistant: A sample application showcased by Microsoft demonstrates the use of multi-agent systems in a creative writing context. This application utilizes the Semantic Kernel and .NET Aspire, illustrating practical applications of multi-agent frameworks in enhancing creative tasks.
3. Challenges in Multi-Agent Systems: Elliot One emphasizes a critical perspective on multi-agent systems, warning that simply adding more agents does not necessarily improve the quality of outputs. Instead, it can complicate the identification of errors, suggesting that careful design and management of agents are crucial for effective outcomes.

Overall, these findings suggest that while multi-agent systems can enhance functionality in applications like creative writing, they also present challenges that require careful consideration in their design and implementation.

Draft:

Harnessing Multi-Agent Systems in C# Applications: A Guide to Creative Writing

In the evolving landscape of software development, multi-agent systems (MAS) have emerged as a powerful paradigm, particularly in applications that require creativity and collaboration. This post explores the implementation of multi-agent systems in C# applications, focusing on their role in enhancing creative writing tasks.

Understanding Multi-Agent Systems

Multi-agent systems consist of multiple interacting agents, each capable of autonomous decision-making. These agents can collaborate, negotiate, and share information, making them ideal for complex tasks that benefit from diverse perspectives. In the context of writing applications, MAS can facilitate the generation of content, brainstorming ideas, and even editing drafts.

Creating a Multi-Agent Application

Jesse Liberty outlines a structured approach to developing a multi-agent application aimed at generating blog posts. The process involves two key phases: design and implementation. During the design phase, developers must define the roles and responsibilities of each agent, ensuring that they complement one another. The implementation phase focuses on coding the agents, integrating them into a cohesive system, and testing their interactions.

Example Application: Creative Writing Assistant

A practical example of multi-agent systems in action is a creative writing assistant developed using Microsoft’s Semantic Kernel and .NET Aspire. This application showcases how agents can work together to enhance the writing process. For instance, one agent might focus on generating ideas, while another refines the language and style. By leveraging the strengths of each agent, the application can produce high-quality content that resonates with readers.

Challenges in Multi-Agent Systems

While the potential of multi-agent systems is significant, it is essential to approach their implementation with caution. Elliot One highlights a critical challenge: simply adding more agents does not guarantee improved outcomes. In fact, an increase in agents can complicate error identification and management. Therefore, careful design and oversight are crucial to ensure that the agents work harmoniously and effectively.

Conclusion

The integration of multi-agent systems in C# applications, particularly for creative writing, offers exciting possibilities for enhancing productivity and creativity. By understanding the design and implementation processes, as well as the potential challenges, developers can create robust applications that leverage the strengths of multiple agents. As the field continues to evolve, the thoughtful application of these systems will undoubtedly lead to innovative solutions in various domains.

In summary, multi-agent systems represent a promising frontier in software development, particularly for applications that thrive on collaboration and creativity. Embracing this technology can empower developers to create more dynamic and engaging user experiences.

Review Notes: APPROVED Revision Number: 1

In the next post we’ll begin looking at each file and how it relates to what we had in Python.

In the following code we pass the ResearchState object to StateGraph and create a node for each agent and edges that represent transitions between the nodes. There is one conditional edge: if the reviewer rejects the draft, it goes back to the author

from langgraph.graph import StateGraph, END
workflow = StateGraph(ResearchState)

workflow.add_node("blogger", blogger_node)
workflow.add_node("researcher", research_node)
workflow.add_node("author", author_node)
workflow.add_node("reviewer", reviewer_node)

workflow.set_entry_point("blogger")

workflow.add_edge("blogger", "researcher")
workflow.add_edge("researcher", "author")
workflow.add_edge("author", "reviewer")

workflow.add_conditional_edges(
    "reviewer",
    lambda state: "author" if state.get("review_result") == "rejected" else "END",
    {
        "author": "author",
        "END": END
    }
)

# Compile the graph
app = workflow.compile()

The conditional edge says, “Start with reviewer. Now examine the state. If the review_result is rejected, go to the author; otherwise, go to END. Finally, the dictionary identifies what each node is.

That’s it. All that’s left is to take it out for a spin.