Build multi-agent applications with Agent Framework and Foundry

Let’s build an interview coach that can read a resume, ask useful questions, and save feedback.

We’ll start with one agent and give it tools. Once it can run an interview, we’ll divide the work among five specialist roles.

Microsoft Agent Framework runs those agents in our local .NET application. Microsoft Foundry hosts the model they call. You’ll learn which decisions belong in instructions, which belong in code, and how to check the result.

The starter supplies a Blazor chat page and supporting services. That leaves us free to concentrate on agent behavior rather than building another chat interface.

Start the workshop

Follow an interview through the agents

Triage selects a role. The receptionist collects documents, the interviewers conduct practice, and the summariser saves the final feedback. This diagram shows the usual path. Later, we’ll add routes for changed requests and early finishes.

A usual interview

We will build these five roles a few chapters at a time. Here is the usual path through a short practice interview.

1. Triage. Starts the conversation and hands intake to the receptionist.
2. Receptionist. Collects a resume and job description, then hands over to the behavioural interviewer.
3. Behavioural interviewer. Asks about past experience and saves feedback before handing over to the technical interviewer.
4. Technical interviewer. Uses the job context to ask technical questions, then hands over to the summariser.
5. Summariser. Writes a summary and marks the interview record complete.

Later chapters add the return routes and early-finish choices.

Fictional resumes, a job description, and sample answers are supplied. Use those while learning where document text and conversation data travel.

Why use more than one agent?

Document intake needs a parser and instructions about collecting information. A technical interviewer needs the saved context and instructions about asking useful questions. Giving those jobs separate agents lets us adjust one role’s prompt and tools without rewriting the others.

However, that separation adds work: we have to decide who takes the next turn and carry the interview context between roles. We’ll first build a single coach that handles the whole interview, then split the responsibilities.

Build, explain, then try a change

Each chapter introduces a decision before showing the edits. We’ll create a ChatClientAgent, connect the chat page, then add a C# tool. Model Context Protocol (MCP) will connect the coach to record storage and document extraction.

Along the way, you’ll write an instruction, predict a tool result, and compare repeated runs. The goal is to explain why the code works and make a small change without following another complete listing.

Keep editing the same project throughout the course. Each build chapter names the files and gives you a result to check. Checkpoint downloads provide comparison and recovery copies.

How the application runs

The diagram below shows the services behind the job candidate’s conversation. The agents run in our .NET application and share a configured Foundry model deployment. The local InterviewData service stores records through a Cosmos emulator, and a MarkItDown container extracts document text.

Application architecture

The UI talks to your .NET service. That service calls the Foundry model and executes tools through local MCP servers.

1. Blazor chat UI. The browser displays the UI. The local Blazor server holds the component state and sends AG-UI requests to the agent service.
2. .NET agent service. Runs Agent Framework, supplies instructions, and executes the tools the model requests.
3. Foundry model. Produces replies and tool-call requests. The agent workflow stays in your application.
4. InterviewData MCP. Exposes the functions that create, fetch, update, and complete interview records.
5. Cosmos DB emulator. Stores interview records during local development.
6. MarkItDown MCP. Fetches a document URL and converts the document to text for the agent.

Arrows show requests; replies travel back along the same connections. Only the model runs in Azure during this local walkthrough.

Before you begin

You should be comfortable reading and editing C# and running a .NET application. Some familiarity with Aspire helps. No previous agent or MCP experience is required.

Your workshop path starts with tools, Azure permissions, and a short example run. Model-backed runs can create billable resources. Chapter 0 covers approval and cleanup before we start them.