Status
What is proven, and what is not.
A page most products do not have, because the alternative is letting a reader assume things that are not true yet.
CallAgent is a large system with a great deal of working code and a specific, stateable set of things it has never done. The rest of this site describes what the software does. This page describes how far that has been demonstrated, and it is the page to read first.
What has actually been run.
These are counts from a full suite run, not an estimate. The suites cover the call session and its state machine, all nine steps of a barge-in, audio codecs and resampling, endpointing, the MCP client and its permission gate, provider fallback and circuit breaking, tenancy, and a chaos and security pass over the control plane.
Skipped tests name the credential they need and report as skipped rather than as passing, which is the difference between a suite that is honest and a suite that is green.
- PHP tests
- 1,206
- TypeScript tests
- 1,033
- Total
- 2,239
- Failing
- 0
Pest, over the control plane: every domain plus tenancy, security and chaos suites.
Contracts, audio, MCP, the provider SDK, the gateway, the web SDK and the CLI.
2,237 passed, 2 skipped. Each skip names the credential it is waiting for.
At the time the build report was written, dated the fourth of September 2026.
Quoted from the build report in the repository root, which states its own reporting rule: nothing is claimed as working against a provider there is no credential for.[1]
On 5 September 2026 the first real calls rang
Until that day, everything below about telephony was proven against contract tests. Then somebody put in real Twilio, Anthropic, ElevenLabs and Sonix credentials and rang the number from their own phone.
Eleven calls. Five ended normally, six failed. It did not go well, and that is the useful part: you can see exactly where it broke.
| what was placed | Eleven calls through Twilio to a Romanian number, between 11:50 and 13:55. Five ended, six failed. The longest ran 2 minutes 6 seconds and produced 232 events. |
|---|---|
| what went wrong | The transcriber was running with its language set to “multi” and labelled Romanian as Hindi. The model was handed Hindi text, replied in Romanian that it could only speak Romanian, and offered a transfer to an operator. It did the right thing with the wrong text. |
| measured latency | The first turn of a call: 3,091 ms from endpointing to audio against a 1,200 ms target. The first token arrived in 2,085 ms against a 600 ms target, and the first audio frame in 419 ms against 400. Only speech synthesis came close to budget. |
| what worked | Signalling, dual-channel recording, the event ledger, cost accounting and the transfer all worked. The 32-second call has 83 events, a ready recording, a computed waveform and five cost rows. |
What still has not happened
A handful of calls from a colleague phone is not production. We have run no volume, kept no customer on this system, and taken no real payment.
The list below is what should concern you if you are thinking of putting real traffic on it.
| volume and production | The highest number of simultaneous calls this system has ever carried is one. There are no load measurements, no day of real traffic, and no customer has been served. |
|---|---|
| live payment | None. The billing paths run the real payment SDK over a faked transport, and the console does not even have a button to add a card. |
| media timing | The switch was tested under CPU emulation on a developer machine. Signalling and the dial plan were verified; audio timing measured on that host is not representative of a server. |
| carrier trunk | No call has been through a bring-your-own SIP trunk. Only Twilio has been used, and only through its API rather than over SIP. |
Things that have.
Not everything is waiting on a credential. Several parts of the system have been exercised against real infrastructure or a real synthetic call, and those are worth separating from the rest.
| the switch boots | FreeSWITCH comes up clean from an empty volume, with both SIP profiles running on their internal and external ports and zero errors. |
|---|---|
| SIP scenarios | 11 of 14 SIPp scenarios pass against that live switch in one run: OPTIONS, registration with digest auth, a wrong password refused, a full call setup and teardown, cancellation, hold and resume, DTMF over INFO, transfer, an unauthorised invite challenged, a malformed request rejected, and a call with no acknowledgement reaped. The remaining two need a carrier gateway pointed back at the test harness. |
| a full synthetic call | The gateway drives a complete call through the real session code against mock providers, including a barge-in that runs all nine steps in order and discards the queued audio frames the caller must not hear. |
| MCP client | Transports, discovery, the permission gate and a large suite specifically about server-side request forgery, because an MCP server is a URL somebody else controls. |
| tenant isolation | A cross-tenant read through implicit route-model binding was found by these tests, fixed globally, and now has a regression test. That is what the suite is for. |
Not blocked, not finished.
These are things the build report lists as remaining work that nothing external is holding up. They are listed here in the same words rather than described as coming soon.
From the remaining-work section of the build report, plus one open blocker from the engineering notes.[2]
- 01 Server SDKs generated from the OpenAPI document. The document exists; the SDKs are not shipped.
- 02 A mobile SDK. Not started.
- 03 SAML 2.0 single sign-on. Needs an XML signature library. SCIM provisioning exists; SCIM Groups does not.
- 04 Speech-to-speech is implemented and unit-tested but is not yet selected by the call session — the text pipeline is the only wired path today.
- 05 PDF and legacy Office document ingestion for knowledge bases. Needs a parsing library.
- 06 Reranking for hybrid retrieval. The interface is there; the implementation is not.
- 07 The Opus codec. The rest of the audio path is complete.
- 08 A sandbox image for the shell and computer tools. The client currently refuses to execute rather than quietly falling back to running things locally, which is the correct failure.
- 09 Volume pricing tiers are stored but not applied. Environments and per-key rate limit overrides have schema and models but no service behind them.
Why the product itself is written this way.
A system that reports a guess as a measurement teaches the person using it to distrust every number it shows. Once that happens, the good numbers are worth nothing either, and the honest thing and the useful thing turn out to be the same thing.
So the convention runs all the way down. An estimated latency is prefixed and dimmed and says in a tooltip that it came from a vendor's published figure. A cost derived from list prices at an assumed turn rate says so. A stack that could only be priced for one stage out of three refuses to show a per-minute total, because that is a number a customer would budget against.
And a tool that would need a sandbox that does not exist yet refuses to run, rather than executing locally and reporting success.
No integration is claimed as working against a provider we have no credential for. Everything is either measured here or explicitly labelled as untested.
BUILD_REPORT.md
Notes
-
1
Test counts, the reporting rule and the SIP results:
BUILD_REPORT.mdat the repository root, dated 2026-09-04. - 2 Remaining work: the same report.