When OpenClaw Meets Hospital: Toward an Agentic Operating System for Dynamic Clinical Workflows

This paper proposes an architecture for an "Agentic Operating System for Hospital" that adapts the OpenClaw framework to safely deploy LLM agents in clinical environments by integrating a restricted execution environment, document-centric interactions, page-indexed long-term memory, and a curated medical skills library to ensure reliability, security, and auditability in dynamic workflows.

The Gist

Imagine a hospital as a bustling, high-stakes city. In this city, doctors, nurses, and patients are constantly exchanging information, but they are currently stuck using a very old, rigid map system.

The Problem: The "Scripted City"
Right now, hospital computer systems work like a train on a fixed track. They are great at doing the routine things: checking a patient in, ordering a standard blood test, or scheduling a follow-up. But what happens when a patient has a rare combination of illnesses, or a new drug interacts strangely with an old one? The train hits a wall. The system can't leave the tracks. It can't say, "Hey, let's look at this patient's history from three years ago and combine it with today's lab results to solve this unique puzzle."

Furthermore, trying to give a super-smart AI (a Large Language Model) full control over a hospital is like handing a toddler the keys to a nuclear power plant. If the AI gets confused or hallucinates, it could accidentally delete a patient's record or call the wrong emergency number. We can't trust the AI to "behave" on its own; we need to build a cage that makes it impossible for it to do anything dangerous.

The Solution: The "Agentic Operating System"
This paper proposes building a new kind of "Operating System" for hospitals, inspired by a project called OpenClaw. Think of this not as a new app, but as the foundation of the building itself.

Here is how it works, using simple analogies:

1. The "Restricted Apartment" (Safety First)

Imagine every doctor, nurse, and patient gets their own private apartment in a massive building.

• The Rule: You can only touch the furniture inside your own apartment. You cannot walk into the neighbor's room, you cannot break the windows, and you cannot call anyone outside unless you use the specific, pre-approved phone in your kitchen.
• In the Hospital: The AI agents (the digital helpers) are locked in these "apartments." They can only read and write specific files (documents) they are allowed to see. They cannot access the internet, run random code, or delete files they shouldn't. If the AI tries to do something bad, the "building manager" (the Linux operating system) physically stops it before it happens. It doesn't rely on the AI being "good"; it relies on the locks being unbreakable.

2. The "Skill Library" (The Toolbox)

Instead of letting the AI invent new ways to do things on the fly (which is risky), we give it a pre-approved toolbox.

• The Analogy: Imagine a chef who can only use the knives and pans that have been inspected and approved by the health department. They can't just grab a random screwdriver from the garage to cook.
• In the Hospital: The AI has a library of "skills" like "Check Blood Pressure," "Summarize Lab Results," or "Book an Appointment." These skills are pre-tested. The AI can mix and match them to solve new problems, but it can't invent a new, dangerous tool.

3. The "Paper Trail" (Communication)

In most computer systems, agents talk to each other by sending instant messages. In this new system, nobody talks directly.

• The Analogy: Imagine a busy office where no one speaks. Instead, everyone leaves sticky notes on a shared bulletin board. If the Nurse needs to tell the Doctor something, she writes a note on the "Patient Chart" board. The Doctor sees the note, reads it, and writes a reply on the same board.
• In the Hospital: All communication happens by writing to shared documents. This creates a perfect, unchangeable history of everything that happened. If you want to know who said what and when, you just look at the "sticky notes." It's impossible to hide a conversation or delete a message without leaving a trace.

4. The "Table of Contents" (Smart Memory)

Current AI systems try to remember everything by turning documents into math (vectors). This is like trying to find a specific sentence in a library by guessing which book it might be in based on a vague feeling. It often gets it wrong.

• The Analogy: This new system is like a human librarian. Instead of guessing, the librarian looks at the Table of Contents (called a "Manifest").
  • Step 1: The AI asks, "I need to find a patient's heart history."
  • Step 2: It looks at the main Table of Contents and sees a folder called "2023-2024 Heart Records."
  • Step 3: It opens that folder and sees a sub-table of contents for "January."
  • Step 4: It keeps drilling down until it finds the exact page.
