ST3WARD - Antimicrobial Stewardship Agent

AI stewardship consultant that asks before it recommends. Any hospital uploads their local guidelines and gets an agent that optimizes antibiotic therapy with their evidence. Built solo by a physician

Comment

Inspiration

I'm an infectious-disease specialist, and big part of my job is antimicrobial stewardship. The decision — should this patient stay on piperacillin-tazobactam IV or step down to oral amoxicillin? — is the high-value clinical work. But getting to that decision means hours of mechanical assembly: pulling the EHR, scanning culture and susceptibility reports, cross-referencing the allergy list, comparing against the local antibiogram, checking institutional guidelines, calculating duration from day of source control… every day, for every patient on the consult list.

Stewardship is intensely local. A guideline from another continent — or even another city — can be flat-out wrong, because the resistance profile of E. coli in Madrid is not the resistance profile in San Francisco. Generic LLM medical knowledge collapses against that reality.

ST3WARD was born from a simple idea: take the mechanical assembly off the clinician, ground the reasoning in the hospital's own guidelines and antibiogram, and let the human spend their time on the decision that actually moves outcomes.

What it does

ST3WARD is an antimicrobial stewardship copilot delivered as a multi-agent A2A system:

• st3ward — the stewardship reasoner. Reviews active antimicrobial therapy and produces structured recommendations for de-escalation, IV-to-oral switch, duration optimization, microbiology interpretation, and beta-lactam allergy/cross-reactivity assessment.

• healthcare_fhir_agent — pulls live patient context from a FHIR R4 server (demographics, active meds, conditions, observations, microbiology, allergies).

• general_agent — datetime + ICD-10-CM lookup utilities, no PHI.

• orchestrator — routes the conversation across the three specialists in-process via ADK's AgentTool.

The agent refuses to guess. If FHIR data is missing (no susceptibility report, no allergy history), it explicitly asks for it before recommending dosing. Every recommendation is cited against the institutional guideline document and the local antibiogram, so the antibiotic stewardship committee can audit why it suggested what it suggested.

It ships with our local antibiogram and 10 institutional guideline documents (CAP, UTI, SSTI, gram-positive and gram-negative bacteremia, candidemia, IV-to-PO switch, recommended durations…) in English and Spanish — drop-in replaceable for any hospital that wants their own.

It plugs into Prompt Opinion so any clinician using the platform can have a stewardship consult on demand, with the patient's actual FHIR record already in scope.

How we built it

• Google ADK + Gemini for the agent loop and tool calling.

• A2A protocol (Agent-to-Agent JSON-RPC) over Starlette/uvicorn — each of the four agents is a standalone A2A service with its own agent card on /.well-known/agent-card.json.

• FHIR credentials never enter the LLM prompt. They travel in params.message.metadata under a workspace-scoped extension URI declared in the agent card. A before_model_callback hook intercepts them, stashes them in ADK session state, and tools read them at call time. The model sees clinical text only.

• Local-guideline grounding: institutional guidelines and the antibiogram are loaded as a markdown corpus that the agent quotes by section name (e.g. "per Respiratory Infections, section 3"), so every recommendation is traceable to an editable document — no fine-tuning, no opaque weights.

• shared/ library (middleware, FHIR hook, FHIR tools, app factory) so all four agents share infrastructure and each agent's own code stays focused on its domain.

• One-command local demo: honcho start boots all four agents on ports 8001–8004; an ngrok tunnel makes the stewardship endpoint reachable by Prompt Opinion's cloud platform; an idempotent PowerShell launcher (start-demo.ps1) wires it end-to-end.

• One-Dockerfile-many-services deployment to Google Cloud Run via the AGENT_MODULE env var, with the Google API key stored in Secret Manager.

Challenges we ran into

• Designing the FHIR handoff so tokens and FHIR server URLs never reach the model context. The A2A metadata + before_model_callback + session-state pattern was the right answer, but getting middleware to bridge metadata from outer envelope into params.metadata cleanly took several iterations.

