It said done. Nobody answered.

One question, three answers

There are three ways into CALL-E and each one reports how a call ended in its own words. One can say voicemail and busy. One has no word for either. The third has a failure code with no published list of values, and their own errors guide says not to branch on it. So I wrote a small library that reads all three onto the same scale, and every reading says where it came from: quoted from a field, worked out from other fields, or simply not there.

A voicemail box finished the job

Early on I dialled my own phone and it went to voicemail. The agent asked its question into the beep three times and hung up. The API came back completed, task_completed true, confidence high. Sitting in the same object, the result field said the answer was unknown. The payload disagreed with itself and the field everybody branches on picked the wrong side.

Nothing in my mapping was wrong. Each field was read faithfully. The missing rule was about the pair: a job marked done on a call where nobody established a person was there.

Confidence cannot tell them apart

So I needed a call with a known right answer and nobody bothered by it. The US speaking clock is a recorded line that exists to be called, and what it says is checkable to the second. The agent heard the time and got it right. That real success and the voicemail box that answered nothing scored two hundredths apart, under the same label. There is no threshold you can set between them. Anyone gating on the score is gating on noise.

The clock that moves

Read a finished call straight away and the attempt times are fine: a timezone, fractions of a second. Read the same call a minute later and they have been rewritten. The zone is gone, the time has moved four hours, and the fractions are rounded off. After that it stays wrong. A billing check or a support ticket always reads it later, so it always gets the bad copy.

Another builder had already reported failed calls showing zero duration and blamed the failure path. Their issue was tagged as needing validation. I posted a reproduction that disagreed with their theory: it is about when you read, not whether the call failed. I also said plainly which part of their report my data could not explain. The event stream never moved in any read, so the tool treats events as the clock and the attempt fields as a rumour.

And I was wrong, more than once

My library read an automated phone menu as a human picking up. The screen said a person answered and it was safe to act on. That one switched off the exact safety rule the whole thing exists for, and a live call caught it, not my hundred tests. The reviewer caught the rest. My demo would let anyone who guessed a call id read that call. I shipped two real phone numbers after ticking the box that said all numbers were fictional. My first pull request carried payloads from real calls, and I closed it myself.

Every one of those is fixed and written up in the thread where it happened. The reviewer asked for four rounds of changes and was right every time.

Fourteen issues, six fixed

While building I kept a defect log and filed it in the right repos: the docs, the two SDKs, the CLI and plugins. A maintainer fixed five of them in one night and closed each one with a merged change. Two of them he rated top priority.

The one I am proudest of shows up three times. The TypeScript SDK, the Python SDK and the n8n node all stop waiting the moment a call's status says finished, and all three do the opposite for goal runs. Three codebases, written separately, with the same bug. That is not three careless authors. It is one sentence in the docs, and they all believed it.

Merged

The contribution is a skill that teaches an agent to read what actually happened to a call, plus a small app that shows it. It flags calls that are stuck, calls that are replays, retries that would ring someone twice, and durations that cannot be trusted. Each flag maps to an issue somebody else had already filed and nobody had built against.