smart_toy Agentic AIhealth_and_safety Pharma / Healthcare

Coverage Check — Agent-to-Agent Prototype

A self-initiated concept prototype answering one question: is my medication covered, and what do I need to get it approved? An orchestrator agent delegates to two narrowly-scoped worker agents, reachable by voice or text, with the same orchestration exposed as a headless API for systems that have no interface of their own. Built to prototype agent-to-agent design, conversation/voice state, and headless-system experience rules against a real LLM API — not simulated.

3
specialized agents — one orchestrator holding all conversation state, two stateless workers each scoped to a single lookup, coordinated through real Claude API calls with a contract-matched demo-mode fallback so the prototype is reviewable without an API key.

Client

Self-Initiated Concept

My Role

End-to-end — architecture, agents, frontend, backend

Duration

1-week sprint

Platform

Web · Voice (Web Speech API)

Tech

FastAPI, Anthropic Claude API, Vanilla HTML/CSS/JS

One Assistant Can't Safely Do Two Jobs

Answering "is my medication covered, and what do I need to get it approved?" means two separate lookups — plan eligibility, then formulary and prior-authorization — usually siloed in different systems. My existing agentic work (an email-draft assistant, an embedded analytics assistant) was all human-to-single-agent. This prototype exists to prove the pattern this gap needs: real delegation between scoped agents, not one assistant doing everything.

dnsSiloed systems

Eligibility and formulary data live in separate systems of record — one assistant with broad access to both blurs an auditable boundary.

visibility_offOpaque delegation

Typical chatbot patterns hide whether one assistant or several actually produced an answer — trust requires seeing the handoff.

policyNo headless contract

Nothing in my portfolio defined retention, disclosure, and ownership rules for a system with no interface of its own.

mic_offText-only conversation

Prior conversational work stopped at chat — no shared state model across voice and text as input channels.

adjustMy Brief

Design and build a small, honest agent-to-agent system — one orchestrator, two scoped workers — reachable by voice or text, with the same orchestration exposed headlessly, and with real LLM API calls behind it rather than simulated copy.

The Split Is the Design Decision

For most of my case studies, the research phase is user interviews. Here, the equivalent rigor went into architecture: deciding what each agent is allowed to know, and defending why.

Two-Worker Split

Eligibility vs. Coverage agents

Each agent can do less, not more, than the whole task requires — scope is legible from each agent's own instructions.

Sequential, Not Parallel

Coverage depends on eligibility

Checking a formulary for an inactive member is meaningless — this dependency isn't one Anthropic's parallel pattern fits.

Orchestrator-Only State

Workers are stateless

Only the orchestrator holds conversation history and session state — one place to audit, one place to change.

Confidence Aggregation

Computed at synthesis

A low or partial result from either agent surfaces as a visible caveat, never silently upgraded.

User (voice / text) Orchestrator session state · delegation · synthesis 1 · delegates (stateless) returns structured result 2 · delegates (stateless) returns structured result Eligibility Agent Verifies plan + member status stateless · scoped Coverage & Prior-Auth Agent Looks up formulary tier + PA stateless · scoped Answer + provenance + confidence per-claim sources, spoken aloud if voice was used

Agent-to-agent architecture — orchestrator delegating sequentially to two stateless workers, then synthesizing; neither worker ever sees the other's output

From Architecture to Working Prototype

The process followed the same discipline as my other coded prototypes: think before code, define the contract before the interface, build the system before the screens.

account_tree01 — Architecture

  • Agent-to-agent diagram
  • Delegation rules
  • Stateless workers
  • Synthesis logic

description02 — Context Files

  • Orchestrator prompt
  • Worker prompts
  • I/O contracts
  • Scope boundaries

graphic_eq03 — Conversation State

  • Voice + text, shared state
  • Trace visibility
  • Low-confidence state
  • Error state

policy04 — Headless Rules

  • Retention
  • Disclosure
  • Ownership boundaries
  • API contract

code05 — Prototype

  • FastAPI backend
  • Real Claude API calls
  • Demo-mode fallback
  • Vanilla frontend

Context Files as a Real Deliverable

Each agent's behavior is governed by a markdown file — the actual system prompt sent to Claude in live mode, not documentation written after the fact. This is the direct answer to "markdown and context-file deliverables for agent consumption": the file a reviewer opens is the file the agent runs on.

1

orchestrator.md

Scope, delegation order, synthesis rules, output JSON contract, what it must never do.

2

eligibility-agent.md

Input/output contract, refuses out-of-scope questions, stateless by design.

3

coverage-agent.md

Formulary/PA scope only, never recommends clinical alternatives, structured output only.

