Completion Loop sends Otto, an AI calling agent, to place a real outbound call and navigate the counterparty phone tree autonomously. Each call feeds a typed, confidence-scored Counterparty Graph, which deepens into a behavioral Genome per payer, and a Predictor that forecasts outcomes before the next dial. The call is how the graph is fed; the graph is the business.
The system
Five parts, one loop
Claude-powered Your infrastructure Telephony
The loop, in one sentence: you click Place the call → the Vapi agent (running on Claude) dials the counterparty's phone tree and navigates it → the live transcript streams back to your Flask app → Claude extraction turns each turn into structured facts → the Counterparty Graph grows on screen and gets more confident. Every call makes the next one smarter.
The flow
What happens when you place a call
1
You click "Place the call." The dashboard hits a server-side endpoint (/api/place_call) that holds the Vapi key. The key never touches the browser. The endpoint also pre-warms the IVR so there's no cold start.
2
Otto places a real outbound call from an imported Twilio number to the counterparty's line. Otto's brain is Claude; his transcriber is real-time speech-to-text.
3
Otto navigates the phone tree. He hears the menu, presses the right keys via DTMF tones, survives hold, and answers the verification prompts with the pre-staged identifiers, all autonomously.
4
Vapi streams the live transcript to the app's webhook, turn by turn, while the call is still in progress, not just at the end.
5
Extraction runs incrementally. Each turn is parsed into structured facts (menu path, verification policy, hold pattern, named agent, outcome), and the graph draws itself live on the dashboard.
6
The graph enriches. On completion, Claude does a full extraction pass, adds the claim as a new entity, and bumps the confidence and call-count on every entity it re-verified. The graph is now denser than before the call.
The stack
What it's built on
Otto (voice agent)
Vapi orchestrates the call; the reasoning model is Claude; real-time STT transcribes the counterparty. Native DTMF lets the agent press menu keys.
Telephony
Twilio carries the call. The counterparty IVR is a Flask-served TwiML phone tree, standing in for a payer line under full control.
Application
Flask + SQLAlchemy on Render. Serves the dashboard, the IVR, the call endpoint, and the Vapi webhook. Access-gated.
Extraction
Claude turns transcript turns into typed graph facts, with a deterministic parser as a fallback so the graph builds even if the LLM call fails.
Graph store
Typed nodes and edges with a JSON attrs field carrying facts, confidence, and call-count. Rendered live with vis-network.
Front end
A single dark dashboard that polls for live state at ~1s, streaming the transcript and drawing the graph incrementally as the call unfolds.
The moat, concretely
The Counterparty Graph data model
🔵 Typed entities
Every node has a kind, so the graph reads as an operational map, not a flowchart:
Payer, the org, with hold profile and best-call windows
IVR nodes, the menu tree and key paths
Department, claims, eligibility, benefits
Policy, what verification each payer requires
Rep, named, reachable agents and resolution rates
Claim / Outcome, the result of each call
📈 Confidence that compounds
Each entity carries calls and confidence in its attrs. Every completed call:
increments the call-count on re-verified entities
nudges confidence upward toward certainty
stamps freshness ("verified just now")
adds new entities (a claim, a newly-heard rep)
This is why the graph is defensible: a competitor can rent the same models, but not the accumulated history. The data is the moat.
Beyond facts, behavior
The Counterparty Genome
A flat graph remembers facts: "Meridian requires an NPI." The Genome goes a layer deeper and encodes behavior, how a payer denies, reverses, staffs, and stalls. Each payer becomes a fingerprint of confidence-scored traits drawn from real call evidence.
🧬 A behavioral fingerprint
Meridian Health, for example, is not a row in a table but a personality the graph has learned:
Denies modifier-25 on first pass 79% of the time
But reverses 80% of those on appeal
Hold time triples after 2pm ET
Best window: Tue-Thu, 7-9am
One rep (Dana) resolves; the night shift deflects
Each trait carries its own confidence and the evidence count behind it. This is a model of the counterparty, not a memory of it.
✦ Transfer learning to unseen payers
The genome's real power: a payer you have never called still gets a predicted genome.
Encode each known payer as a behavioral vector
For a new payer, take the early signals you do have
Find the nearest known payers by cosine similarity
Blend their genomes into a prediction, before the first dial
A payer with zero history inherits the hard-won knowledge of the ones it behaves like. The graph is useful on a counterparty it has never touched.
Why this is the deeper moat: anyone can log call outcomes. Encoding payer behavior densely enough to predict it, and to transfer that prediction to unseen payers, requires call volume no competitor can shortcut. The genome is the graph growing from a record into a model.
Foreknowledge, not labor
The Completion Predictor
Once the genome is dense enough, the graph can forecast a call's outcome before dialing. The product stops being "we make your calls" and becomes "we tell you which calls to make, which to skip, and which to fix first." The highest-value call is the one you never place.
🎯 A scored, forward-looking queue
Every claim gets a forecast, a confidence, a time-to-outcome, and a recommendation:
CALL, worth placing; likely to resolve
SKIP, already resolved; a call would waste time
FIX FIRST, will likely deny as-is; correct before dialing
Language stays forward-looking ("LIKELY APPROVE," "EXPECT PENDING") until a real call confirms it. Forecast before, fact after.
◈ Every forecast cites its source
The obvious question is "how does it know?" So each forecast shows its provenance:
The graph is fed by more than calls: portal syncs, remittance feeds, and the genome itself. Provenance turns the skeptical question into a demonstration of depth.
Predict, then confirm. When a real call does run, its outcome lands next to the forecast: "FORECAST DENIED, CONFIRMED." Right or wrong, the graph learns from the comparison. Over time, more claims can be resolved without a call at all, which is the point.
The system teaches itself
Self-Rewriting Playbooks
A playbook is the set of rules Otto follows for a payer: how to navigate, when to call, what to verify. The frontier move is that Otto rewrites his own playbook when the world changes. Payers change requirements constantly, and every biller gets caught flat-footed. Here, the first call to hit the change catches it, and every call after is already immune.
🧱 Otto hits a wall he was not scripted for
Mid-verification, the payer demands something new, for example a rendering-provider taxonomy code that no prior call required. A scripted agent fails here.
Otto instead recognizes the novel requirement, handles it on the call, and completes the verification, rather than dropping the call and escalating to a human.
✦ The discovery is written back as a rule
The moment Otto adapts, the system writes a new playbook rule: "Meridian now also requires the rendering provider's taxonomy code at verification."
Every future Otto pre-loads that rule and sails through the wall that stopped the first call. Competence compounds, and no human edited anything.
Why this is defensible. Automation that follows a fixed script degrades the moment a counterparty changes. A system that rewrites its own playbook gets stronger with every change it encounters, and the learning is shared across every customer calling that payer. The world changing is what makes the moat deeper, not shallower.
The payoff of the graph
The Appeal Engine
Filing appeals is not the innovation; every billing shop does it. The innovation is what decides the appeal. Traditional denial management runs on static rules. This runs on the Genome, so the decision to appeal, and the prediction that it will win, comes from real per-payer reversal behavior that only exists because the system makes the calls. A competitor can file appeals. They cannot know that Meridian reverses 80 percent of modifier-25 denials while Atlas reverses 31 percent, without the call volume.
🧬 Genome-driven, not rule-driven
The moment a claim denies, the engine consults the payer's genome, not a static template:
This payer reverses 80% of these; another reverses 31%, so we only fight what wins
Denials are ranked by recoverable value (reversal odds times dollars), a revenue pipeline, not a worklist
The decision happens on the call, not days later in a separate review queue
💰 The moat becomes revenue
Once the engine decides to fight, it generates the full packet, appeal letter, documentation, citation, and submission, and files it on the same call, with a confirmation number.
This is where the data moat pays in dollars. The graph is the defensible asset; the appeal engine is the proof it converts to recovered revenue no competitor can match.
Why this closes deals. "We check status faster" saves labor. "We recover dollars you were about to lose, and we know which ones are worth fighting for this payer" is a different, easier sale, and it unlocks percentage-of-recovery pricing. The reversal data sharpens with every appeal filed, so the moat compounds exactly where the revenue is.
Production considerations
Scaling & security
⚙️ How it scales
The demo is single-tenant on a small instance, but the shape scales cleanly:
Calls are stateless jobs; concurrency is a worker-pool question
The graph is per-counterparty, so it shards naturally by payer
Extraction is idempotent and deduped by call id
The webhook accepts live streaming, so latency is a poll interval, not a batch
🔒 Security posture
Built with the sensitivities of the domain in mind:
Secrets (Vapi, Claude keys) live server-side only, never in the browser
The dashboard is access-gated; the call endpoint holds the key server-side
Every call is a discrete, auditable job with a captured transcript
Human-gated actions and full audit trails are the natural next layer for a regulated buyer
Built as a personal project. No employer code, data, or credentials. Everything here runs on personal infrastructure and personal accounts, a working proof of the thesis, not a product built on anyone else's platform.