Dashboard
Shift Allocation Agent
Autonomous activities gracefully handled by the fleet of agents
Today's operations - state of the hospital as monitored by the agents fleet
Inventory management actively monitored by the Inventory Management Agent
HR Agent - Includes approvals which are sent to the human manager for critical purchases before proceeding
HR Agent contd.
Agentic system architecture
Deployment architecture
Security Architecture

Prudently

The fleet that never waits to be asked. It doesn't wait for an emergency to find out if it's ready for one, either.

Prudently architecture: a root coordinator, a security gateway every internal call passes through, eight specialist agents, one external hop, and a real-time fleet watch

Inspiration

Hospitals rarely fail all at once. They fail one missed signal at a time: a nurse working past the point it's safe to keep going because nobody tracked the hours, a supply room running low because nobody was watching the shelf, a credential that lapsed because nobody cross-checked it against the calendar, two schedulers double-booking the same operating room because their systems don't talk to each other. None of it trips an alarm. Each one stays invisible until it becomes a patient-safety incident, and by then it's too late to have caught it early.

The people whose job it is to catch these things are already stretched thin. One more dashboard to remember to check doesn't fix that; it's one more thing to forget. What a hospital needs is something always watching, connecting signals across departments no single team sees together, that only interrupts a person when a decision genuinely needs one.

That's the gap Prudently closes: not a chatbot waiting for a question, but a fleet of specialist AI agents, one per operational area, reading a hospital's live data around the clock and acting the instant something crosses a line. Think of it as a veteran charge nurse who could somehow be in every ward at once.

We also pushed on a harder question most hospitals never get to test in advance: not "are we fine right now," but "if a mass-casualty surge or a power outage hit tonight, would we survive it?" Most hospitals only learn the answer during the emergency itself. Prudently checks that answer continuously, quietly, long before it's needed.

What it does

Eight specialist agents, each reading the same live hospital data, each deployed independently with its own identity. No two agents share a point of failure, or a set of permissions.

The specialists

Coordinator is the only agent a person talks to directly. It never acts on its own: it routes each request to the right specialist, through a security checkpoint first.
Shift Allocation tracks every clinician's hours against a safe limit for their role, and flags or reassigns anyone drifting into unsafe fatigue before it becomes a mistake on the floor.
Inventory Management watches every tracked item's stock level against its reorder point, factoring in actual usage rate, not a fixed shelf count.
Supply Chain Resiliency decides what to do about a shortage Inventory flags: which vendor to use, how urgent it is, and drafts the purchase order itself.
HR tracks every credential's expiration date, and finds a qualified per-diem substitute when Shift Allocation runs out of people to reassign.
Chaos & Continuity is the resilience specialist, and the piece we're proudest of. It knows 24 hospital emergency scenarios: mass-casualty surges, outbreaks, power and water outages, staff walkouts, cyberattacks, and more. Every monitoring cycle, on its own, it re-checks all 24 against live staffing and stock levels. If readiness quietly slips from fine to not ready, it raises the alert unprompted, like a fire marshal checking the exits without being asked.
Surgical Scheduling checks every operating-room booking for conflicts, and keeps patient data encrypted at rest, readable only by the two roles that need it.
Medical Representative is the one specialist that talks to the outside world, over a genuine agent-to-agent connection to its own separately hosted service, not a shortcut inside the same process. Every inbound vendor message is screened twice before a model ever reads it. In testing, the second pass caught something the first one missed.

Always watching, not just answering questions A watch that never sleeps, on its own schedule, re-reads the hospital's live state and compares it to what it saw last time. It only speaks up when something got worse: stock crossing critical, a unit's fatigue risk climbing, a credential expiring, a scheduling conflict, or a disaster-readiness gap opening. Nothing gets flagged twice for the same unchanged problem.

Autonomous, but never unsupervised Every action with a real-world consequence, contacting a vendor, notifying staff, reordering stock, waits for a human approval first. An email lands with an approve or reject link, and nothing happens until someone says yes. The fleet decides when to raise something, never that it's earned the authority to act unsupervised.

Built to survive being looked at, not just demoed Every agent runs under its own cloud identity, individually reviewable and revocable. Patient data is encrypted at the field level, decryptable only by the roles that need it. Every action the fleet takes, successful or not, is written to a timestamped record, alongside a live trace of exactly which agents and services a request touched, in order, as it happens.

Prudently security architecture: every control mapped to the specific data or action it protects

How we built it

Eight agents, each an independently deployed AI agent runtime on Google Cloud with its own identity, orchestrated with Google's Agent Development Kit. Backend and dashboard both run on Cloud Run, backed by Firestore, the same live database every agent and dashboard panel reads from directly. There's no separate demo-data layer. The one agent that talks to the outside world does so over an agent-to-agent hop to its own hosted service, screened both in and out by a dedicated prompt-injection defense. Patient-identity fields are encrypted with a cloud key-management service before they're ever written.

