Build a Multi-Agent Career Copilot: Resume-to-Job Fit Analysis

Date: September 3, 2026 · 2:00 PM to 3:00 PM UTC | Platform: Microsoft Reactor (Livestream)

Series: Build AI agents with Microsoft Foundry Toolkit for VS Code

The Short Version

I stood up in front of a global developer audience and, live, with no safety net beyond a pre-deployed backup, built a system where four AI agents hand work to each other like a small assembly line. One reads a resume, one reads a job description, one scores how well they match, and one turns the gaps into a real learning plan with working Microsoft Learn links instead of made-up ones.

This was the third and final talk in a three-part Microsoft Reactor series alongside Junjie Li (Senior PM, Microsoft) and Bethany Jepchumba (Cloud Advocate, Microsoft). They opened the series, Junjie on what the Foundry Toolkit actually is, Bethany on shipping your first single agent, and I closed it out by taking that foundation and pushing it into multi-agent territory: four agents, wired together, debugged live, and deployed to production in front of everyone watching.

If you want the honest pitch for why this talk matters beyond “I did a demo”: the interesting part isn’t that four agents can talk to each other. It’s what breaks when they do, and how you actually find out which one broke. That’s the part of the talk people remember.

Watch the Recording

Watch on YouTube or open the official Microsoft Reactor event page.

Presentation Slides

Open the presentation PDF in a new tab.

Event Overview

Series Context

Three sessions, each of us taking one leg of the journey from “what is this toolkit” to “here’s a production system running live”:

Event Details

• Platform: Microsoft Reactor Livestream
• Date and Time: September 3, 2026 · 2:00 PM to 3:00 PM (UTC)
• Duration: 60 minutes, live build plus Q&A
• Format: Live coding, not slides with a demo bolted on. The code was written and run in real time.
• Topic: Agentic AI, multi-agent orchestration, Microsoft Foundry
• Audience: Developers already comfortable with single-agent concepts, ready for the next layer
• Reach: Global livestream audience, plus an on-demand recording that keeps earning views

My Role

I was the sole presenter and builder for this session, the capstone of a series the three of us built together. What that actually involved:

What the System Actually Does

The Resume-to-Job Fit Evaluator takes a resume and a job description, and hands back a fit score, a gap list, and a learning roadmap with real, working Microsoft Learn links. Four agents split the work, each with exactly one job.

graph LR
    U["User Input<br/>(Resume + Job Description)"] --> A["ResumeParser<br/>Extract skills & experience"]
    A -->|Relay JD forward| B["JD Agent<br/>Extract requirements"]
    B -->|Relay Resume forward| C["MatchingAgent<br/>Score fit & identify gaps"]
    C -->|Gaps forward| D["GapAnalyzer<br/>Build learning roadmap"]
    D -->|MCP tool call| E["Microsoft Learn<br/>MCP Server"]
    E --> F["Result<br/>Fit Score + Gaps + Roadmap"]

    classDef node fill:#1e3a5f,stroke:#4a90e2,color:#e8f0fe
    class A,B,C,D,E,F node

Agent Responsibilities:

• ResumeParser: Reads the resume and pulls out skills, experience, certifications
• JD Agent: Reads the job description and extracts what it’s actually asking for
• MatchingAgent: Compares the two and produces a score from 0 to 100, plus a gap list
• GapAnalyzer: Turns those gaps into a learning plan, using a live tool call to Microsoft Learn’s MCP server for real, citable module links

Why Four Agents Instead of One

This is the part of the talk I spent the most time on, because it’s the part that actually transfers to other problems.

One agent trying to do all four jobs tends to rush every one of them, and when the final answer is wrong, there’s no way to tell which of the four steps failed. It’s all tangled into one response. Split into four focused agents, and each one becomes independently testable and independently debuggable. In the live demo, that meant opening the Agent Inspector, looking at four separate “spans,” one per agent, and knowing within seconds which step produced the wrong output. That’s not a demo trick, it’s a real production debugging pattern.

The honest tradeoff, which I said out loud on stage rather than glossing over: four agents means four model calls instead of one, so you’re paying more in tokens and latency. Worth it when you need to trust and audit each step. Not worth it for a quick one-shot summary.

