Architecture
What runs when a call arrives, which surfaces trigger the post-call chain, and the version boundary.
Four things matter before you build on Meddle. An admission sequence decides whether a call is answered. Both transports share one pipeline. Some surfaces trigger the post-call chain and some do not. And the version boundary splits settings a version owns from settings that edit live.
What happens when a call arrives
The caller's network delivers the call to our carrier, which posts a signature-verified webhook to the voice runtime. Everything below happens before the caller's phone stops ringing.
Number resolution
The runtime resolves the dialled number to an agent. If the lookup fails or the number is not assigned, the call is refused cleanly and the caller can redial.
Admission checks
Three checks decide whether the call is answered. They run concurrently with warm-up, so on the healthy path they cost no perceptible time.
| Check | On failure | On error |
|---|---|---|
| Billing | Call refused before answer, no charge | Fails open |
| Platform capacity | Caller forwarded to your overflow number | Fails open |
| Duplicate call | Second arrival for the same call refused | Fails open |
The duplicate guard is off by default. The other two are always active.
Order matters. Billing runs first, so a blocked workspace is refused rather than forwarded. Capacity runs next, so a forwarded caller never claims a pipeline slot. The duplicate guard runs last.
Warm-up during ringback
While the checks run, the runtime loads the agent's settings, warms the prompt cache and pre-renders the greeting audio. The whole warm-up is capped at two seconds; on timeout the call is answered anyway.
The caller hears ringback rather than dead air. A greeting rendered in advance is the difference between an agent that starts talking and one that starts thinking.
Answer and media
The runtime answers, the media stream opens, the greeting plays, and the conversation begins. Latency targets are on Reliability.
Two transports, one pipeline
| Transport | Used by |
|---|---|
| PSTN | Inbound calls, outbound campaigns, onboarding, call-me test |
| WebRTC | In-app test call, share-link voice call, website voice widget |
Both build the same pipeline. A browser test call exercises the same agent and conversational machinery as a phone call. What it does not exercise is the carrier leg: line quality, codec compression and speakerphone echo only show up on a real phone call.
After the call
Three passes run in order:
- Deterministic metrics. Model-free measurements from the call record.
- Judge metrics. A language model grades only the metrics the agent has enabled. None enabled means no model calls and no charge.
- Analysis. Sentiment, outcome, caller type, urgency, summary and extracted facts. Rolls the call into the caller profile when memory is on.
Analysis reads metric results, so it runs after the judge pass. Each pass is isolated, so one failing does not stop the next.
On the first analysis only, the platform fans out to alerts and post-call follow-up. Re-analysis does not fire them again. Turning call analysis off also stops alerts and follow-up.
Which surfaces run the post-call chain
| Surface | Transport | Post-call chain |
|---|---|---|
| Real inbound or outbound call | PSTN | Yes |
| In-app test call, share link, website widget | WebRTC | Yes |
| Voice eval, phone mode | PSTN | Yes |
| Voice eval, bridge mode | Direct | No |
| Text eval | None | No |
| Chat: test panel, share link, website widget | None | No |
A phone-mode eval dials the agent's own number, so the full chain runs. Outbound side effects are suppressed, so a test cannot send a real message to a stranger.
Evals prove the conversation, not what happens after it
Bridge and text evals write no analysis, raise no alert, send no webhook and run no follow-up. If your integration depends on post-call behaviour, use an in-app test call or a phone-mode eval.