One of the most satisfying fixes came from refusing our own earlier conclusion. We'd written down that per-agent identity wasn't possible, because the CLI tool we were using didn't expose that option. It turned out the tool was the limitation, not the platform: reading what that tool actually sends to Google's API surfaced a working config the flag never exposed. All eight agents went from sharing one identity to each carrying its own, individually revocable.

We also route every autonomous, unprompted agent turn through the same in-process path the fleet already uses for a person-initiated question, rather than a remote call to the deployed runtime. In testing, that remote path reset mid-response more often than it completed. A silently failing autonomous action is a worse outcome than a little infrastructure elegance, so we chose the path that works every time.

Major technologies used

Service / model	Purpose
Vertex AI Agent Engine	Hosts all 8 reasoning engines
Vertex AI Memory Bank	Per-agent scoped long-term memory
Gemini	Agent reasoning, tool calls
Agent Development Kit (ADK)	Multi-agent orchestration framework
Cloud Run	API + dashboard hosting
Firestore	Live fleet state, single source of truth
Model Armor	Prompt-injection screening, inbound vendor messages
Cloud Trace	Distributed tracing, per agent turn
Cloud Logging	Structured audit log
Pub/Sub	Async messaging
Cloud KMS	Field-level PII encryption
Firebase Auth	Manager sign-in
Agent2Agent (A2A) Protocol	Cross-service hop to Medical Representative
Flow (with Veo)	Submission video, clip generation

Prudently deployment architecture: every deployed piece and every connection between them

By the numbers

8 independently deployed specialist agents, 1 agent-to-agent connection to the outside world, 0 simulated ones
24 distinct hospital emergency scenarios re-checked against live data every monitoring cycle, not just on request
5 conditions the fleet watches for and acts on unprompted: stock shortages, staff fatigue, expired credentials, scheduling conflicts, disaster-readiness gaps
5 categories of consequential action, each held behind a human approval
213 automated tests, all passing, 9.98/10 static-analysis score across the backend
8 separate cloud identities, one per agent, each independently revocable

Challenges we ran into

A deployment could report success while still quietly serving an old, broken version for a short window after.
A single misconfigured region setting for the fleet's shared memory store silently broke the entire autonomy pipeline, no error visible anywhere.
A record-keying bug meant weeks of a clinician's fatigue history were overwriting each other into a single day's data.
A depletion-rate bug applied a full day's inventory usage on every short cycle. Every tracked item hit critical stock in about five minutes, and 26 reorder emails went out before anyone caught it.
A login security fix accidentally locked out every signed-in user, including us. A user reported it before we found it ourselves.

Accomplishments we're proud of

A genuine agent-to-agent hop for vendor communications: a real network call to a separately deployed service, screened on both sides, not a same-process function call wearing an "agent-to-agent" label.
Eight agents, each with its own cloud identity and its own scoped memory, with every internal call routed through a single security gateway that checks who's allowed to talk to whom. Real per-agent isolation, not a shared trust boundary.
Two independent, sequential security screening passes standing between any inbound message and the model that reads it: real defense in depth against manipulation attempts, not a single point of failure.
Patient-identity fields (name, date of birth, contact information) encrypted at the field level with cloud-managed keys, decryptable only by the two roles that actually need to see them.
A disaster-readiness engine that continuously re-checks 24 emergency scenarios against live hospital data, not just on request, and caught an already-developing oxygen-supply shortage the first time it ran against real data.

What we learned

Autonomy and authority are different problems, and conflating them is the real risk. We didn't try to make a model trustworthy enough to act alone; we split "decide when to raise something" from "decide whether it happens," and let the AI own the first while a person always owns the second. That boundary, not the model's judgment, is what makes the fleet safe to run unattended.
Multi-agent systems are a security problem before they're a coordination problem. Once agents can call each other, the real design question is who's allowed to call whom, and whether you can prove it afterward. We built the security gateway before we finished inter-agent coordination, because retrofitting authorization onto working agent-to-agent calls is much harder than designing for it up front.
Shared memory between agents isn't a convenience, it's a correctness risk. An agent that can read another specialist's memory can also reason from assumptions it was never meant to have. Giving every agent its own scoped memory store wasn't just isolation, it constrained what each agent could even get wrong.
Reacting to change, not to state, is what makes autonomy trustworthy at scale. An agent that only speaks up when something is genuinely different can run unattended indefinitely without becoming noise a person tunes out. That property matters more in production than it does in a demo.

What's next

A sixth watch axis for vendor reliability degrading over time, tracked across purchase-order history rather than caught only after one bad delivery.
Contact information and integrations that connect to something other than synthetic hospital data.
A safeguard so the watch can't double-fire if it's ever run across more than one server at once.
Finer-grained, resource-level permissions for patient data, instead of one application-level access check. Worth doing right within a hackathon week, not just fast.