For the AZcare team · From a BabbleLabs alum

Conversations are a cost.
Completions are the product.

You've built the right wedge: not inbound support, not robo-dial volume, but the operational calls businesses must make to get work done. This page is my product thesis for what compounds on top of that wedge, six concepts, built the way I'd run product at AZcare. I came to Cisco through the BabbleLabs acquisition; consider this my application, in the only format that matters.

The specific innovation

Teach an agent to beat the phone tree, then remember everything it learned

The major platforms are racing to turn your own meetings into work. None can reach the operational calls a business must place into other organizations' phone systems. That is the whitespace, and here is the wedge into it.

The hard part

An agent that navigates the counterparty's phone system

Not answering calls, placing them, into other organizations' IVR trees: pressing the right menus, surviving hold, passing verification, extracting the outcome. Operational work businesses do by the millions, entirely by phone, with no API and no transcript to mine.

The compounding part

Every call writes to a counterparty graph

Each completed call extracts structured knowledge and writes it back as a typed, confidence-scored graph. The next call starts smarter. The moat is not the calling; it is the accumulated map of the phone-based world that no competitor can buy.

The system · Where AZcare compounds

One graph. One loop. Six products.

Voice models are rented; everyone has them. What compounds is what only you can accumulate: the operational map of the phone-based world, and the loop that runs on it.

signals preempts & playbooks every completion enriches the graph, and gets sensed again context context context CONTEXT Counterparty Graph the map of the phone-based world SENSE Completion Pulse live workflow signals PREDICT Completion Predictor stall & SLA foresight ACT Protocol Bridge governed execution
Sense → Predict → Complete.
Why this compounds: the Graph makes every call smarter than the last. The Pulse senses workflows live; the Predictor turns signals into foresight; the Bridge executes with governance. Every completion enriches the Graph, and the loop closes. Competitors can copy the calling; they cannot copy the accumulated map. Click any box for its demo.
Concept 1 · The Counterparty Graph & Genome

Every call makes the next one smarter.

Illustrative mock · Pre-validation

The moment it shows

Before dialing, the agent already knows the counterparty: not just the IVR tree and verification requirements, but the payer's behavior, that it denies modifier-25 on first pass 79% of the time but reverses 80% on appeal, that its hold triples after 2pm. Every completed workflow writes this back. This behavioral model, the Genome, is the asset nobody else can accumulate.

What's underneath

  • Knowledge graph of organizations, departments, IVR trees (versioned, they change), verification requirements, outcome history
  • The Counterparty Genome: a behavioral fingerprint per payer, how it denies, reverses on appeal, staffs, and stalls, each trait confidence-scored from real evidence
  • Transfer learning: a payer you have never called inherits a predicted genome from its nearest behavioral neighbors, useful before the first dial
  • Freshness engine: detect when a phone tree changed and re-map on the next call

Discovery questions to validate

  • Which vertical's graph is densest value first: payers, banks, or government?
  • How fast do IVR maps decay, and what freshness SLA matters?
  • What can be shared across customers without leaking competitive info?
Counterparty Graph, Pre-Call Intelligence MOCK
🗺️
Grounded answer · from 1,847 prior workflows

Claim status requires member ID + provider NPI + TIN. Fastest path: menu 2 → 4, say "claims status" at the prompt. Average hold 14 min; best window Tue to Thu, 7 to 9am PT. If stalled past 20 min, the fax escalation path resolves in 1 business day.

📞 1,204 completed calls to this payer 🌲 IVR map · verified 3 days ago ⏱️ Hold model · updated hourly
Payer Main Line IVR v47 · mapped Menu 2 → 4 "claims status" Menu 3: Benefits not this task Verification Gate ID + NPI + TIN Fax Escalation fallback · 1 biz day fast path avoid
Every call makes the next one smarter.
Concept 2 · The Completion Predictor

Catch the stall before the first dial.

Illustrative mock · Pre-validation

The moment it shows

Monday 8am. Every queued claim is scored with a forward-looking forecast: LIKELY APPROVE, LIKELY DENY, EXPECT ALREADY PAID, each with a recommendation to CALL, SKIP, or FIX FIRST. The system preempts: it flags the claim that will deny for a missing modifier before you waste the call, and skips the one a remittance feed already shows as paid. The highest-value call is the one you never place.

What's underneath

  • Forecasts drawn from the Graph and Genome: denial patterns, appeal-reversal rates, payer behavior
  • Every forecast cites its source ("835 remittance feed · EOB posted 6 days ago", "312 modifier-25 claims · denial pattern"), so "how does it know?" is answered on screen
  • Forward-looking until confirmed: the language stays a forecast until a real call turns it into fact
  • Unlocks SLA-backed pricing, prediction becomes pricing power

Discovery questions to validate

  • What accuracy threshold changes customer behavior?
  • Do customers pay for prediction, or only completion?
  • Which SLA guarantees clear enterprise procurement?
