Ringdown

An on-call escalation agent that phones the pager holder — and proves the acknowledgement happened.

Comment

Inspiration

Every on-call system reports "notification sent" and treats the incident as escalated. That proves nothing. The push landed on a silenced phone. The mail went to a folder. The SMS was half-read at 03:00 and the engineer went back to sleep. The acknowledgement is the only part that matters, and it is exactly the part nobody verifies.

What it does

Ringdown walks an escalation ladder one real phone call at a time. Each rung asks one person two questions: are you taking this incident, and in how many minutes. A run ends when somebody commits with an owner and a clock, when somebody declines, or when the ladder is exhausted.

It records an acknowledgement only when the owner and the ETA are each quoted by a span the recipient actually spoke. A "yes" with no number of minutes is not an acknowledgement.

That one case is the whole product. In the demo's second scenario the provider is perfectly satisfied — the call completed, task_completed is true, confidence is high at 0.91, the disposition reads acknowledged — and there is no ETA. A system that branches on those three signals reports the incident as escalated and goes back to sleep. Ringdown drops a rung, and the backup commits.

How we built it

It places the call over REST and re-reads it over MCP. The provider's two surfaces are not two views of one JSON document: REST reports lowercase statuses and exposes task_completed and completion_confidence; MCP reports uppercase statuses and accepts no extraction schema at all. So verifying over MCP re-derives the acknowledgement from a transcript served by the transport that did not write it. An agent that audits itself through the channel it wrote with proves nothing.

Ten checks run on the attempt that acknowledged, in two blocks that prove different things: six establish that both surfaces describe one call, four re-derive the acknowledgement from the second channel's transcript. Zero checks is not success — a ladder with no attempts is never reported as verified.

Every verdict is sealed in a hash-chained JSONL ledger that does something a flat append-only log cannot: it re-derives the verdict from the recorded attempts on replay. Rewrite a verdict, recompute its hash, relink every record after it, and the chain closes cleanly — and verification still fails.

Python 3.11 with an empty dependency list. 295 tests that run with no credentials and no outbound calls, against a fake CALL-E that serves both surfaces from one store with two different projections.

There is a second app, calle-receiver, that exists for one reason: CALL-E does not dial Argentina. It is a FastAPI service that answers the agent on a US Twilio number and bridges to an Argentine phone, with recording, live transcription and a dashboard.

Challenges we ran into

The idempotency key stopped being a nicety and became the load-bearing part. All five REST creates timed out at a 15-second client socket timeout before the provider answered — one create sat inside the provider for four minutes and twenty-seven seconds before it did anything. Every one of them had in fact created the call. Because the key is derived from the payload rather than generated per run, all five replays returned the existing call instead of dialling a second time. Against the real API, reconciliation is the normal path, not a rare branch.

Speech recognition turned out to be the honest adversary. On one connected call the provider reported task_completed: true at 0.86 high, with evidence reading "The engineer acknowledged taking the incident." The recipient's turn behind that reads "Yes. I'm banking this incident right now" — the transcriber heard "banking" for "taking". Ringdown refused the acknowledgement, correctly: no commitment phrase was ever spoken in the transcript it was given.

Accomplishments that we're proud of

The demo output was written by hand before the code that produces it, and a test now compares every quoted block against a real run, so the contract cannot drift silently.

And we placed six real calls against the live provider — which the repository itself called "the single highest-value thing anyone with a dialable number can do".

What we learned

Those six calls confirmed the REST contract: metadata echoes back exactly as sent, so an attempt can be tied to the call it belongs to.

They also settled an open question, in the direction we did not want. get_call_run takes a run_id that only run_call hands out. No identifier a REST-placed call exposes resolves to one — not the call id, not provider_call_id, not the attempt or recipient id. And the first successful run ever observed does not have the shape our parser reads. Cross-surface verification cannot be completed from this side today, so a live run reports the acknowledgement as unconfirmed rather than claiming it — exit 45, which means the second channel said nothing, never the second channel disagreed.

We did not hide that. It is stated as a known ceiling, the provider's actual responses are committed as test fixtures with their provenance, and one test asserts that the parser cannot read a real run — so the gap is a tested fact rather than a surprise waiting for the next person. The same findings went to the CALL-E team as feedback.

What's next for Ringdown

The provider fix is small and unlocks the whole category: have get_call_run accept a call id as well as a run id, or expose the run id on the CallTask that REST already returns. Either one makes an agent auditable across transports.

On our side: re-escalation when an ETA expires, and a keyed HMAC over the ledger so it proves something against an adversary and not only against accident.

Built With

Share this project:

Updates