Multi-agent clinical workflows

Reviewed by Dr. Ram Kumar G, MBBS, MD (Internal Medicine), MPH (USA), on 2026-10-18 · Last updated 2026-10-18

Intermediate
Clinical focus
About 30 minutes
Includes exercise

Before this lesson: Tool calling against FHIR data

In short

Multi-agent systems divide a task between several model-driven agents, for example one that gathers facts, one that checks them and one that drafts a summary, sometimes coordinated by an orchestrator. Splitting work can improve focus and allows independent checking, but small error rates compound across steps, and agents built on the same model can share the same blind spots. Clinical multi-agent workflows need independent verification against the source record and a clinician approval gate before anything affects care.

You will learn to

Describe common multi-agent patterns: pipelines, orchestrator-workers, panels and checkers
Calculate how per-step error rates compound across a workflow
Build a pipeline in which a checker independently verifies an extractor
Critically appraise claims about multi-agent diagnostic systems

Common patterns

Research systems such as MDAgents, which adapts the number and roles of agents to a case's complexity, report better results on medical question benchmarks than single agents. Gains on benchmarks need to be confirmed on real workflows.

Pattern	How it works	Clinical example
Pipeline	Fixed sequence of agents, each doing one job	Extract facts → check → draft a review summary
Orchestrator and workers	One agent plans and delegates subtasks to others	Plan a pre-clinic summary, delegating labs, medicines and letters
Panel or debate	Several agents propose and critique answers, then combine	A 'virtual panel' discussing a diagnostic puzzle
Checker or verifier	A separate agent or rule set verifies another's output against sources	Re-query the record to confirm every value in a draft

Errors compound

If each step of a workflow succeeds independently with probability p, the whole chain of n steps succeeds with probability p to the power n. Agent steps are not fully independent, but the arithmetic shows why long chains need checks.

python

for per_step in [0.99, 0.95, 0.90]:
    print(f"per-step success {per_step:.0%}: " + ", ".join(
        f"{n} steps {per_step ** n:.0%}" for n in [1, 3, 5, 10]))

# per-step success 99%: 1 steps 99%, 3 steps 97%, 5 steps 95%, 10 steps 90%
# per-step success 95%: 1 steps 95%, 3 steps 86%, 5 steps 77%, 10 steps 60%
# per-step success 90%: 1 steps 90%, 3 steps 73%, 5 steps 59%, 10 steps 35%

End-to-end success for chains of 1 to 10 steps at three per-step success rates.

Ten steps that are each 95% reliable complete correctly only 60% of the time.
Shorter chains, more reliable steps (deterministic code where possible) and verification at key points all help.

A pipeline with an independent checker

The example uses the synthetic FHIR bundle and patient-scoped tools from the previous lesson. The extractor makes a typical mistake: it reports an older HbA1c. The checker re-queries the record independently, rather than trusting the extractor, and flags the mismatch along with a clinically relevant combination.

python

tools = PatientTools(resources, patient_id="p1")

def extractor_agent(tools):
    """Gathers facts. Simulated mistake: reports the OLDER HbA1c (8.2%) instead of the latest."""
    return {"hba1c": {"value": 8.2, "source": "Observation/o1"},
            "egfr": tools.latest_observation("98979-8"),
            "medications": tools.active_medications()}

def checker_agent(facts, tools):
    """Independently re-queries the record and compares; flags any mismatch."""
    issues = []
    latest = tools.latest_observation("4548-4")
    if facts["hba1c"]["value"] != latest["value"]:
        issues.append(f"HbA1c {facts['hba1c']['value']} ({facts['hba1c']['source']}) is not the latest: "
                      f"{latest['value']} on {latest['date']} ({latest['source']})")
    on_metformin = any("metformin" in m["medication"].lower() for m in facts["medications"])
    if on_metformin and facts["egfr"]["value"] < 45:
        issues.append(f"On metformin with eGFR {facts['egfr']['value']} (below 45): review with prescriber")
    return issues

def drafter_agent(facts, issues):
    status = "NEEDS CLINICIAN REVIEW" if issues else "draft"
    lines = [f"[{status}] Diabetes review summary (synthetic patient p1)"]
    lines += [f"- HbA1c {facts['hba1c']['value']}%", f"- eGFR {facts['egfr']['value']}"]
    lines += [f"- FLAG: {i}" for i in issues]
    return "\n".join(lines)