Completion Predictor, Book of Work · 342 workflows in flight MOCK
Stall risk
Prior auth · WF #4821
0.00
Drivers: member DOB missing · payer closed Fri PM · 2 prior attempts hit verification gate
Time-to-outcome
Vendor payment confirm
0.0 days
Drivers: AP desk answers 10 to 11am only · requires invoice # + remit ID · callback loop likely
Batch SLA
220 employment verifications
0%
On track: 208 complete by Thursday · 12 flagged for preemptive document collection
08:02PreemptWF #4821, DOB request sent to requester before dialing · stall risk drops to 0.31 on receipt
08:02SchedulePayment confirm queued for 10:05am, the window this AP desk actually answers
08:03SLAVerification batch, 12 at-risk workflows rerouted to fax path · Thursday SLA holds
Stalled? We knew yesterday.
Concept 3 · Self-Rewriting Playbooks

The system teaches itself when the world changes.

Illustrative mock · Adaptive learning

The moment it shows

Mid-call, a payer demands something new, a rendering-provider taxonomy code no prior call required. A scripted agent fails here and escalates to a human. Otto instead recognizes the novel requirement, handles it on the call, and the system writes a new playbook rule on the spot: "Meridian now also requires the taxonomy code at verification." Every future call pre-loads it and sails through the wall that stopped the first one.

What's underneath

  • Otto adapts to unscripted requirements in the moment, rather than dropping the call
  • The discovery is written back as a durable rule, not lost when the call ends
  • The learning is shared across every customer calling that payer, one call teaches the fleet
  • Payers change requirements constantly; each change makes the moat deeper, not shallower

Discovery questions to validate

  • How often do payer requirements actually change in practice?
  • Will customers trust an agent that adapts without human review?
  • Is shared learning across customers a selling point or a privacy concern?
Why it is defensible

Automation breaks; a self-rewriting system compounds

Any competitor can wire an agent to a fixed script. That script degrades the instant a counterparty changes something. A system that rewrites its own playbook gets stronger with every change it encounters, and because the learning pools across customers, the density no one else can match is exactly what makes each call smarter. This is the difference between brittle RPA and a system that improves itself.

The line for the buyer: your team stops re-learning each payer's new rules by getting burned. The first call catches the change; every call after is immune.

Concept 4 · The Appeal Engine

Everyone files appeals. We know which ones will win, per payer, before we file.

Illustrative mock · Revenue recovery

The innovation, stated plainly

Filing appeals is not new; every billing shop does it, and denial-management tools template the letters. The innovation is what decides the appeal. Traditional tools use static rules: "modifier-25 denial, send template." Ours uses the Genome, so it knows that Meridian reverses 80% of these but Atlas only 31%. We do not appeal everything. We appeal what the data says will win, for that specific payer, from reversal behavior no one else has because no one else makes the calls.

What's actually new

  • Genome-driven, not rule-driven: the appeal decision comes from real per-payer reversal rates, not a static playbook
  • On the call, not days later: the denial and the recovery decision are one continuous action, no queue, no downstream review
  • Ranked by recoverable value: denials are scored by reversal-odds times dollars, so staff work a revenue pipeline, not an alphabetical worklist
  • The moat is the reversal data itself; it sharpens with every appeal filed

Discovery questions to validate

  • How much lift does per-payer reversal data give over generic appeal rules?
  • Would customers pay a percentage of recovered revenue?
  • What appeal-accuracy threshold changes a biller's behavior?
Why it closes deals

The appeal engine is the payoff of the graph

This is not a standalone feature bolted on; it is the proof that the data moat pays in dollars. Because we make every call, we learn each payer's true reversal behavior, and that is what lets us tell a biller which denials to fight and file them on the spot. A competitor can file appeals. They cannot know Meridian reverses 80% and Atlas 31% without the call volume we have. The graph is the moat; the appeal engine is where the moat becomes revenue.

The pricing unlock: because we can score recoverable value, we can charge a percentage of recovered revenue, aligning price directly with dollars delivered. No one without the per-payer reversal data can price that risk.

Concept 5 · The Protocol Bridge

When both sides have agents, skip the hold music.

Illustrative mock · Pre-validation

The moment it shows

An AZ agent dials a payer, starts navigating the IVR, and detects an AI agent on the other end. The call flips from voice theater to structured protocol: verification tokens exchanged, claim status returned, done in seconds. Voice remains the universal fallback; protocol becomes the fast path. First-time counterparty agents route through a human trust gate.

What's underneath

  • Agent detection + capability handshake over the voice channel, then structured exchange (A2A/MCP-style)
  • Trust registry: verified counterparty agents, with human approval on first contact
  • Multi-channel weave: voice, fax, portal, email in one governed workflow

Discovery questions to validate

  • Which counterparties deploy answering agents first, and will they handshake?
  • What trust and verification standard do both sides accept?
  • Does AZcare publish the protocol and own the standard?
