Four Agents, One Resume: Building a Fan-Out/Fan-In Pipeline in Microsoft Foundry

Microsoft Tech Community | July 15, 2026

Read the original post on Microsoft Tech Community →

graph LR
    A["4 Specialized Agents<br/>Tech Stack · Experience · Fit · Roadmap"]
    B["2 Core Patterns<br/>Fan-Out & Fan-In"]
    C["1 Hosted Deployment<br/>Foundry Agent Service"]

    style A fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style B fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style C fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px

Motive / Why I Wrote This

A single giant prompt asked to run an entire business pipeline will eventually let you down. I’ve watched it happen enough times that I stopped being surprised by it: the model loses track of an earlier instruction, skips a step, or gives you a different answer on every run even when nothing about the input changed.

I wrote this article, and built the lab behind it, to document a different way of working. Instead of asking one model to hold an entire pipeline in its head, you split the work across a small team of specialized agents, each with one job, and let a workflow coordinate them. Lab 02 of my Foundry Toolkit workshop is a concrete, working version of that idea: a resume-to-job-fit pipeline made of four agents that run in parallel, then merge their findings back together.

The goal was not to make something that looks impressive in a demo. It was to give developers a small enough system that they can trace every hop by hand, while still hitting the real problems that show up in production multi-agent systems: parallel execution, shared state, and agents that depend on other agents’ output.

Problem Context: Why Single-Prompt Pipelines Break

Ask one model to read a resume, score it against a job description, and produce a learning roadmap, all in one prompt, and you’ll usually get something that looks fine on the first try. The trouble starts on the second and third runs.

A few things tend to go wrong:

→ the model blends the technical assessment with the experience assessment instead of keeping them distinct,
→ the output format drifts between runs, which breaks anything downstream that expects structured data,
→ and there’s no natural place to inspect why the model reached a particular score, because everything happens inside one undifferentiated response.

None of this is really a “prompting” problem. It’s a structural one. A single prompt has no concept of stages, no way to checkpoint partial work, and no clean boundary where you could plug in a human reviewer or a different model for a specific sub-task. Splitting the work into agents fixes that, not by making any individual agent smarter, but by giving the system a shape you can actually reason about.

What I Built

Lab 02 builds a Resume → Job Fit Evaluator: a pipeline of four agents working across two stages, fan-out and fan-in.

graph LR
    Resume["Resume Input"]
    Resume -->|fan-out| Tech["Tech Stack Analyst"]
    Resume -->|fan-out| Exp["Experience & Impact Scorer"]
    Tech -->|fan-in| Fit["Fit Evaluator"]
    Tech -->|fan-in| Road["Roadmap Architect"]
    Exp -->|fan-in| Fit
    Exp -->|fan-in| Road
    Fit --> Out["Score + Roadmap"]
    Road --> Out

    style Resume fill:#e3f2fd,stroke:#1565c0
    style Tech fill:#e8f5e9,stroke:#2e7d32
    style Exp fill:#e8f5e9,stroke:#2e7d32
    style Fit fill:#fff3e0,stroke:#e65100
    style Road fill:#fff3e0,stroke:#e65100
    style Out fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px

In the fan-out stage, an incoming resume goes to two agents at once. The Tech Stack Analyst looks only at languages, frameworks, and tools. The Experience & Impact Scorer reads through career history, performance metrics, and any signs of leadership. Neither agent knows the other exists; they just do their one job and return structured output.

In the fan-in stage, both of those outputs feed into two more agents. The Fit Evaluator combines everything into a single compatibility score. The Roadmap Architect takes the same combined context and turns whatever gaps it finds into a short, practical learning path for the candidate.

I kept the scenario deliberately ordinary. A resume evaluator isn’t a flashy demo, but that’s the point: it’s exactly the kind of internal tool a team might actually build, and it exercises fan-out and fan-in without needing ten agents to make the concept land.

The End-to-End Process, Properly Explained

The lab is built as a sequence of docs inside the workshop repo, under workshop/lab02-multi-agent/, and it walks through the pipeline in the order you’d actually build it.

1. Prerequisites and understanding multi-agent design

Before touching code, the lab spends a short module on why fan-out and fan-in are the two patterns worth learning first. Most real multi-agent systems, even complicated-looking ones, are built out of these two primitives combined in different orders.

2. Scaffolding the multi-agent workspace

The Agent Builder interface in the Foundry Toolkit extension generates the starter project for all four agents in one step, so you’re not hand-writing folder structure and boilerplate before you’ve built a single agent.

3. Configuring each agent independently