The Pass-Through Pattern

Each agent in the chain can only see what the immediately previous agent said, not the original message, not the full history. That’s a deliberate setting (context_mode="last_agent"), and it’s what keeps each agent narrow and testable. But it creates a real problem: if a later agent needs something from earlier in the chain, someone has to explicitly copy it forward.

sequenceDiagram
    participant User
    participant RP as ResumeParser
    participant JD as JD Agent
    participant MA as MatchingAgent
    participant GA as GapAnalyzer

    User->>RP: Resume + Job Description
    RP->>JD: Parsed Resume + [JOB DESCRIPTION]<br/>(pass-through)
    JD->>MA: Extracted Requirements + [PARSED RESUME]<br/>(pass-through)
    MA->>GA: Fit Score 0-100 + Gap List
    GA->>User: Learning Roadmap with<br/>Microsoft Learn Links

    Note over RP,JD: Pass-through block is critical<br/>If missing, GA reports a specific error<br/>("no job description was provided")

I called this the pass-through pattern in the talk, and it’s the single idea I asked the audience to hold onto, because when it’s missing, you get a specific, recognizable failure (“no job description was provided”) that has nothing to do with the wiring and everything to do with a missing line in an earlier agent’s instructions. Knowing the difference between a wiring bug and a pass-through bug is exactly the kind of debugging instinct that matters once you’re not the one who wrote the code.

What I Actually Built and Showed, Live

Orchestration Layer

# The real orchestration, about ten lines
workflow = (
    WorkflowBuilder()
    .set_start_executor(resume_executor)
    .add_edge(resume_executor, jd_executor)
    .add_edge(jd_executor, matching_executor)
    .add_edge(matching_executor, gap_executor)
    .set_output_executors(gap_executor)
    .build()
)

hosted_agent = workflow.as_agent()

Tool Integration with MCP

# GapAnalyzer's one tool: a real MCP call to Microsoft Learn
@tool
async def search_microsoft_learn_for_plan(skill: str) -> list[dict]:
    async with streamable_http_client("https://learn.microsoft.com/api/mcp") as client:
        results = await client.call_tool(
            "search_content",
            {"query": skill, "content_type": "module"}
        )
        return results or FALLBACK_LEARN_URLS[skill]

The Pass-Through Implementation

[Agent Instructions - ResumeParser]

...

At the end of your response, include a section:
[JOB DESCRIPTION PASS-THROUGH]
<the original job description text, verbatim>

This lets the next agent in the chain access information
it would otherwise never see.

And because live demos do sometimes misbehave: I went in with a pre-deployed backup agent already running, specifically so that if the deploy stalled in front of everyone, I could switch to the live version and keep teaching instead of narrating a spinner.

Why This Kind of Work Matters

For developers watching: a real, working pattern for splitting an AI system into pieces you can actually trust, not just a toy demo, something you could genuinely fork and repoint at a different problem.

For teams building with AI: the same shape (read, extract, compare, act) shows up constantly outside resumes: support ticket triage, contract review, compliance checks, content moderation pipelines. The pattern transfers.

For anyone evaluating whether I can do this kind of work in front of real people, under real conditions: this talk is a decent proxy for what forward-deployed and solutions-engineering work actually looks like, going deep into a system, explaining it to people who didn’t build it, and staying calm and useful when something breaks in front of an audience instead of in a sandbox.

What This Talk Says About How I Work

I’m including this section deliberately, because a portfolio entry should tell you something about how someone operates, not just what they presented.

Reach and Impact

• Delivered live to a global Microsoft Reactor audience across multiple time zones
• Recording available indefinitely on-demand, continuing to gain views after the live session
• Closing session of a three-part Microsoft Reactor community series that ran across two weeks
• Finished code published and public, so the talk’s value didn’t end when the stream did

Resources

Watch and Read

• Full Session on Microsoft Reactor – Official event page with live recording
• YouTube: Build a Multi-Agent Career Copilot – Full recording with timestamps

Materials

• Presentation PDF with Code Examples – Slides and architecture diagrams
• Finished Repository – The exact code from the live demo, ready to fork