Rare-disease information triage: six source-isolated audits and safety-bounded arbitration

Scenario

A typical scenario: a patient or family member comes with a suspected rare disease and a mix of material: their own symptom notes, patient education from a nonprofit, guidelines or expert consensus, a genetic test result of uncertain significance, plus forum posts and ads for commercial tests. The sources disagree, and commercial pages often map similar symptoms straight to one disease and sell a test for it. Whoever organizes this information has to lay the conflicts out while holding the line: no diagnosis, no recommended treatments or products.

This example gives each type of source to its own agent, with no channel between them, and has a downstream arbiter judge only from the structured audits. The example plants a set of conflicts: the web and commercial sources map the symptoms to a fictional MYO-X-related myopathy, the guideline keeps a broad differential, and the genetic evidence is a variant of uncertain significance (VUS); the arbiter has to list this conflict explicitly. The example outputs no diagnosis, treatment or dosing advice, and the fixtures contain no real patient data.

How it works

The models in the table are the example repository's defaults; the actual choice is made per scenario at the design stage.

Source isolation comes from two places: each fixture is inserted only into its own audit agent's prompt, and all seven agents hold an empty ToolRegistry with an empty tools array, so none can read files or go online; the arbiter's prompt contains only JSON.stringify of the six audit results and never sees the raw fixtures. The six audits run one after another.

All seven agents have an outputSchema (Zod), temperature 0.1 and maxTurns 1. The framework appends the schema description to the system prompt, and if the first parse or validation fails it asks the model to answer again with the error message attached (src/agent/agent.ts); the script's outer runTimed gives each audit agent up to 3 attempts.

The arbiter's conclusion is one of four categories, credible_lead, conflicting_evidence, misleading_or_commercial or needs_specialist_review, alongside fields such as conflicts, missing_evidence, unsafe_elements, safe_next_steps and diagnosis_provided. The safety-policy fixture lists what is prohibited: no diagnosis, no confirming or ruling out a rare disease, no recommended treatments or doses, no recommended commercial tests, and no treating a VUS as grounds for diagnosis.

Result

Runnable artifacts and how to verify them:

Requires an API key. The script header lists ANTHROPIC_API_KEY and Node.js 20 or later as prerequisites, and the model can be overridden with the MODEL environment variable; run it with npx tsx packages/core/examples/cookbook/rare-disease-information-triage.ts.

The console first prints [RUN] / [DONE] and the duration for each of the six audit agents, a summary of each agent's output tokens and total audit time, then the arbiter's TriageDecision JSON.

After the run it checks 5 assertions: the conclusion is one of the three conflict or safety-concern categories, patient_facing_answer_allowed is false, diagnosis_provided is false, conflicts is non-empty, and unsafe_elements is non-empty. If any assertion fails, or any agent does not return structured output, the script exits with code 1.

Tested on commit 2f1d0ff on 2026-09-23: all six audit agents passed on the first attempt, the audits took about 29 seconds in total and the arbiter about 7 seconds; the conclusion was misleading_or_commercial with high confidence, listing 5 conflicts and 5 unsafe elements (including the commercial testing page's "quickly confirm MYO-X disease" and treating a VUS as grounds for diagnosis); all 5 assertions PASS, 7505 input / 7462 output tokens in total, exit code 0. This test run swapped the example's committed anthropic / claude-sonnet-4-6 for DeepSeek's deepseek-flash; the rest of the logic ran unchanged.

All six fixtures are labelled MOCK, and the gene name MYO-X and the case mock-rd-001 are fictional; the output is model-generated text for demonstrating and verifying the flow.

Sources

How this relates to YuanASI

The material on this page is a cookbook example in the official open-multi-agent repository, maintained by YuanASI.

If you have a real medical or health information process, and need to audit patient self-reports, guidelines, test reports and web content separately, then combine them within clear safety boundaries into material for doctors or clients, connected to your own knowledge base and review system, the matching YuanASI service is Custom AI Agent Development →