The Orchestration Layer

Definition

The connective layer between capable models and useful care: routing, agent lifecycle, tool access, safety monitoring, memory, and the records everything reads and writes. It is the part of an AI-enabled health system that does not exist yet, and the reason capability keeps outrunning deployment.

Almost everything needed to build AI-enabled care already exists somewhere in a large health system. The EHR is there. The data platform is there. The models are available under enterprise agreements. What is missing sits between them.

DEPLOYMENT ZONE TENANT · BAA ON-PREM · EDGE EXTERNAL Engagement surfaces WHERE PEOPLE MEET THE SYSTEM Personal companion multimodal · patient-side Member portal app · web Outreach channels SMS · voice · email Clinician + staff tools in-workflow assistants Consumer devices wearables · home · third-party AI Orchestration THE LAYER THAT DOES NOT EXIST YET Routing, agent lifecycle, tool registries, handoffs Model gateway routing by task complexity, token budget, retention policy TO BUILD Agent orchestration graph runtime, task agents, scoped identity per agent TO BUILD Tool + context protocol MCP client and server, agent-to-agent, API gateway EMERGING The membrane consolidates inbound outreach, carries outbound intent with context TO BUILD Safety and governance BESIDE THE CONVERSATION, NEVER INSIDE IT Proxy and guardrails PHI redaction, prompt policy, jailbreak and injection defense Independent risk monitor crisis detection, escalation state, separate from the talker Audit and provenance every action to a request, every claim to a source Evaluation and drift completion and abandonment, equity disaggregation, model and agent drift The two records THE OBJECTS EVERYTHING ELSE READS AND WRITES Trajectory record Who this person is, where their health is headed, what matters. CLINICAL STATE · GOALS · RESPONSE HISTORY · PROJECTED PATH Slow · clinical · permissioned layers per stream Coordination record What is open right now, who owns it, what turn, what is overdue. ITEM · OWNER · STATE · TURN · DUE · BLOCKING REASON Fast · operational · crosses organizational boundaries Exposed to every application through a single member-context API. Portable on request — exit is the test of ownership. Knowledge and memory GROUNDING Clinical retrieval vetted corpus, protocols, citation on every claim Working memory short and long term, per-member ontology Cohort reference what happens to people like this one Enterprise knowledge policy, benefits, coverage, operations — the questions nobody can answer today Data platform MOSTLY ALREADY EXISTS EHR FHIR APIs, registries, clinical warehouse Lakehouse claims, utilization, quality measures Ambient capture encounter transcripts, secure messages Social context SDOH screening, life events Device and signal streams wearables, remote monitoring, pharmacy fills Inference WHERE THE GATE ACTUALLY SITS Frontier models in tenant Private endpoints under BAA. No training on inputs, no retention, region-pinned. TENANT · BAA Open models on-prem Self-hosted for the most sensitive work and for cost control at volume. ON-PREM Small and edge models On device or at the edge: triage, classification, redaction, vision. Cheap, fast, private by construction. EDGE Almost every box below the orchestration line already exists. The gap is the connective layer above it. Which is why the constraint on AI-enabled care is architectural rather than technical — and why the deployment boundary, not the model, is what enterprises actually negotiate.
Figure A reference architecture for an integrated delivery system

Generic reference model. Component names are industry-standard rather than vendor-specific, and deployment zones reflect the boundaries most health systems actually negotiate.

Reading the diagram

Two things are worth noticing about the shape of it.

The bottom half is mostly built. EHR and FHIR access, a lakehouse, quality registries, ambient documentation, social screening, device streams. Health systems have spent fifteen years and enormous sums assembling exactly this. It is not the constraint.

The gap is the band above it. Model gateway, agent orchestration, the membrane, an independent risk monitor, and the two records everything else reads and writes. Very little of that exists in production anywhere, and none of it is a model problem.

Why the deployment zone matters more than the model

Every enterprise conversation about AI in healthcare eventually stops being about capability and starts being about where the inference happens. That is not obstruction. It is the shape of the constraint.

Tenant under a business associate agreement. Frontier models reached through private endpoints inside the organization's own cloud tenant, with contractual guarantees that inputs are not retained or trained on and that data stays in a known region. This is where most enterprise health AI runs today, and it is the minimum bar for anything touching protected health information.

On-premises. Open-weight models self-hosted for the most sensitive workloads, and increasingly for cost control once volume is real. Inference cost is an operating expense that scales with success, which changes the calculus in a way pilots never reveal.

Edge and small models. Classification, triage, redaction, and vision running on device or close to it. Cheap, fast, and private by construction rather than by contract. Underused, and the most likely place for near-term wins that do not require a governance cycle.

The practical consequence is that architecture decisions get made on the boundary, not on the benchmark. A slightly less capable model that can run where the data already sits will beat a better model that cannot, every time. That is a real constraint and it is not going away, which is an argument for designing around it rather than waiting it out.

What the layer has to do

Route. Send each request to the right model — small and fast for triage and classification, larger for reasoning that warrants it. This is what makes continuous use affordable rather than a pilot with a budget line.

Hold context. Working memory, per-member ontology, and retrieval over vetted clinical sources with citation attached to every claim.

Act across systems. Scoped task agents with explicit tool registries, so nothing reaches further than its job requires, and every action traces back to a request.

Watch itself. Risk monitoring that runs beside the conversation rather than inside it. Drift detection on agent behavior and clinical error. Outcome measurement disaggregated by population, because a system that works on average and badly for some has failed.

Maintain the records. The trajectory record and the coordination record, exposed to any application that needs member context through a single interface.

Two lenses for anything you are about to build

A test worth applying to every AI use case an organization evaluates. Does this optimize the current model, or does it advance toward the future state?

Both can be valuable. But they should be labeled honestly. A tool that improves documentation throughput is current-state optimization. A tool that builds a continuous signal layer, or maintains a record between visits, is future-state infrastructure. Most organizations need both and fund only the first, because the first has a return you can put in a slide and the second has a return that arrives later and lands somewhere else on the org chart.

That is the same pattern as absorb versus streamline, one layer down in the stack.

← All concepts