ProCat Solutions
Abigel.ai is live, and half a second became our most important number
Our DIMOP Plusz project has closed and the phone assistant and AI language teacher are live at abigel.ai. Lessons on latency, streaming and telephony.
· Our own product 
Yesterday, 14 September 2026, our project DIMOP_PLUSZ-1.1.2/A-24-2025-00236 came to a close, and what it produced is now live at https://abigel.ai. For more than a year we built a system that processes a phone call in real time. This post covers what we shipped and what we learned along the way.
Co-financed by the European Union.
Two products, one foundation
Abigel.ai consists of two products on shared infrastructure.
Virtual assistant. An AI phone assistant that answers calls on a business’s number 24 hours a day. It talks to the caller, books appointments, takes messages, answers simple questions, and produces a transcript and a summary of every call. Customers build the course of a call in a no-code flow editor, without programming. The assistant speaks more than 25 languages and detects the caller’s language.
Teacher. A conversational AI language teacher that runs speaking lessons in 26 languages, from A1 to B2. The learner speaks; the system responds, corrects and gives feedback in real time. The audio processing chain built for the phone assistant serves a different purpose here, but the technology is the same.
Both are multi-tenant SaaS: usage-based pricing, data separated per tenant, GDPR-compliant operation inside the EU, a call log and CSV export. The project delivered the scope committed in the grant.
Half a second
The project’s most important technical lesson fits in one sentence: on a phone call, anything that takes more than a few hundred milliseconds can be heard. People expect a reply within roughly half a second. Stretch that to a second and a half and the caller talks over it, hesitates or hangs up.
Run speech recognition, the language model and speech synthesis one after another and you easily reach several seconds. What we did about it:
- Streaming at every step. Speech recognition returns partial results before the sentence ends. The language model’s reply arrives token by token. Speech synthesis is already speaking the first sentence while the rest is generated. The chain works as a pipeline, with the stages overlapping.
- End-of-speech detection. Deciding whether a caller has finished speaking turned out to be harder than we expected. A silence threshold that is too short cuts people off; one that is too long feels slow. We tune it on the content of the speech as well as the length of the silence.
- Interruptions. If the caller starts talking while the assistant is speaking, playback stops at once and only the part actually spoken counts as context. Without that, the conversation feels unnatural.
- Geographic proximity. We use voice and language model providers through endpoints inside the EU, and our own components run in the same data centre. Each network hop costs ten to twenty milliseconds, and they add up.
We measure latency per call and per step, and track it in percentiles. Most of our architectural decisions were made on that metric.
Old telephony problems
Everything we had written before about SIP and the PSTN came back, plus a few new issues:
- the phone network’s 8 kHz, G.711-encoded audio carries far less information than the data speech recognition models were trained on. Accuracy is worse on a phone line, and confirmation questions in the flow editor have to make up for it,
- audio passes between the SIP side and the processing chain in small frames, without buffering; every buffer is latency,
- operators’ SIP trunks behave differently on call transfer and DTMF handling, so the bridge layer is configurable per operator,
- the network can fluctuate mid-call, and jitter and packet loss degrade recognition, so we write RTCP data into the call log too.
Testing could not rely on manual calls. We launch automated calls that walk through the flows with pre-recorded or synthesised speech and compare the transcript with the expected one. It is slow, but without it someone would have had to phone in by hand after every change.
No room to improvise
The large language model drives the conversation, but a phone call is a peculiar environment. It needs short, spoken answers, not paragraphs. The model has to follow the steps set in the flow editor, and when recognition gets something wrong, it has to ask instead of guessing. It receives the flow as a structured instruction; free text only shapes the phrasing.
Appointment booking and similar operations go to the backend as tool calls, and the backend returns the result to the model. Here too, idempotent processing is the key: a retried call must not book two appointments.
Operations and fine-tuning
The project has closed, the product is live, and the coming months are about operations and fine-tuning. We will keep sharing what we learn on the blog. Next up: load testing voice-based systems and alerting based on call quality.
We thank the Hungarian Government and the European Union for their support, and everyone who tested, sent feedback and stayed patient through the first, still stuttering calls.
