Building Agentic Clinical Operating Systems: Architecture, Orchestration, and Governance
- Jun 23
- 8 min read

By David Stone, CEO, TransformativeMed
April 2026
In Part 1 of this series, we explored why healthcare needs Agentic Clinical Operating Systems—the shift from passive EHR repositories to intelligent, autonomous coordination. But understanding the vision is only the beginning. The harder question is: How do you actually build one?
Building an ACOS isn't simply a matter of adding ChatGPT to your EHR. It requires fundamental architectural decisions about event processing, agent orchestration, data semantics, and clinical governance. Get these foundations wrong, and you end up with expensive demos that can't scale to production. Get them right, and you unlock genuine transformation in clinical operations.
Drawing from our real-world experience at 100+ hospitals and over 15yrs of implementations, in this article we examine the technical architecture of emerging production-grade ACOS platforms.
The Four Architectural Pillars
An effective ACOS platform rests on four interconnected architectural components:
1. Event-Driven Infrastructure
Traditional healthcare IT systems operate on a request-response model. A user clicks a button, the system queries a database, and information is returned. This model fundamentally doesn't match how clinical care actually works.
In reality, hospital operations are driven by events: a patient's status changes, a lab consult is ordered, a note is documented. These events happen asynchronously, often simultaneously across hundreds of patients. An ACOS must be able to detect, process, and respond to these events in real-time without waiting for human requests.
This requires event-driven architecture capable of:
High-volume event processing – Handling 150,000+ asynchronous events per second across a health system
Stateful stream processing – Maintaining context about each patient's journey through complex, multi-day workflows
Event sourcing and replay – Reconstructing the sequence of clinical events for auditing, debugging, and continuous improvement
Exactly-once semantics – Ensuring that critical clinical actions (sending a communication, updating a care plan) happen once and only once, even in failure scenarios
This is not a problem that traditional relational databases or batch ETL processes can solve. It requires platforms specifically designed for real-time event stream processing at healthcare scale.
Why We Chose Vantiq
TransformativeMed evaluated multiple orchestration platforms before partnering with Vantiq. The decision came down to three factors:
|
2. Multi-Agent Orchestration
The "agentic" in ACOS refers to autonomous agents that perceive, reason, and act. But in complex clinical workflows, no single agent can handle the entire process. You need specialized agents working in coordination.
Consider discharge planning. A monolithic "Discharge Agent" would need expertise across medical readiness assessment, rehabilitation therapy evaluation, insurance coverage determination, disposition planning, and care team communication. That's an impossible cognitive load for a single LLM prompt, and it creates brittleness—any domain requires the entire agent to be retrained.
Instead, effective ACOS platforms use multi-agent orchestration:
Domain-specific agents – Each agent has a narrow scope of responsibility aligned with clinical specialization (Rehab Agent, Medical Readiness Agent, Disposition Agent)
Shared state management – Agents read from and write to a common discharge plan object, ensuring all team members see a consistent view
Event-driven coordination – Agents subscribe to relevant EHR events and activate when their domain expertise is needed, without central coordination overhead
Asynchronous execution – Agents work in parallel; the Rehab Agent doesn't wait for the Medical Readiness Agent to complete
This mirrors how human clinical teams actually operate—specialized roles working asynchronously toward a common goal—and it's far more robust and maintainable than monolithic approaches.
3. Semantic AI-Data Platform
EHR data was designed for human consumption and regulatory compliance, not AI reasoning. A typical hospital discharge note contains critical information buried in narrative text: "Plan for discharge tomorrow AM pending PT clearance and family meeting to arrange home oxygen delivery."
An ACOS needs to transform this unstructured narrative into structured, semantic representations that agents can reason over:
Anticipated discharge date: Tomorrow AM
Barriers: PT clearance pending, family meeting needed
DME requirements: Home oxygen
Tasks: Complete PT evaluation (owner: PT), Schedule family meeting (owner: Case Management), Arrange oxygen delivery (owner: Case Management)
This semantic transformation happens through a combination of:
Natural Language Processing – LLMs extract entities and relationships from clinical narratives
Clinical ontologies – Mapping extracted concepts to standardized terminologies (SNOMED, LOINC, ICD-10)
Temporal reasoning – Understanding time-based relationships ("tomorrow AM" relative to note timestamp; "pending PT clearance" as a dependency)
Vector embeddings – Creating semantic representations that capture clinical meaning beyond exact keyword matching
This semantic layer sits between the EHR's data structures and the agents' reasoning engines, providing the "context at scale" that makes autonomous coordination possible.
4. Deep EHR Integration
An ACOS that can't read from and write to the EHR is just an expensive analytics dashboard. True autonomous coordination requires bidirectional integration:
Real-time event streaming – Receiving EHR events (new notes, orders, results) within seconds of occurrence
Bidirectional data flow – Reading patient demographics, clinical data, and workflow state; writing back care plans, tasks, and communications
Workflow embedding – Displaying agent-generated insights directly in clinician workflows (PowerChart, mobile apps) rather than forcing context switches
Standards-based APIs – Leveraging SMART-on-FHIR, HL7, and vendor-specific APIs (Oracle's MPages, Epic's Interconnect) to avoid brittle point-to-point integrations
The integration architecture must also respect clinical safety requirements: ensuring that automated updates are clearly labeled, maintaining audit trails, and providing override mechanisms when human judgment differs from agent recommendations.
The Governance Challenge: Preventing AI
Hallucinations
The most dangerous failure mode in clinical AI isn't obvious errors—it's confident incorrectness. LLMs can "hallucinate" plausible-sounding but entirely fabricated information, and in healthcare, that's unacceptable risk.
Production ACOS platforms implement multiple layers of governance:
Multi-Agent Verification
One powerful technique is using "challenge agents" that independently verify the work of primary agents. For example:
The Chart Review Agent extracts "Anticipated discharge: April 22 AM" from a clinical note
The Verification Agent independently reviews the same note and validates whether April 22 AM is actually documented
If the agents disagree, the system flags the discrepancy for human review rather than confidently displaying incorrect information
This approach leverages the fact that LLM errors are stochastic—two independent agents are unlikely to hallucinate the same incorrect information. Disagreement becomes a signal of uncertainty.
Source Citation and Traceability
Every agent-generated insight must be traceable to source documentation. When an ACOS displays "PT cleared patient for discharge on 4/21," clinicians can hover to see the exact PT note and timestamp where that information was documented.
This serves two purposes:
Clinical validation – Clinicians can quickly verify that the AI interpretation matches their understanding of the source material
Continuous improvement – When errors occur, development teams can trace back to the specific prompt, model, and source document to understand what went wrong
Confidence Scoring and Human-in-the-Loop
Not all agent actions should be fully autonomous. ACOS platforms implement tiered autonomy based on clinical risk:
High confidence, low risk → Fully autonamous (e.g., extracting anticipated discharge date from a note that explicitly states it)
Medium confidence or medium risk → Autonomous with human review (e.g., inferring that PT has cleared a patient based on note content without explicit statement)
Low confidence or high risk → Human-in-the-loop approval required (e.g., determining medical readiness based on complex clinical reasoning)
The system learns over time which scenarios require human oversight and which can be safely automated, gradually expanding the autonomous envelope as confidence grows.
Real-World Governance: The Endocrinology Consult Case In early testing of agentic discharge planning, the Communication Agent reached out to an endocrinology consult service: "Is your service still following the patient?" The clinician responded: " No, signed off today, will write note this afternoon after clinic."
The agent correctly updated the discharge plan to show endocrinology as "signed off" but initially set the expected sign-off note time as "this afternoon"—which was ambiguous. A challenge agent flagged the ambiguity: "afternoon" relative to when? The system prompted the Communication Agent to clarify, and the response was updated to include a specific timestamp. This kind of multi-layer verification—combined with human review of edge cases—builds robustness that single-agent systems can't achieve. |
Hybrid Workflows: Bridging Legacy and Agentic
A critical but often overlooked aspect of ACOS architecture is that pure agentic workflows are not yet realistic for most clinical processes. The reality on the ground is that effective ACOS implementations are hybrid—combining autonomous agents with traditional application interfaces and manual workflows.
For example, in discharge planning:
Autonomous components – Chart review continuously scans notes; Communication agent proactively reaches out to clinicians
Traditional UI components – Discharge coordinator dashboard displays patient lists with filterable columns; manual override controls for editing disposition and estimated dates
Workflow automation – Automated task assignment based on agent-identified needs; manual task creation still available
This hybrid approach recognizes that clinicians need control and visibility. Full
autonomy isn't the goal; appropriate autonomy that reduces burden while maintaining clinical oversight is the goal.
Architecturally, this means ACOS platforms must support:
Seamless integration of agent-generated data with user-entered data
Clear visual distinction between autonomous updates and manual entries
Override capabilities that don't break agent logic
Gradual migration paths from manual to autonomous workflows
The Development Velocity Challenge
AI capabilities are evolving at unprecedented speed. GPT-4 was state-of-the-art in early 2023; by late 2024, multiple models surpassed its capabilities. New multimodal models, smaller specialized models, and novel architectures emerge monthly.
Organizations that hard-code specific LLM dependencies or build custom orchestration frameworks face a brutal tradeoff: they can't keep pace with AI evolution without constant re-engineering. By the time they deploy a custom-built system, it's already using outdated models.
This is why platform abstraction is critical. An effective ACOS platform should:
Support multiple LLM providers – Allowing easy switching between OpenAI, Anthropic, Google, open-source models as capabilities evolve
Provide model routing logic – Automatically selecting the most appropriate model for each task based on cost, latency, and accuracy requirements
Enable rapid prompt iteration – Allowing clinical teams to test and refine agent behaviors without engineering bottlenecks
Abstract orchestration complexity – Handling agent communication, state management, and error recovery at the platform level rather than requiring custom code
Organizations building ACOS capabilities in-house often underestimate this challenge. What starts as "we'll just use GPT-4 with some clever prompts" quickly becomes "we need a team to manage model evaluation, prompt versioning, orchestration logic, and continuous retraining."
Partnering with platforms like Vantiq that solve these problems at the infrastructure level allows healthcare organizations to focus on clinical innovation rather than AI engineering.
The world is moving fast. If we built the foundations on our own, they'd be outdated by deployment. Vantiq gives us the ability to move at the speed of the market while maintaining reliability, governance, and clinical safety.
Lessons from Production Deployments
Having deployed our Best in KLAS® CORES Platform across 100+ hospitals, several hard-learned lessons shape how we approach ACOS architecture:
Start with high-volume, high-burden workflows. Discharge planning, care transitions, and quality surveillance generate massive coordination overhead. Automating these workflows delivers immediate, measurable ROI that funds further innovation.
Design for incremental autonomy. Don't try to achieve full automation on day one. Deploy agents that assist human coordinators first, then gradually expand autonomous capabilities as confidence and trust build.
Invest heavily in observability. You need to see what agents are doing, why they're doing it, and when they're getting it wrong. Comprehensive logging, real-time monitoring dashboards, and error alerting are not optional.
Co-develop with clinical teams. IT-driven ACOS projects fail. The most successful implementations involve case managers, social workers, and physicians in prompt design, workflow configuration, and continuous refinement.
Plan for organizational change management. Agents change clinical roles. Case managers evolve from project coordinators to clinical experts focused on complex cases. This is a positive shift, but it requires training, role redefinition, and leadership support.
Looking Ahead: The Implementation Journey
Understanding the architecture of ACOS platforms is essential, but it's only part of the story. The final piece is: How do healthcare organizations actually implement these systems?
In Part 3 of this series, we'll examine the implementation journey—from initial pilot to enterprise-scale deployment. We'll cover stakeholder engagement, ROI measurement, regulatory considerations, and the critical success factors that separate successful ACOS implementations from expensive failed experiments.
Next in This Series
Part 3: Implementing Agentic Clinical Operating Systems: From Pilot to Production
What does ACOS implementation actually look like? We'll share real-world case studies, ROI frameworks, change management strategies, and the roadmap for scaling from a single use case to enterprise-wide autonomous coordination.
About the Author: David Stone is CEO and co-founder of TransformativeMed, the Best-in- KLAS® leader in Clinician Digital Workflow solutions for Oracle Health EHR systems.
TransformativeMed | The Intelligent Care Platform Built by Clinicians for Clinicians
Best in KLAS® Clinician Digital Workflow 2026 | 100+ Hospitals | 100% Buy-Again Rate