facts = extractor_agent(tools)
issues = checker_agent(facts, tools)
print(drafter_agent(facts, issues))

# [NEEDS CLINICIAN REVIEW] Diabetes review summary (synthetic patient p1)
# - HbA1c 8.2%
# - eGFR 41
# - FLAG: HbA1c 8.2 (Observation/o1) is not the latest: 7.4 on 2026-07-02 (Observation/o2)
# - FLAG: On metformin with eGFR 41 (below 45): review with prescriber

Run the bundle and PatientTools blocks from the FHIR lesson first.

The checker caught the outdated value because it went back to the source, with provenance, instead of asking the extractor whether it was sure.
The draft is clearly marked for clinician review and keeps both the error and the flag visible. A real system would correct the value and record that a correction was made.
Checkers built on the same model and prompt as the agent they check can share its errors; rule-based checks against the source, or a different model, add independence.

Teaching code, not a clinical tool

The agents in this track use synthetic patients and a scripted stand-in for the language model, so they run without an API and without real data.
Agents that can read or change real health records need organisational approval, security review, access control and, where they influence care, regulatory assessment.

Reading claims about multi-agent diagnosis

In a 2025 preprint, Microsoft researchers described an orchestrator that simulates a panel of physicians working through 304 difficult case records from the New England Journal of Medicine step by step. They reported up to 85.5% diagnostic accuracy, against an average of 20% for generalist physicians.

The cases are published diagnostic puzzles, chosen for difficulty, not typical clinic patients.
Physicians in the comparison worked without colleagues, reference books or other aids they would normally use.
It was a preprint at the time of publication, and accuracy on curated cases is not evidence of benefit in practice. Prospective evaluation in real workflows is needed.

Where should a human approve a multi-agent workflow's output?

Could the output change care, a record or a communication with a patient?
- If No, internal draft only
  1. Label as AI-drafted; spot-check and audit regularly
- If Yes
  1. Has an independent check against the source passed?
    If No
    Block and route to a clinician with the flags
    If Yes
    Clinician reviews and approves before anything is sent or saved

A simplified design aid for learning purposes; local governance decides the actual approval rules.

Exercise

Build a small multi-agent pipeline over synthetic FHIR data, inject errors and measure how well independent checks catch them.

Data: Synthetic FHIR bundle from the previous lesson (Generated in the notebook)

Reproduce the extractor, checker and drafter pipeline.
Inject five different extractor errors (wrong value, stopped medicine reported as active, wrong unit, missing allergy, wrong patient) and record which the checker catches.
Extend the checker to catch the errors it missed, using only re-queries of the source record.
Simulate 1,000 runs with random step failures (95% per step, 4 steps) with and without the checker, and compare end-to-end error rates.
Write the approval rules you would propose for a pre-clinic summary agent in your setting.

The runnable notebook and worked solution will be published soon. You can work through the steps with the code on this page in the meantime.

Key takeaways

Multi-agent systems split tasks into roles: pipelines, orchestrators, panels and checkers.
Per-step errors compound; keep chains short and verify at key points.
Checkers should re-check the source independently, not trust other agents.
Diagnostic benchmark claims need careful reading; human approval stays essential.

Terms used: AI agent, Human-in-the-loop, Multi-agent system, Tool calling

FAQ

What is a multi-agent system?

A workflow in which several model-driven agents with different roles, such as gathering, checking and drafting, work on parts of a task, sometimes coordinated by an orchestrator agent.

Are multi-agent systems more accurate than single agents?

Sometimes, on benchmarks, especially with verification steps. But each extra step can add errors, and agents sharing the same model may share mistakes. Evaluate on your real task.

Can AI agents diagnose better than doctors?

Some research systems score highly on curated diagnostic puzzles, but comparisons often restrict physicians' usual resources, and there is not yet evidence of better outcomes in real practice.

What makes a good checker agent?

Independence: it re-queries the original source, uses rules or a different model where possible, and flags uncertainty rather than silently correcting.

Where should humans be involved?

Before any output changes care, the record or a communication with a patient, and whenever an automated check fails.

Sources

Educational content only. This material teaches methods; it is not clinical advice. Code, models and examples here are not validated medical devices and must not be used to make decisions about real patients without proper clinical validation, governance and any required regulatory approval. Examples use synthetic or openly licensed de-identified data only. Never paste identifiable patient information into public AI tools. Mentions of models, tools or vendors are for identification, not endorsement.