Protocol Bridge, Workflow: Claim status · Payer #212 MOCK
📞
Dial + IVR
Queued
🤖
Agent Detected
·
🧑‍⚖️
Trust Gate
·
🔁
Protocol Exchange
Queued
Outcome Delivered
Queued
Dial + IVRDialing via Graph fast path (menu 2 → 4) · hold model predicts 14 min · voice agent engaged
⚡ Agent DetectedCounterparty is an AI agent. Capability handshake offered · structured channel available · hold music no longer required
⏸ Trust GateFirst contact with this agent. Identity attestation routed for human approval · signature pinned to trust registry
✓ Trust GateApproved. Counterparty agent verified against payer domain · future contacts auto-trusted
Protocol ExchangeVerification tokens exchanged · claim #88231 status returned: approved, EOB issued 07/18 · transcript + attestation logged
Outcome DeliveredRequester notified with confirmation artifact · Graph enriched: this payer now protocol-capable
Protocol path: 9 seconds · voice-only baseline: 23 minutes of hold
9 seconds. Not 23 minutes.
Concept 6 · The Completion Pulse

ROI as a live signal, not a QBR slide.

Illustrative mock · Pre-validation

The moment it shows

A COO glances at the board mid-quarter: completion rate ticking up, hold-hours absorbed piling into the hundreds, one counterparty degrading two weeks running, with the system already proposing the fix. The dashboard is the sales artifact: value visible live, renewal conversation already won.

What's underneath

  • Live aggregation across every workflow: completions, time-to-outcome, escalations, counterparty responsiveness
  • League table of counterparties, who answers, who stalls, who needs the fax path
  • Signals feed the Predictor and trigger Bridge playbooks automatically

Discovery questions to validate

  • Which 4 metrics does an ops leader check weekly, unprompted?
  • Does the league table drive expansion ("add another department")?
  • Per-completion pricing vs. platform license, what does the Pulse justify?
Completion Pulse, Live Board · Acme Health Ops · wk 30 MOCK
Completion rate
0.0% ▲ 2.1
Time-to-outcome
0.0h ▼ 0.8h
Hold-hours absorbed
0h this mo
Counterparty drift · Payer #212
0% 2 wks
LiveSignalPayer #212 responsiveness down 31% for 2 weeks · hold times doubled after their IVR change
LiveProposedShift Payer #212 calls to 7 to 8am window + fax fallback · one click to apply to 47 queued workflows
LiveExpansionFinance dept usage +58%, vendor confirmations trending · expansion playbook drafted for account team
ROI, live on screen.
Proof · meet Otto

Meet Otto, the agent that makes the call

Otto is the calling agent at the center of this. This is not a slide or a mock: Otto places a real phone call, navigates the payer IVR, survives hold, passes verification, and the Counterparty Graph builds itself on screen from the live transcript while the Completion Pulse ticks. The concepts you just read, running end to end, driven by one agent you can point at any payer.

☎️
Otto never waits on hold for you.
Pick a claim, and Otto dials the payer, works the phone tree, and comes back with the answer, logging everything he learns into the graph so the next call starts smarter.
▶ Watch Otto make a live call
Otto dials, navigates the phone tree, and the graph builds from the real transcript.
Give it a few seconds to wake on first load.
Why me

29 years of voice AI, pointed at your exact problem

AZcare's hard problems are the ones I've spent a career shipping through: speech at production scale, AI that survives real phone systems, governance that clears enterprise procurement, and platforms that turn calls into structured outcomes.

Founder & CEO of Piot Networks; founding member of AdEntify. Built on-device speech tech at BabbleLabs, acquired by Cisco in 2020.
30M+
Call & conversation summaries shipped, production AI over real phone conversations at global contact-center scale
50B
Tokens/month governed, architected the LLM platform layer: routing, guardrails, cost, compliance
29
Years in enterprise AI, speech, NLP, LLMs, agentic platforms; CMU-trained; patents across all of it
📞

I've shipped AI that lives on the phone

  • Contact-center AI at millions of calls: summarization, mid-call handoffs, topic analytics, wrap-up automation
  • AI receptionist capabilities including transfer-by-name with grapheme-to-phoneme evaluation, deployed for global enterprises
  • Adversarial testing frameworks for voice and chat agents before they touch customers
🛡️

I've made agent AI enterprise-deployable

  • Guardrails, PII redaction, and compliance-grade governance in production, including regulated industries
  • Responsible AI programs that turn "impressive demo" into "approved vendor"
  • Fluent in the procurement dialects: healthcare, finance, and the enterprises AZcare will sell into
What I'd own

The founding CPO agenda, first 90 days

🔍

Discovery, weaponized

20+ customer conversations in 30 days. Which vertical's Graph is densest value first: payers, banks, or government? Which workflow is the land, which is the expand?

💰

Pricing architecture

Per-completion pricing anchored to hold-hours absorbed, with SLA-backed tiers the Predictor makes possible. Value pricing, not seat pricing.

🗺️

The Graph as strategy

Data network effects with per-customer privacy walls, designed from day one. The moat gets architected now or never.

🛡️

Governance as product

TCPA, HIPAA, consent, recording laws, adversarial testing of voice agents. The compliance posture that turns pilots into enterprise contracts.

The ask: an hour with the team. I'll bring the full argument; you bring the hard questions. Worst case, you get a free product thesis from someone who has shipped voice AI for 29 years. Best case, AZcare gets its founding CPO.  francis.kurupacheril@gmail.com