meridian

Inspiration Anyone who's had to call a hospital, sit through a phone tree, and explain their symptoms twice before reaching the right department knows how broken hospital intake is. That first-contact triage step — figuring out where a patient belongs and how urgently — is exactly the kind of judgment-plus-lookup task agentic AI is well suited for, which made it a natural fit for this hackathon's focus on agents that do real work for people rather than just answer questions. AWS's own published examples of Strands agents automating healthcare admin work (like prior-authorization review) and open-source multi-agent ER triage projects confirmed this pattern was worth building on, rather than starting from a blank page.

What it does

Meridian is a digital front desk for a simulated large hospital. A patient describes what's wrong, and the agent checks the hospital's department directory, pulls up their patient record if they're known, and reasons over the complaint itself to decide if it's an emergency. If it is, it escalates straight to the ER with the specific red flag it caught — no routine queue, no delay. If it isn't, it classifies the complaint into urgent, soon, or routine (each with a plain-language rationale), finds an available doctor in the right department, and books a real appointment. It never diagnoses or prescribes — it only routes, triages, and escalates, which is exactly what a front desk does.

How I built it

I used the Strands Agents SDK in TypeScript, with the whole system — hospital directory, patient records, tools, system prompt, and run loop — living in a single src/agent.ts file so anyone reviewing the project has one place to look. Seven tools handle directory lookup, patient lookup, urgency assessment, doctor matching, booking, and ER escalation. The urgency tier (urgent/soon/routine) is a deterministic keyword match against the hospital's own flag lists, so it's consistent and auditable rather than a model guess. Emergency detection is different on purpose: it stays inside the model's own reasoning rather than a keyword tool, because a hospital's highest-stakes decision shouldn't ride on exact string matching. I also built a load-test script that fires several simulated patients at the agent at once, each getting its own agent instance, to prove it holds up under concurrent use. The model runs on AWS Bedrock (Claude), reached through Bedrock's standard AWS credential chain.

Challenges I ran into

The biggest one was realizing that a keyword-based emergency check would miss real paraphrases — it would catch "chest pain with shortness of breath" but miss "chest pain and can't breathe," which is the same emergency in different words. That's what pushed me to keep ER escalation inside the model's semantic judgment instead of a brittle string match. I also hit a real concurrency bug: a single Strands Agent instance can only process one invocation at a time, so my first load test failed on every client after the first. I fixed it with a factory function that gives each simulated patient their own agent instance. On the infrastructure side, I started on Google Gemini's free tier and discovered its daily quota (20 requests/day, enforced at the account level, not per-project) made it unworkable for real testing, so I migrated the whole project to AWS Bedrock mid-build. Along the way I also caught and fixed a cross-platform bug in my own entry-point detection that silently broke the app on Windows.

Accomplishments that I'm proud of

I'm proud that I caught the emergency-detection near-miss before it shipped, not after — that's exactly the kind of gap that matters most in a healthcare-adjacent tool, and I treated it as a design decision (documented in my architecture doc) rather than a bug to patch over. I'm also proud of proving the agent handles multiple simultaneous patients correctly, since a front desk that can only talk to one person at a time isn't a realistic front desk. And I'm proud I didn't let infrastructure problems become excuses when Gemini's quota turned out to be a dead end, I migrated the entire model layer to Bedrock under real time pressure without breaking any of the agent's core logic.

What I learned

The clearest lesson was that safety-critical decisions shouldn't sit on brittle string matching, even when a keyword tool feels like the simpler, more "deterministic" choice — sometimes the model's own judgment is the safer option. I also learned, the hard way, that free-tier API quotas can be enforced in surprising places (account-level, not project-level, in Gemini's case), which is worth knowing before betting a demo on one. And I picked up a genuinely useful cross-platform lesson: import.meta.url and process.argv[1] don't compare cleanly on Windows without normalizing through fileURLToPath, which is an easy silent failure to ship without noticing.

What's next for Meridian

Near-term, I'd expand the simulated hospital data (more departments, doctors, and patient histories) and connect appointment booking to a real calendar/scheduling API instead of a JSON file, so the "real entry" it writes is actually useful. Longer-term, the architecture is designed to point at real systems without changing shape — an actual EHR reached through Bedrock AgentCore Gateway in place of my simulated patient records, and a real scheduling system in place of appointments.json. I'd also deploy the agent itself to Amazon Bedrock AgentCore for a live, hosted demo rather than a local run.

Built With

• aws-region)-from-.env-a-plain-json-file-(appointments.json)-as-the-simulated-hospital-record-store
• aws-secret-access-key
• no-build-step-needed-for-dev-dotenv-?-loads-aws-credentials-(aws-access-key-id
• running-claude-(global.anthropic.claude-sonnet-4-6)-via-bedrockmodel-zod-?-schema-validation-for-every-tool's-input-node.js-(22+)-with-tsx-for-running-typescript-directly
• strands-agents-sdk-(typescript)-?-the-core-agent-framework
• using-its-agent-class-and-tool()-factory-aws-bedrock-?-the-model-provider