• Why it's better: The AI uses its own reading skills to navigate the Table of Contents. It doesn't need complex math to find things; it just reads the descriptions, just like a human doctor flipping through a paper chart. This means the memory is always accurate, organized, and easy to understand.

The Big Picture: Why This Matters

This system allows the hospital to handle the "Long Tail" of medicine—the weird, rare, and complex cases that standard software can't handle.

• Before: A doctor encounters a rare drug interaction. The computer says, "I don't have a protocol for this." The doctor has to do everything manually.
• After: The doctor asks the AI Agent. The Agent looks at the "Table of Contents" of the patient's 10-year history, uses its "Skill Library" to check drug interactions, and composes a new, custom plan on the spot. It does this safely, without ever leaving its "apartment" or breaking any rules.

In short: This paper proposes a hospital computer system that is safe by design (locked down like a prison), organized like a library (using tables of contents instead of math), and flexible like a human (able to solve new problems by combining old tools). It turns the AI from a risky wildcard into a reliable, auditable assistant.

Technical Summary

1. Problem Statement

The paper addresses the critical gap between the capabilities of Large Language Model (LLM) agents and the stringent requirements of hospital environments. While LLM agents show promise in automating clinical tasks, their deployment in healthcare is hindered by four structural limitations:

• Safety and Security Risks: Existing agent frameworks assume open computing environments with broad permissions (file system access, network calls, arbitrary code execution), which violate healthcare privacy regulations (e.g., HIPAA) and audit requirements.
• Inadequate Memory Architectures: Current Retrieval-Augmented Generation (RAG) systems rely on flat vector embeddings that fragment patient histories. This destroys the longitudinal, hierarchical structure of clinical records (e.g., admission notes vs. discharge summaries), leading to unreliable recall and loss of temporal context.
• Lack of Multi-Participant Coordination: Most agent architectures assume a single user-model dialogue. Hospitals, however, involve multiple roles (physicians, nurses, patients) exchanging information via structured documents rather than continuous conversation.
• Inflexibility of Hospital IT: Existing Hospital Information Systems (HIS) and Electronic Health Records (EHR) rely on fixed, pre-programmed workflows. They fail to address the "long tail" of clinical variability where unique patient comorbidities or novel situations fall outside predefined protocols.

2. Methodology: The Agentic Operating System for Hospital

The authors propose a new infrastructure layer termed the Agentic Operating System for Hospital, built upon the open-source OpenClaw framework but heavily modified for clinical safety. The architecture is grounded in the principle of least-privilege execution and consists of four core components:

A. Restricted Execution Environment (OS-Level Isolation)

Instead of relying on the LLM to follow safety instructions, the system enforces safety at the operating system level.

• Linux-Based Isolation: Each agent (patient, clinician, triage) runs in an isolated namespace with a dedicated OS user account.
• Minimal Interface: Agents are restricted to only two primitive operations: reading and writing files.
• Prohibited Actions: Direct file system traversal, outbound network calls, dynamic code loading, and privilege escalation are blocked via kernel-level mechanisms (seccomp filters, AppArmor/SELinux policies).
• Trust Shift: Trust is enforced by the OS kernel rather than the model's instruction-following behavior.

B. Medical Skills Library

• Curated Capabilities: Agent capabilities are not generated dynamically but are drawn from a pre-audited, static library of "medical skills" (e.g., vital sign aggregation, medication adherence tracking).
• Typed Interfaces: Each skill has a strictly defined interface and can only access specific, pre-approved internal resources (e.g., a specific lab database) via narrow connectors.
• Ad-Hoc Composition: The agent can dynamically compose sequences of these skills to address novel clinical requests that no single pre-programmed workflow covers.

C. Document-Centric Multi-Agent Coordination

