EIR: Healthcare Agent Fleet

• 

• 

• 

• 

Inspiration

Hospitals do not have a shortage of software. They have a coordination problem.

A patient may need to schedule an appointment, recover after a procedure, respond to a follow-up, or reach a clinician when something changes. At the same time, hospital teams are managing reviews, records, scheduling, inventory, and dozens of workflows that often live in separate systems.

We wanted to explore a different idea: what if a hospital could have a secure fleet of specialized agents that work together over time, instead of one chatbot trying to do everything?

That became EIR, the Healthcare Agent Fleet.

What it does

EIR is a multi-agent platform for hospital access, recovery, and operations.

Patients get their own portal where they can view appointments, search availability, book, reschedule or cancel visits, follow their recovery, and talk to EIR through a conversational interface.

Clinicians get a separate workspace with their schedule, patients, recovery escalations, and human review queue.

Operations teams get a command center for appointments, patients, observability, and the agent fleet itself.

Recovery is one of EIR's long-running workflows. A Recovery Episode can remain active for days or weeks. EIR schedules follow-ups, coordinates outreach, evaluates structured risk signals, tracks adherence, and escalates cases when a clinician needs to step in.

We also applied the same architecture to hospital supply operations. Replenishment cases can monitor stock, coordinate inventory and procurement agents, contact a synthetic supplier, draft purchase orders, and stop at a human approval boundary before anything can be authorized.

The important part is that these are not isolated demos. They share the same fleet infrastructure, security model, registry, observability, and human approval patterns.

The managed agent fleet

Our Patient Access Agent runs on Google's managed Agent Runtime using Gemini 3.5 Flash and Google ADK.

We use:

• Agent Runtime to execute the Patient Access agent
• Memory Bank for persistent context across sessions
• Agent Registry to register the managed agent and its approved services
• Agent Identity so the agent authenticates with its own least-privilege identity
• Agent Gateway in AGENT_TO_ANYWHERE mode with IAP enforcement
• Model Armor to inspect and protect agent traffic
• Google Cloud observability through Cloud Logging, Cloud Trace, and Cloud Monitoring

We verified Memory Bank across separate sessions. A synthetic patient can say that they prefer Main Clinic and afternoon appointments in one session, then start a completely new session later and EIR can retrieve that preference when searching for appointment options.

We also tested the security boundaries. Cross-patient access is rejected by backend authorization, and prompt injection attempts cannot bypass the gateway, Model Armor, or our application-level controls.

How we built it

The frontend is built with Next.js and TypeScript, with dedicated experiences for patients, clinicians, and hospital operations.

The backend uses FastAPI and Python. Healthcare scheduling is backed by a real FHIR R4 store in Google Cloud Healthcare API using Patient, Practitioner, HealthcareService, Schedule, Slot, and Appointment resources.

Firestore stores durable operational state such as recovery episodes, access sessions, reviews, and workflow data. Pub/Sub powers asynchronous workflows, and Cloud Scheduler resumes work that may happen days later.

The agent layer is built with Google ADK. Instead of hardcoding a chain of agents, EIR routes work through capabilities. Specialized agents handle patient access, scheduling, outreach, risk, adherence, records, escalation, inventory, and procurement.

Infrastructure is managed with Terraform, and GitHub Actions deploys to Google Cloud using Workload Identity Federation without a long-lived Google Cloud service account key.

The demo contains only synthetic data. It currently includes 12 patients, 6 practitioners, 5 healthcare services, 3 locations, more than 80 appointment slots, recovery cases, clinician reviews, and waitlist requests.

Safety was part of the architecture

Healthcare is not a place where an LLM should silently make every decision.

We deliberately separate conversation from authorization and execution.

The model can understand what someone is asking for, but deterministic services enforce patient ownership, appointment rules, and allowed actions.

Clinical risk can trigger a human review instead of an autonomous medical decision.

Purchasing agents can draft an order, but they cannot approve spending.

Model Armor and Agent Gateway provide managed defenses, while backend RBAC remains the final authorization boundary.

We do not claim HIPAA compliance, we do not use real patient data, and EIR does not autonomously diagnose patients.

Challenges

The hardest part was moving from a working agent demo to a real managed fleet.

Agent Runtime packaging, Memory Bank, Agent Identity, Agent Registry, and Agent Gateway each had different integration details. Some problems initially looked like service limitations but turned out to be implementation issues.

For example, Memory Bank is attached to the ReasoningEngine rather than being a standalone top-level resource. Agent Identity also required us to handle authenticated calls carefully because Cloud Run normally consumes the Authorization header itself.

Agent Gateway introduced another challenge. Once IAP enforcement was enabled, even Gemini's own outbound endpoints had to be registered correctly. We kept enforcement enabled and fixed the allowlist instead of disabling the gateway.

FHIR seeding also required care. Google Cloud Healthcare API does not treat pending resources inside a transaction bundle the same way a local fixture would, so we moved to deterministic PUT-based seeding with stable IDs.

Those problems made the project much stronger because they forced us to validate the actual production architecture instead of stopping at mocks.

What we learned

The biggest lesson was that useful agents need much more than a model.

Persistent memory matters. Identity matters. Authorization matters. Event-driven execution matters. Observability matters. Human approval matters.

We also learned that a fleet is much easier to extend when agents coordinate through capabilities instead of knowing about each other directly. That is what allowed us to add hospital supply workflows without rewriting the recovery state machine.

And perhaps most importantly, we learned that healthcare agents should know when not to act.

What's next

We want to keep expanding EIR as a reusable hospital operations layer.

The next steps are deeper integrations with real hospital systems, more operational workflows, stronger evaluation of long-running agent behavior, and additional communication channels.

We have also built the Voximplant and Gemini Live voice path so the same backend tools can eventually be reached through a phone call. The production voice architecture is in place, but we keep it clearly marked as unverified until the final paid live call succeeds.

Our goal is not to build another hospital chatbot.

It is to build an agent fleet that can safely coordinate work across the hospital while keeping people in control.

Built With

• agent-gateway
• agent-identity
• agent-registry
• agent-runtime
• cloud-healthcare-api
• cloud-monitoring
• cloud-run
• cloud-scheduler
• cloud-trace
• fastapi
• fhir
• firestore
• gemini
• google-adk
• google-cloud
• memory-bank
• model-armor
• next-js
• pub-sub
• python
• terraform
• typescript
• veo
• vertex-ai
• voximplant