• Local grounding minimizing hallucination. Giving Gemini the guideline corpus is easy; making it cite the right section and refuse to extrapolate beyond what the local document says is the hard part. We leaned heavily on the system prompt and on forcing the model to ask for missing data instead of inventing it.

• Multi-agent boundaries. The orchestrator wanted to "help" by answering questions itself instead of delegating. Tightening the instruction so it routes to st3ward for therapy questions and to healthcare_fhir_agent for chart questions was a lot of prompt-engineering judgement.

• Agent-card URL synchronization across local dev, ngrok tunnels, and Cloud Run — each environment needs the card to advertise the URL the caller can actually reach.

Accomplishments that we're proud of

• End-to-end live demo working through Prompt Opinion. A real clinical case — Carmen Martínez, 72, hospitalized for CAP due to S. pneumoniae susceptible to penicillin — produced a structured recommendation to step down piperacillin-tazobactam IV to amoxicillin 1 g PO every 8 hours, citing the Respiratory Infections section of the local guidelines and the Jerez antibiogram, with explicit follow-up notes on confirming penicillin allergy.

• Credentials-in-metadata pattern is clean enough that we promoted it into a reusable shared/fhir_hook.py that any future healthcare agent can adopt with one import.

• Bilingual local-guideline corpus (10 documents × EN/ES) plus 4 synthetic FHIR patients covering the most common stewardship scenarios (de-escalation CAP, preliminary pyelonephritis, cellulitis MSSA with allergy, mild CAP appropriate therapy) — enough to run a credible clinical demo without ever touching real PHI.

• Four agents, one Dockerfile, one launcher — the operational story is genuinely simple.

• The agent says "I don't know". Watching it refuse to recommend dosing when the allergy history was missing felt like the single most clinically responsible thing we built.

What we learned

• The LLM is not the hard part. The plumbing — FHIR auth, session state, A2A metadata routing, secret handling — is where production-grade healthcare agents are made or broken.

• A2A's metadata channel is the right place for context that must not enter the prompt: PHI, bearer tokens, FHIR endpoints. Designing around it from day one is much cleaner than retrofitting redaction later.

• Regional grounding > generic medical knowledge. Same organism, different city, different first-line antibiotic. A stewardship agent without local data is a confident liability.

• Forcing the agent to ask for missing data is more clinically useful — and more trusted by clinicians — than letting it guess plausibly.

• Multi-agent architecture pays off when the responsibilities are genuinely orthogonal (stewardship reasoning ≠ FHIR retrieval ≠ general utilities). When they aren't, it just adds latency.

What's next for ST3WARD - Antimicrobial Stewardship Agent

• Pilot at a real hospital with their own antibiogram, formulary, and guideline corpus — the swap is a config change, not a code change. That's the test that matters.

• More clinical skills: empirical therapy initiation, sepsis time-zero advisor, PK/PD dose adjustment for renal/hepatic impairment, automated IV-to-PO switch alerts triggered by FHIR observations (afebrile + tolerating oral + decreasing CRP).

• Outbreak surveillance agent that reads aggregate FHIR data against local antibiogram trends to flag emerging resistance early.

• Audit & explainability layer so antibiotic stewardship committees can review every recommendation the agent has made, with the exact guideline sections and FHIR facts that supported it — non-negotiable for clinical adoption.

• More languages for the guideline corpus: we already have EN + ES; next up PT, FR, AR.

• Integration with hospital pharmacy systems so recommendations land as orderable, formulary-aware suggestions, not free text.

• Prospective validation study vs. ID specialist recommendations — the only way to move from demo to standard of care.

• Production hardening: short-lived FHIR token rotation, fine-grained RBAC per skill, BAA-compliant deployment, and structured logging that satisfies hospital information-security review.

Built With

Share this project:

Updates