• No Direct Messaging: Agents do not communicate via direct channels. All interaction occurs through structured writes to shared clinical documents.
• Mutation Events: When an agent writes to a document, it triggers an append-only mutation event.
• Event Broker: A lightweight broker dispatches these events to subscribed agents. Agents react to changes (e.g., a patient agent writing a symptom log triggers a clinician agent to review it) based on version counters, ensuring causal ordering and auditability.

D. Page-Indexed Memory Architecture (Manifest-Guided Retrieval)

The paper rejects vector embeddings in favor of a hierarchical, human-readable memory system:

• Document Hierarchy: Patient records are organized as a rooted tree where internal nodes represent groups (e.g., "2023 Encounters") and leaf nodes are content pages.
• Manifest Files: Each internal node contains a manifest.md file listing its children with natural-language descriptions of their scope and content.
• Progressive Disclosure Retrieval: To answer a query, the agent navigates the tree by reading manifests. It uses its language reasoning to select relevant subtrees and prune irrelevant branches, descending only until it reaches the specific leaf pages needed.
• Incremental Maintenance: When a document is updated, only the affected manifest entry is regenerated via an LLM call, avoiding the need for re-indexing or vector recomputation.

3. Key Contributions

1. Infrastructure-First Design: Reframes LLM agent deployment in healthcare as an infrastructure problem rather than a model capability problem, prioritizing environmental constraints over model instructions.
2. OS-Native Safety: Demonstrates that reducing agent interfaces to file I/O allows the use of mature OS security primitives (user isolation, file permissions) to guarantee safety and auditability, eliminating the need for complex application-level sandboxes.
3. Manifest-Guided Memory: Introduces a vector-free memory architecture that preserves the longitudinal and hierarchical structure of clinical data, enabling interpretable retrieval traces and eliminating embedding overhead.
4. Document-Mutation Coordination: Proposes a coordination model where agents interact solely through shared document mutations, creating a tamper-evident, causal audit trail of all inter-agent communication.
5. Ad-Hoc Clinical Reasoning: Enables the system to handle the "long tail" of clinical variability by dynamically composing skills to address novel scenarios that fixed hospital workflows cannot.

4. Results and Clinical Scenarios

The paper validates the architecture through six detailed clinical workflow scenarios (illustrated in Figure 3), demonstrating that a single unified infrastructure can handle diverse needs:

• Continuous Monitoring: Automated aggregation of wearable data and generation of follow-up notes.
• Triage: Initial assessment and routing based on symptom history and prior records.
• Emergency Escalation: Immediate, priority-flagged alerts for critical physiological events, interrupting standard reasoning cycles.
• Medication Management: Closed-loop adherence tracking and dynamic care plan adjustments.
• Proactive Risk Identification: Longitudinal analysis across years of data to identify trends (e.g., declining renal function) and trigger preventive interventions.
• Cross-Specialty Coordination: Managing multimorbid patients by allowing multiple specialist agents to read/write to a shared care plan, detecting drug conflicts, and reconciling treatment plans.

5. Significance

This work represents a paradigm shift in Clinical AI deployment:

• From "Safe Models" to "Safe Systems": It argues that safety cannot be achieved solely by training safer models; it requires a controlled execution environment where unsafe behavior is structurally impossible.
• Auditability: By leveraging OS-level file auditing (e.g., auditd), the system provides a complete, tamper-evident record of every agent action, satisfying strict regulatory requirements without custom engineering.
• Interpretability: The manifest-guided retrieval process produces a human-readable trace of the agent's information gathering, unlike the "black box" nature of vector similarity searches.
• Scalability to Variability: It offers a solution to the rigidity of current hospital IT, allowing AI to adapt to unique, unscripted patient needs while maintaining the safety and structure required in healthcare.

In conclusion, the authors propose that the future of clinical AI lies not in more powerful models, but in Agentic Operating Systems that rigorously constrain agent behavior through OS-level isolation, document-centric coordination, and hierarchical memory management.