Building AI agents is getting easier. Deploying them as part of a real application, with multiple services, persistent state, and production infrastructure, is where things get complicated. Developers from the .NET community have requested whether a real-world example that shows running on local machine as well as on the cloud in a cloud-native way.

We’ve heard you! We built an open-source Interview Coach sample to show how Microsoft Agent Framework, Microsoft Foundry, Model Context Protocol (MCP), and Aspire fit together in a production-style application. It’s a working interview simulator where an AI coach walks you through behavioral and technical questions, then delivers a summary of your performance.

This post covers the patterns we used and the problems they solve.

Here’s the link to visit the Interview Coach demo app.

If you’ve been building AI agents with .NET, you’ve probably used Semantic Kernel, AutoGen, or both. Microsoft Agent Framework is the next step. It’s built by the same teams and combines what worked from both projects into a single framework.

It takes AutoGen’s agent abstractions and Semantic Kernel’s enterprise features (state management, type safety, middleware, telemetry) and puts them under one roof. It also adds graph-based workflows for multi-agent orchestration.

For .NET developers, this means:

• One framework instead of two. No more choosing between Semantic Kernel and AutoGen.
• Familiar patterns. Agents use dependency injection, IChatClient, and the same hosting model as ASP.NET apps.
• Built for production. OpenTelemetry, middleware pipelines, and Aspire integration are included.
• Multi-agent orchestration. Sequential workflows, concurrent execution, handoff patterns, and group chat are all supported.

The Interview Coach puts all of this into a real application, not just a Hello World.

AI agents need more than a model. They need infrastructure. Microsoft Foundry is Azure’s platform for building and managing AI applications, and it’s the recommended backend for Microsoft Agent Framework.

Foundry gives you a single portal for:

• Model access. A catalog of models from OpenAI, Meta, Mistral, and others, all through one endpoint.
• Content safety. Built-in moderation and PII detection so your agents don’t go off the rails.
• Cost-optimized routing. Requests get routed to the best model for the job automatically.
• Evaluation and fine-tuning. Measure agent quality and improve it over time.
• Enterprise governance. Identity, access control, and compliance through Entra ID and Microsoft Defender.

For the Interview Coach, Foundry provides the model endpoint that powers the agents. Because the agent code uses the IChatClient interface, Foundry is just a configuration choice, but it’s the one that gives you the most tooling out of the box.

The Interview Coach is a conversational AI that runs a mock job interview. You provide a resume and a job description, and the agent takes it from there:

1. Intake. Collects your resume and the target job description.
2. Behavioral interview. Asks STAR-method questions tailored to your experience.
3. Technical interview. Asks role-specific technical questions.
4. Summary. Generates a performance review with specific feedback.

You interact with it through a Blazor web UI that streams responses in real time.

The application is split into several services, all orchestrated by Aspire:

• • LLM Provider. Microsoft Foundry (recommended) for different model access.
  • WebUI. Blazor chat interface for the interview conversation.
  • Agent. The interview logic, built on Microsoft Agent Framework.
  • MarkItDown MCP Server. Parses resumes (PDF, DOCX) into markdown via Microsoft’s MarkItDown.

• InterviewData MCP Server. A .NET MCP server that stores sessions in SQLite.

Aspire handles service discovery, health checks, and telemetry. Each component runs as a separate process, and you start the whole thing with a single command.

The handoff pattern is where this sample gets interesting. Instead of one agent doing everything, the interview is split across five specialized agents:

In the handoff pattern, one agent transfers full control of the conversation to the next. The receiving agent takes over entirely. This is different from “agent-as-tools,” where a primary agent calls others as helpers but retains control.

Here’s how the handoff workflow is wired up:

var workflow = AgentWorkflowBuilder
 .CreateHandoffBuilderWith(triageAgent)
 .WithHandoffs(triageAgent, [receptionistAgent, behaviouralAgent, technicalAgent, summariserAgent])
 .WithHandoffs(receptionistAgent, [behaviouralAgent, triageAgent])
 .WithHandoffs(behaviouralAgent, [technicalAgent, triageAgent])
 .WithHandoffs(technicalAgent, [summariserAgent, triageAgent])
 .WithHandoff(summariserAgent, triageAgent)
 .Build();

The happy path is sequential: Receptionist → Behavioral → Technical → Summarizer. Each specialist hands off directly to the next. If something goes off-script, agents fall back to Triage for re-routing.

The sample also includes a single-agent mode for simpler deployments, so you can compare the two approaches side by side.

Pattern 2: MCP for tool integration

Tools in this project don’t live inside the agent. They live in their own MCP (Model Context Protocol) servers. The same MarkItDown server could power a completely different agent project, and tool teams can ship independently of agent teams. MCP is also language-agnostic, which is how MarkItDown runs as a Python server while the agent is .NET.

The agent discovers tools at startup through MCP clients and passes them to the appropriate agents:

var receptionistAgent = new ChatClientAgent(
 chatClient: chatClient,
 name: "receptionist",
 instructions: "You are the Receptionist. Set up sessions and collect documents...",
 tools: [.. markitdownTools, .. interviewDataTools]);

Each agent only gets the tools it needs. Triage gets none (it just routes), interviewers get session access, and the Receptionist gets document parsing plus session access. This follows the principle of least privilege.

Aspire ties everything together. The app host defines the service topology: which services exist, how they depend on each other, and what configuration they receive. You get:

• Service discovery. Services find each other by name, not hardcoded URLs.
• Health checks. The Aspire dashboard shows the status of every component.
• Distributed tracing. OpenTelemetry wired up through shared service defaults.
• One-command startup. aspire run --file ./apphost.cs launches everything.

For deployment, azd up pushes the entire application to Azure Container Apps.

• .NET 10 SDK or later
• Azure Subscription
• Microsoft Foundry project
• Docker Desktop or other container runtime

git clone https://github.com/Azure-Samples/interview-coach-agent-framework.git
cd interview-coach-agent-framework

# Configure credentials
dotnet user-secrets --file ./apphost.cs set MicrosoftFoundry:Project:Endpoint "<your-endpoint>"
dotnet user-secrets --file ./apphost.cs set MicrosoftFoundry:Project:ApiKey "<your-key>"

# Start all services
aspire run --file ./apphost.cs

azd auth login
azd up

azd down --force --purge