Microsoft Agent Framework in Practice: What the Interview Coach Sample Actually Teaches You
The Challenge
If you've been building AI agents on the Microsoft stack, the last 18 months have felt like choosing between two good but incompatible paths. Semantic Kernel gave you enterprise-grade state management, middleware pipelines, and production telemetry. AutoGen gave you flexible multi-agent patterns and research-grade orchestration. Picking one meant giving up the strengths of the other.
That changed when Microsoft merged both into the Microsoft Agent Framework — now in public preview. But a framework announcement only gets you so far. Developers want to see how the pieces fit in something more complex than a Hello World.
Microsoft just published an answer: the Interview Coach, an open-source sample that wires together Agent Framework, Microsoft Foundry, Model Context Protocol (MCP), and.NET Aspire into a production-style application. It's a working interview simulator — five specialised agents, two MCP tool servers, a Blazor web UI, and a deployment path that goes from aspire run on your laptop to azd up on Azure Container Apps.
It's also a pattern library disguised as a demo. Here's what matters.
What's Changed
One Framework, Five Agents
The Interview Coach splits a mock job interview across five agents, each with a distinct role: Triage (routing), Receptionist (session setup and document ingestion), Behavioural Interviewer (STAR-method questions), Technical Interviewer (role-specific questions), and Summariser (performance review).
This uses the handoff orchestration pattern — the most interesting of Agent Framework's orchestration models. When the Receptionist finishes collecting your CV and job description, it transfers full control to the Behavioural Interviewer. Not "calls it as a tool" — hands off entirely. The receiving agent owns the conversation until it passes forward again.
var workflow = AgentWorkflowBuilder
.CreateHandoffBuilderWith(triageAgent)
.WithHandoffs(triageAgent, [receptionistAgent, behaviouralAgent,
technicalAgent, summariserAgent])
.WithHandoffs(receptionistAgent, [behaviouralAgent, triageAgent])
.Build();
The happy path is sequential: Receptionist → Behavioural → Technical → Summariser. If something goes off-script, agents fall back to Triage for re-routing. It's a pattern that maps cleanly to any multi-step business process — customer onboarding, incident triage, procurement workflows.
MCP as the Tool Boundary
Tools don't live inside agents. They live in their own MCP servers. The MarkItDown server (Python) parses CVs from PDF and DOCX into markdown. The InterviewData server (.NET) handles session persistence in SQLite. Each agent only receives the tools it needs — Triage gets none, interviewers get session access, the Receptionist gets both document parsing and sessions.
This is the principle of least privilege applied to agent tooling. And because MCP is language-agnostic, your Python tool server and your.NET agent code don't need to share a runtime. Different teams can ship tool servers independently. That's the real operational benefit.
Aspire Ties It Together
.NET Aspire handles the multi-service orchestration: service discovery by name (not hardcoded URLs), health checks on every component, OpenTelemetry distributed tracing across all five agents and both MCP servers, and single-command startup. For production, azd up deploys everything to Azure Container Apps.
For anyone who's wired up service mesh configurations manually, Aspire's approach is refreshingly opinionated. Define the topology in code, and the infrastructure follows.
Why Foundry Matters Here
Microsoft Foundry provides the model endpoint — access to OpenAI, Meta, Mistral, and other models through a single catalogue, plus content safety, cost-optimised routing, and enterprise governance through Entra ID. Because Agent Framework uses the IChatClient abstraction, swapping Foundry for another provider is a configuration change. But Foundry gives you the most complete operational tooling out of the box: evaluation, fine-tuning, PII detection, and the new task adherence features coming in public preview.
Getting Started
The prerequisites are.NET 10 SDK, Docker Desktop, an Azure subscription, and a Foundry project. Clone the repo, set your Foundry endpoint and API key via dotnet user-secrets, and run aspire run. The Aspire Dashboard shows the status of every service. Click the WebUI endpoint and you're doing a mock interview.
git clone https://github.com/Azure-Samples/interview-coach-agent-framework.git
cd interview-coach-agent-framework
aspire run --file./apphost.cs
The sample includes both multi-agent and single-agent modes, so you can compare the two side by side and understand when the orchestration overhead is worth it (spoiler: it is when you have distinct phases with different tool requirements).
For deployment: azd auth login && azd up. That's it. Clean up with azd down --force --purge.
What This Means
Microsoft Agent Framework resolves the Semantic Kernel vs. AutoGen dilemma. The Interview Coach proves it's not just theoretical — these patterns work in a real application with real services. The combination of handoff orchestration, MCP tool servers, and Aspire deployment gives.NET teams a credible path from local prototype to cloud-native production agent.
The framework is also explicitly designed as a bridge. It connects Azure AI Foundry, Microsoft 365 Copilot, and third-party agent platforms. With A2A (Agent-to-Agent) protocol support and the new multi-agent workflow capabilities coming to Foundry Agent Service, the pieces are converging around a single orchestration layer.
If you're a.NET developer building agents, this is where to start. Not with the docs — with the Interview Coach repo. Clone it, run it, then swap the interview agents for your own domain. The patterns transfer directly.
Leon Godwin, Principal Cloud Evangelist at Cloud Direct