Inspiration
Getting a rare-disease diagnosis feels like it should be the end of the search. It's usually the start of a new one. About 25–30 million Americans live with a rare disease (NIH NHGRI). Diagnosis takes 4.7 years on average, and 1 in 4 patients sees 8 or more clinicians before getting one (EURORDIS Rare Barometer, Europe). 95% of rare diseases have no FDA-approved treatment (Global Genes).
Tools that tell you who the expert is already exist. The hard part comes after that: finding the right inbox, phone line or application form, writing the message, following up when nobody answers, and keeping track of what each office asked for. We wanted to build something that does that work for the patient, persistently, without ever acting behind their back.
What it does
Orelia turns a diagnosis into appointments.
- Intake. The patient uploads a report and Orelia fills in the intake answers from it.
- Research swarm. 12 Claude research agents search for specialists, clinics, trials, advocacy groups and financial or travel aid.
- Validation. Every claim needs a source URL, or it's dropped.
- Needs analyst + judge. These build a ranked shortlist and show why each resource was kept, kept as a maybe, or dropped.
- Consent. The patient picks who to contact and ticks exactly which details may be shared.
- Contact plan. For each resource Orelia plans the best way in: email, a phone call, an online application, or email and then a call if nobody replies.
- Agent factory. When the plan is approved, Orelia spins up one persistent agent per resource. Each agent has its own goal, strategy and state:
- Email through AgentMail, on a per-agent thread
- Phone calls through Vapi, with the AI disclosure first and a live transcript in the console
- Online forms filled and submitted in a Kernel cloud browser, which judges can watch live
- Persistence. Agents wake on webhooks (replies, call results, form submissions) and on a cron that runs every minute, so they keep working after the browser is closed:
- A reply becomes a task, for example "Send records to …", with a drafted letter.
- A time the office proposes becomes an appointment for the patient to confirm.
- A reply cancels that agent's scheduled follow-up.
- Silence triggers the agent's own follow-up after a few business days. For an email-then-call plan, the agent switches to a call if nobody answers.
- Agent chat. Every agent is also a chat the patient can come back to later.
- Two views. The patient view shows just the next thing to do. The judge view shows how everything works underneath.
Safety is enforced in code, not just prompts. Every outbound message passes one gate. It checks the patient's approval before sending, the allowlist, ticked-fields-only sharing, the AI disclosure, a no-medical-advice screen, a cap of five contacts and follow-up cadence. Nothing goes out without the patient's OK.
In the demo video, the coordinator's email reply and the phone call are real. A real Gmail reply landed on the agent's thread, and the clinic's phone call happened live.
How we built it
- App: Next.js 16 (App Router), React 19, TypeScript and Tailwind v4, deployed on Vercel with a cron that runs every minute.
- Data: Neon Postgres through Drizzle. Cases, candidates, evidence, contact plans, resource agents, agent events and messages, tasks, appointments and Kernel live-view sessions all live here.
- Models (all Claude):
- Haiku 5.5 for the research swarm
- Sonnet 5.5 for the needs analyst and the per-resource agents
- Sonnet 5 inside Vapi for voice calls
- Opus 5.5 for judging and for classifying inbound replies
- Channels:
- AgentMail for email and inbound webhooks
- Vapi for outbound calls and call webhooks
- Kernel for cloud-browser form filling, with read-only live view embedded in the console
- Exa for web search, including detecting the "apply" links on aid-program pages
- Agent runtime: each agent decides with a code-computed set of allowed actions: wait, follow up, switch channel, answer a request, escalate or finish. The model only chooses among those actions. Leases and idempotent webhook ingestion keep agents from double-acting.
- Replies: a classifier turns inbound mail into one of seven task types. Appointment times are extracted deterministically with chrono-node and are never auto-confirmed.
- Testing: 5,100+ Vitest tests, plus an offline end-to-end demo with mock channels, so the whole pipeline runs without network access. Playwright handles browser checks.
Challenges we ran into
- Persistence is a state machine, not a loop. An agent has to react correctly to a reply, a call result, a form confirmation or simply time passing, and it must not double-send when a webhook and the cron fire together. We ended up computing allowed actions in code, with leases and idempotent ingestion, and letting the model choose only within those bounds.
- Safety without killing usefulness. Every channel (email, voice, web forms) goes through the same outbound gate, and a form submission has to respect the patient's consent field by field.
- Finding the actual door. Search results often stripped the links that lead to an aid program's application form, so the planner never offered "apply online". We had to keep page links from Exa and detect application, referral and intake forms ourselves.
- Showing the browser agent live. Kernel's live view only exists while a session runs, and the submit step wasn't tied to the agent that owned it. So the "Watch the agent" panel never appeared during submit until we scoped live views to each agent.
- Real-world messiness. Speech-to-text on calls mishears clinic names. Gmail replies have to thread back to the right agent. Research is nondeterministic. Every one of these shaped the design.
Accomplishments that we're proud of
- A real reply from a real inbox woke the right agent. It logged the proposed appointment for the patient to confirm, cancelled its own follow-up and asked the patient to approve sending records, with no human in the loop until the approval step.
- A live AI phone call that discloses it's an AI first, asks how to get seen and turns the answers into next steps.
- A patient view that stays calm and simple while a dozen agents work underneath it.
What we learned
- Agents are most trustworthy when the code decides what's allowed and the model decides what's best within that.
- "Persistent" really means good handling of webhooks, schedules and idempotency more than clever prompting.
- For patients, the best interface shows one next step. The complexity belongs in the judge view.
What's next for Orelia
- Real clinic directories and verified contact points at scale
- Insurance and referral workflows, such as tracking a referral from the patient's own doctor
- Shared access for caregivers
- A pilot with patient advocacy organizations
Synthetic data only. Orelia never gives medical advice.
Built With
- agentmail
- anthropic
- chrono-node
- claude
- drizzle-orm
- elevenlabs
- exa
- kernel
- neon
- next.js
- playwright
- postgresql
- react
- tailwindcss
- twilio
- typescript
- vapi
- vercel
- vitest
- zod
Log in or sign up for Devpost to join the conversation.