One healthcare-governance problem — keeping internal policies in step with new MOH circulars — solved end-to-end by a team of cooperating agents. A worked case study in the orchestration pattern, grounded in real documents.
In Workflow Patterns (D1) you met orchestration — a coordinator that decides the plan as it runs and pauses at human gates. This case study puts that pattern to work on one real healthcare-governance problem: keeping Synapxe's internal policies and SOPs in step with new MOH circulars. It's a job no single-purpose agent handles well, because it spans retrieval, interpretation, comparison, drafting and review — each a different skill.
A new MOH circular arrives — say, an update to data-handling or infection-control requirements. Somewhere in Synapxe's policy library, an unknown number of internal policies and SOPs may now be out of date. Today a compliance officer has to work out which documents are affected, read the circular against each one, decide what must change, draft the updates, and get them signed off — largely by hand, and largely in sequence.
The Guideline Assistant you built in Foundations is a single grounded agent — brilliant at one focused task, like answering a question from one policy. The compliance cycle is bigger: it needs several kinds of expertise working together and reporting to a coordinator. That's a multi-agent system.
One clear job, grounded in your documents, with a human verifying. This is where you start — and where most value lands first.
Different specialists (retrieve, interpret, compare, draft, review) run in coordination under one coordinator, so a cross-cutting job gets done in one pass.
A human still owns the decision. More agents means more discipline about where a person approves — not less.
A multi-agent system mirrors how a good compliance team already works: a coordinator who owns the outcome, a set of specialists who each do one thing well, and a reviewer who checks the whole before it goes to a human. Each agent has its own instructions, its own grounding documents, and its own tools — just like a real person has their own remit. Click any card to see what it does, what it reads, and what it hands on.
Reads the circular, decides who does what, resolves conflicts, assembles the brief.
Finds the internal policies & SOPs the circular might touch — grounded in the library.
Extracts the concrete obligations from the circular — what must change, and by when.
Compares each policy to the new rules, finds the gaps, flags who's affected.
Drafts the revised policy text and a plain-language change notice — with citations.
Cross-checks the specialists, builds the traceability matrix, prepares the sign-off pack.
Not an agent — the person who reviews, decides, and signs off. Always in the loop.
You could try to make one giant agent do everything. In practice, splitting into specialists is what makes the system trustworthy and maintainable — the same reasons you'd split the work across a real team.
Each agent's system prompt does one job, so it's shorter, sharper, and less likely to drift than one prompt trying to do five things.
The Retrieval agent knows the library; the Requirements agent knows how to read a circular. Each is grounded in exactly the documents it needs.
You can check the Gap agent on its own — feed it a policy and a rule, see if it finds the gap. Easier to trust, easier to fix.
When the coordinator finds a conflict it can't resolve, it escalates to the human — rather than one opaque model guessing.
This is the whole system in one picture. The coordinator reads the circular, spawns the specialists it needs, gathers their work, and routes it through a reviewer to a human approval gate before anything is finalised. Click any agent to see its moment, or press auto-play to watch a circular flow from the officer's desk to a signed-off compliance brief.
The coordinator doesn't follow a fixed script — it decides the plan from what the circular contains. A one-line data-retention tweak might touch two SOPs; a new infection-control standard might touch twenty. Same team, different plan each time.
Here's the same flow told as a story — a single MOH circular travelling from the officer's desk to a signed-off brief. Notice where the work runs together, where the coordinator decides, and where a human stays in control.
The deliverable isn't a wall of text — it's a table a human can audit at a glance. Every new requirement is tied to a document, a change, and an owner, with the source cited. This is illustrative of the shape of the output, not real Synapxe policy data.
| Circular clause | Affected policy / SOP | Proposed change | Owner · status |
|---|---|---|---|
| Data-retention period updated | Records Management SOP | Revise retention schedule; cite new clause | Records · draft |
| New breach-notification window | Data Incident Response Policy | Shorten notification timeline; add step | InfoSec · draft |
| Access-review frequency | Access Control Policy | Gap — no current clause; new section needed | IT · flag |
| Staff awareness requirement | Training & Awareness SOP | Add mandatory refresher on the new rule | HR · draft |
The point of the team isn't a magic number — it's a change in shape. Manual work is sequential and lives in one inbox; the multi-agent flow runs the reviews together and leaves a complete, cited trail for a human to approve.
Policy & circular compliance is a textbook fit for multi-agent, for the same reasons a good manager splits work across a team rather than asking one person to do it all.
The Requirements agent reads circulars; the Retrieval agent knows the library. Each is grounded in exactly its own documents — no one agent has to be good at everything.
Once the coordinator has the candidate policies, the per-policy comparisons and drafts don't wait in a queue — they proceed together.
The coordinator sizes the job to the circular. A small tweak spawns two sub-tasks; a major standard spawns many. Nothing is over- or under-done.
Every clause is tied to a source and an owner. That audit trail is exactly what a governance function needs — and what a single black-box answer can't give.
More agents means more power and more to manage. These are the costs to weigh before reaching for a multi-agent design — the same ones the DNA / IT team will raise.
Seven agents conversing is harder to follow than one. You need agent traces and logs of every step — plan for observability from day one.
Even run together, each specialist call takes time. Fine for a compliance cycle measured in hours — not for real-time chat.
Several system prompts and tool sets to version. A change in one specialist can ripple — treat prompts like code.
For compliance, accountability sits with a person. The team drafts and traces; a human approves. That gate is not optional.
You've seen the full team. The honest picture: AgentSea today runs a single grounded agent, so you don't wire up seven cooperating agents this afternoon. What you can do is design the system now, and deliver the value in pieces with today's tools — then adopt coordination as the platform matures.
| Piece | Its one job | Why it's separate |
|---|---|---|
| 🎼 Coordinator | Plan, dispatch, resolve, assemble | Owns the outcome and decides the plan at runtime |
| 👥 Specialists | Retrieve · interpret · compare · draft | Each grounded in its own docs, testable on its own |
| ✅ Reviewer | Cross-check, build the matrix | Catches conflicts before a human sees them |
| 🧑⚖️ Human gate | Review, decide, sign off | Accountability stays with a person — always |
When you fill in your Agent Design Canvas, ask whether your use case is really one agent or a small team. If it's a team, name the coordinator, list the specialists, and — most importantly — mark where a human must approve. That labelled design is your brief to the DNA / IT team.