Every agent gets its own agent.yaml, pointing at a model from the Foundry catalog and reading its endpoint from environment variables:

FOUNDRY_PROJECT_ENDPOINT=https://<your-workspace>.services.ai.azure.com/api/projects/<your-project>
AZURE_AI_MODEL_DEPLOYMENT_NAME=<your-ai-model>

Keeping configuration per-agent, rather than one shared config, matters once you want to swap a model for a single agent (say, a cheaper model for the Tech Stack Analyst) without touching the rest of the pipeline.

4. Testing locally with the Agent Inspector

This is where most of the real debugging happens, and it’s the part I spent the most time on while building the lab. The Agent Inspector traces what each agent actually saw and returned at every step, which matters a lot more with four agents than with one. Watching data pass through a fan-out and then get merged back in at the fan-in stage is a different kind of debugging than stepping through a single function; the Inspector is what makes that traceable instead of a black box.

5. Deploying and verifying the live pipeline

Once the local runs look right, the extension packages the whole agent team and registers it with Foundry Agent Service as a live Hosted Agent, no server to provision by hand. The Remote Agent Playground then gives you a page where you can drop in a real resume and watch all four agents process it in the cloud, streamed in real time.

graph LR
    A["Scaffold<br/>Agent Builder"]
    B["Configure<br/>agent.yaml"]
    C["Test Locally<br/>Agent Inspector"]
    D["Deploy<br/>One Click"]
    E["Verify Live<br/>Remote Playground"]

    A --> B --> C --> D --> E
    C -->|iterate| B

    style A fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style B fill:#fff3e0,stroke:#e65100
    style C fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style D fill:#f3e5f5,stroke:#6a1b9a
    style E fill:#fce4ec,stroke:#c2185b,stroke-width:2px

Why You Should Try This Lab

graph TB
    subgraph SMALL["Small Enough to Understand"]
        S1["4 agents, 2 patterns"]
        S2["No 10-agent maze to debug"]
    end

    subgraph DEBUG["Debugging Is the Point"]
        D1["Agent Inspector traces every hop"]
        D2["The skill that transfers to production"]
    end

    subgraph DEPLOY["Ends in a Real Deployment"]
        E1["Not a notebook"]
        E2["Live on Foundry Agent Service"]
    end

    style SMALL fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style DEBUG fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style DEPLOY fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px
    style S1 fill:#c8e6c9
    style S2 fill:#c8e6c9
    style D1 fill:#bbdefb
    style D2 fill:#bbdefb
    style E1 fill:#e1bee7
    style E2 fill:#e1bee7

Four agents and two patterns is enough to hit real multi-agent problems, parallel execution, merged state, dependent outputs, without needing to trace ten moving parts to find a bug. A lot of multi-agent tutorials stop at “here’s how you define agents”; this one spends real time on the Agent Inspector, because tracing agent-to-agent communication is the skill that actually transfers to production systems. And it doesn’t stop at a local script: you deploy to Foundry Agent Service and verify the result in a live playground, so you leave with a working, hosted pipeline instead of code that only runs on your machine.

A Quick Note on Sequencing

This is the second lab in the workshop. The first covers a single agent end to end, from scaffolding through deployment, and Lab 02 assumes you’re comfortable with that flow before adding the coordination layer on top. If you haven’t built an agent with the Foundry Toolkit before, start there; if you have, this lab is where things get more interesting.

Get Started in 5 Minutes

If you have Python and access to a Microsoft Foundry project, the fastest way to see the pipeline is:

→ Clone the workshop repository.
→ Open workshop/lab02-multi-agent/ and follow the README.
→ Scaffold the four agents with the Agent Builder.
→ Run the pipeline locally and trace it with the Agent Inspector.
→ Deploy and test it against a real resume in the Remote Agent Playground.

Seeing four agents actually hand off work to each other, instead of reading about fan-out and fan-in as abstract terms, is what makes the pattern click.

Learn More & Explore Further

Key Takeaways

→ Multi-step pipelines tend to break down when they’re handled by one large prompt; splitting the work into specialized agents gives the system a shape you can actually debug.
→ Fan-out and fan-in cover a surprising amount of real multi-agent design once you see them applied to an actual pipeline instead of a diagram.
→ Local tracing tools like the Agent Inspector matter more as agent count goes up, not less.
→ A small, ordinary scenario, like scoring a resume, is often a better teaching example than a flashy one, because it keeps the focus on the coordination pattern instead of the use case.

Read the Full Article

→ Microsoft Tech Community post

Building a Fully Managed Multi-Agent Pipeline with Microsoft Foundry