Case study
Odyssey AI
A nine-agent claims system where the agents explain findings and deterministic code decides facts.
- 9agents in the pipeline
- 1st placeHumana hackathon
What it is
When a health claim is denied, the member usually finds out through silence — and then spends a phone call learning what happened. Odyssey moves that explanation earlier. It reads a claim, works out what went wrong, decides whether it is fixable, and produces a plain-language account of what happened, who needs to act, and what the next step is.
When something genuinely needs a person, it hands the representative a case summary that was already assembled, so the call starts at the answer rather than at the beginning.
It was built for a Humana hackathon on a fully synthetic dataset — no real member data was involved — and it won first place.
The architecture
Agent graph
- ROI Gatebefore_agent_callback
A data-access check that runs before any member data is fetched: is this caller permitted to receive this information? Roughly twenty lines of Python. Not an agent, and deliberately not a model call.
- Dash-ManagerSequentialAgent
Orchestrator and state manager. Fans out to three independent workstreams.
- Claim Spine
The main path: what happened to this claim, and can it be fixed?
- Summarizer
Condenses the claim record into a working brief.
- Issue-Detector
Identifies the failure — missing prior authorization, modifier mismatch, coverage rule.
- ResearchersParallelAgent
Two agents investigate the identified issue concurrently against the deterministic tool layer.
- MediatorLoopAgent, max 2
Validation gate. Reconciles the researchers, and may reject and re-dispatch them — capped at two iterations, with a deterministic exhaustion path so the loop terminates by construction.
- Solvability-RouterBaseAgent, not an LLM
Reads a boolean the Mediator already produced and routes. Unit-testable, still visible in the trace.
- Error-Fixer
Fixable: produce the remedy and the member-facing explanation.
- Escalation-Flag
Not fixable: assemble a representative-ready case summary.
- Benefits-Navigator
Answers coverage and prior-authorization questions, citing the specific coverage rule it used.
- Compliance-Sentinel
Triages the operational and compliance flag queue by severity.
- deterministic code
- model agent
- orchestration
The decision I would defend hardest
Concurrency, and paying for reliability with latency
Two parallel researcher agents issuing three tool calls each produced six concurrent calls against Vertex AI. That is a perfectly reasonable thing to want and a reliable way to hit a rate limit mid-run — which, in a demo, means the pipeline dies in front of an audience.
I serialized those six calls. It cost about five seconds of end-to-end latency and it made the failure mode go away. For a system whose output a representative reads before picking up a phone, five seconds is not a currency anyone is counting; a run that dies halfway through is.
Notes on scope
Deliberate limits
- Synthetic data
- The entire dataset is synthetic. No real member information was used at any point.
- Not authentication
- The ROI Gate is a data-access check, not a login. There are no accounts, credentials, or sessions anywhere in the system — calling it auth would overstate what it is.
- Grounded, not generated
- Benefits answers cite a rule identifier. Compliance triage prioritises pre-written flags. Neither invents a number.
- Scope discipline
- Half the provided dataset belonged to a different problem. An early version of the architecture drifted into it; those features were cut before the build rather than defended afterwards.
What it is worth
The headline is that it uses nine agents. That is the least interesting thing about it. The part I would actually put in front of an engineer is the subtraction: an agent that was removed because a boolean already existed, a loop that was capped because it could otherwise run forever, and five seconds of latency traded away to stop a rate limiter from ending the run.