terminalFrom orchestrator.md

Never forward one worker agent's raw output to the other worker agent. Each worker gets only what the orchestrator explicitly constructs for it. If confidence is medium or low, say so in the answer itself — do not present a hedge only in metadata the user never sees.

Conversation & Voice State

Voice and text share one state machine — voice isn't a thinner, separate interaction model. The difference is only the input method (speech-to-text) and one added output (text-to-speech on the final answer), which matters because a voice-only user can't visually scan a confidence badge — the spoken answer says the caveat explicitly.

listening mic active transcribed echoed back orchestrating parsing intent delegating (1 of 2) eligibility agent delegating (2 of 2) coverage agent synthesizing composing answer answer_ready spoken via TTS if voice input low_confidence caveat spoken, not suppressed error plain-language failure + human handoff

One shared state machine for voice and text — low-confidence and error states are visible outcomes, not hidden fallbacks

Headless System — Experience Rules

The same orchestration is exposed as POST /v1/coverage-check, with no UI of its own. Because nothing here is a screen, the "experience" is entirely in the contract — what's disclosed, what's retained, who owns what.

1

Retention

Member/plan IDs discarded post-request; results cached 15 minutes; transcripts retained 30 days, then deleted.

2

Disclosure

Every response carries ai_generated, not_medical_advice, and confidence — consumers must surface them.

3

Ownership

Payer systems own source data; the patient owns transcripts; workers never receive each other's output.

Orchestrator + Worker Agents Chat / Voice UI conversational trace + spoken answer Headless API Consumer pharmacy portal · call-center tool · no UI disclosure block required in every render: ai_generated · not_medical_advice · confidence Retention Disclosure Ownership boundaries

One orchestration layer, two consumers — the headless path is governed entirely by contract, not by a screen

Code — Real Agents, Real API, Honest Fallback

In live mode (ANTHROPIC_API_KEY set), each agent call is a real Anthropic API request using the markdown context files as system prompts. In demo mode, the identical contract is satisfied deterministically, so the same frontend, trace, and confidence logic work either way — a portfolio prototype that only runs with a live key attached isn't reviewable by someone who doesn't want to configure one.

1

FastAPI backend

Orchestrator + 2 workers, Anthropic SDK integration, headless endpoint, health check exposing current mode.

2

Vanilla frontend

No framework, no build step — Web Speech API for voice in/out, live trace rendering, confidence badges.

3

Demo ↔ live parity

Same JSON contract in both modes — reviewable without a key, upgradeable to live inference with one env var.

Competency → Evidence, Traceable

Requirement Where it's proven
Agent-to-agent flow Orchestrator class delegating to two independently-scoped workers, sequential dependency justified in architecture.md
Conversation state design Full state table (listening → … → answer_ready / low_confidence / error), rendered live in the UI trace
Voice / multimodal Web Speech API input + speech synthesis output, sharing one state machine with text
Markdown/context-file deliverables for agents orchestrator.md, eligibility-agent.md, coverage-agent.md — the real system prompts, not summaries of them
Headless system experience rules Retention / disclosure / ownership rules defined from scratch; POST /v1/coverage-check as the no-UI consumer contract
Prototyping against LLM APIs Real Anthropic SDK calls in live mode, contract-matched demo-mode fallback
Responsible AI UX patterns Per-claim provenance, confidence-as-UI-state, disclosure block on every response, honest error state

A Small, Honest Proof — Not a Production Claim

infoTransparency

This is a self-initiated prototype built to close a specific portfolio gap — not a shipped Pfizer feature. All member, plan, and drug data is synthetic. It's a two-agent, single-sequential-flow system, deliberately scoped small rather than claiming production-scale multi-agent expertise.

Agent Scope

Broad accessarrow_forwardNarrow scope

2 workers

each independently scoped and auditable

Delegation Visibility

Opaque thinkingarrow_forwardLive trace

100%

of delegation steps rendered in real time

LLM Integration

Simulatedarrow_forwardReal API calls

Live

Anthropic SDK, with contract-matched demo fallback

Headless Contract

Undefinedarrow_forwardExplicit rules

3

retention, disclosure, and ownership rules, defined from scratch

Scope boundaries are a design decision, not a technical default.The two-worker split wasn't the easy path — one agent with access to both datasets would have been simpler to build. It was the right path because it keeps each agent's behavior legible and auditable on its own, which matters more in a regulated domain than raw simplicity.
A headless system's UX is its contract.With no screen to design, retention, disclosure, and ownership rules are the entire experience. Writing them down explicitly, the way I'd annotate a screen, is what makes a headless system reviewable at all.