Inside the agent-driven platform behind Yeam
Yeam's denial-recovery product works alongside the EHR a practice already runs. Behind it sits a full agent-driven system we built ourselves: instead of burying every task behind a menu tree, it lets you ask. Here is how that system is put together, and why we shaped it around a small set of specialized agents instead of one large model doing everything.
The click-heavy problem
A traditional EHR buries every task behind a menu tree: find the patient, open the encounter, switch to the coding tab, jump to claims, pull up billing. Each screen is a separate mental context. The work a clinic actually wants (check this patient in, draft this SOAP note, tell me why this claim was denied) gets spread across a dozen views. The premise of an agent-first EHR is simple: you describe the outcome, and the system routes the request to whatever part of the app can produce it.
The shape of the system
Everything flows through one entry point. A Command Bar (the familiar Cmd-K palette) takes a natural-language request and hands it to an orchestrator. The orchestrator classifies intent and routes the task to one of five specialized agents. Each agent knows how to do a narrow set of jobs well, queries the live database for real data through function calling, and streams its answer back into a persistent chat panel.
| Agent | Handles |
|---|---|
| Front Desk | Check-ins, scheduling, cancellations, patient lookup, insurance verification |
| Clinical Doc | SOAP notes, encounter documentation, ICD-10 and CPT coding |
| Claim Scrubber | Claim validation, code review, status checks |
| Billing | Denied claims, appeal letters, revenue cycle |
| Analytics | Live metrics (encounters, denial rate, revenue), trend analysis |
Intent, then tools, then a stream
When a request comes in, the orchestrator first decides what kind of task it is, then dispatches to the matching agent. That agent does not guess at data. It calls typed tools that run real database lookups (Gemini function calling on our side), gets structured results back, and only then composes a response. The reply streams token by token over server-sent events, so the chat panel fills in as the answer is produced rather than waiting for a complete block of text.
Splitting the work across narrow agents keeps each one's job small enough to be reliable. The billing agent only reasons about denials and appeals; the analytics agent only reasons about metrics it just pulled from the database. Narrow scope means fewer ways to be wrong.
Graceful degradation
A clinical tool cannot fall over when a model API is unavailable. If the generative model key is not set, the agents still run: they query the database and return a structured, factual stub instead of a generated narrative. The data path and the language path are separate, so losing the second one never takes down the first.
The stack, briefly
- Next.js 16 (App Router) with React 19 and TypeScript.
- PostgreSQL with Prisma as the ORM.
- tRPC with React Query for typed, end-to-end data access.
- Google Gemini for intent classification, tool calling, and generation.
- Tailwind CSS v4 for the interface.
None of this is exotic on its own. What makes it feel different is the ordering: the conversation is the primary surface, the click-through screens are the fallback, and every answer is grounded in a live database read rather than the model's memory.
Yeam deploys AI medical employees into clinics.
Reception, documentation, coding, and billing, handled by agents so staff can focus on patients.