Executive summary
One engineer rebuilt ML6's internal voice receptionist on the ElevenAgents platform in a single 40-hour week (5-9 October 2026). Our earlier voice agents, built on the open-source LiveKit framework, took months: git history shows commit activity on 37 and 96 days across two internal repositories between September 2025 and July 2026. The new version already outperforms the old one. Internal tests show early hang-ups dropped from 41% to 21%. Even more impressive: the amount of real requests delivered increased from 36% to 71%. Callers were more likely to be optimistic about what or whom they wanted. The comparison is not like-for-like, because our engineer already knew the old bot. Even so, if you are considering a custom voice agent stack, run a one-week prototype on a managed platform before you commit to building.
ElevenLabs used its Netherlands launch event on 1 October 2026 to show that voice agents are already in production and scale beyond demos. ElevenLabs takes the Dutch market seriously, as the venue and program reflected. The most useful part for us was a panel on customer service agents that had gone live.
One case stood out: large-scale telecom provider KPN already took its customer service agents into production with ElevenLabs (60,000 weekly customer calls). The panel described three problems the team had to solve. Obviously, the priority was making agents behave predictably. The other two included keeping the system prompt short enough to stay effective and deciding exactly when to hand a call to a human agent.
We recognize all three. We hit the same problems when building voice agents for clients, and the same questions came up in our internal build. Hearing them from a team in production confirmed that these are the real difficulties of voice agents. Interestingly, model quality is no longer the main obstacle.
The event also deployed the technology itself. Live translation and transcription ran throughout the event, and in our experience, they were quite accurate. ElevenLabs also showed recent changes to its creative platform: a media campaign built from start to finish and adapted to different markets, platforms, regions, and cultures, which it said can be set up in about two hours (we have not tested this yet).
ElevenAgents is a platform for building voice agents: software that holds a spoken conversation with a caller, answers questions, and decides when to hand over to a person. The platform combines speech recognition, a language model, speech synthesis, and telephony.
The architect is a feature of that platform. You describe the agent you want in plain language, and the architect produces a working first version. It can also read recorded conversations, analyze them, propose improvements, and apply those changes itself. In other words, it covers both the first build and the tuning loop that normally takes most of the time.
Speed of response matters for voice more than for text. A caller notices a one-second pause. We find that the low-latency ElevenLabs v4 model we use on the new bot made the agent feel noticeably more responsive. In fact, the median response time is around 1.9 seconds.
We rebuilt the internal receptionist bot, the same one our LiveKit-based stack already ran, on the ElevenAgents platform. The method was simple.
For the baseline, we used git history from our two earlier internal repositories. One is a general LiveKit Agents framework with several example agents, including the receptionist. The history gives only a rough measure of effort, and we say more about that below.
The architect produced a working agent from prompting alone, and it found the improvements we would have found ourselves. The second point surprised us most.
After colleagues had played test calls, the architect read the conversations and suggested changes. In our assessment, these were the same improvement points we would have proposed. It then applied them on its own. That shortened the cycle from the first version to a usable agent considerably. Normally, this is the slowest part: someone listens to calls, spots patterns, edits the prompt, and tests again. Here the platform did most of that loop. We went over 30 iterations in just one week.
The architect proactively suggests actions based on evaluated calls.
The comparison with our earlier work looks like this:
| Metric / Feature | Earlier build (LiveKit, own stack) | Rebuild (ElevenAgents) |
| Calendar time | About 5.5 months (repo A) and about 11 months (repo B) | 5 days (5-9 October 2026) |
| Days with commits |
37 (repo A), 96 (repo B) |
5 |
| Estimated effort |
Roughly 37-80 person-days (repo A, our estimate) | 5 person-days (one engineer, 40 hours) |
| Scope | Scope Repo B is a multi-agent framework; the receptionist is one of six examples |
Receptionist only |
| Result | Working receptionist, but 41% early hang-ups and only 36% real requests delivered | Working, and better. Only 21% early hang-ups and 71% real requests delivered |
Sources: ML6 git history for two internal repositories (repo A: 11 February to 23 July 2026, 183 commits, about six contributors; repo B: 2 September 2025 to 24 July 2026, 618 commits). The effort range is our estimate: the lower end counts commit days only, the upper end adds one day of non-commit work per commit day.
Read the table carefully. The earlier repositories cover far more than a receptionist. Repo B includes outbound meter readings, outstanding payments, an EU AI Act risk classification agent, a survey agent, and others. We are not claiming that one week replaces eleven months of that work.
What we can say is narrower. For the same receptionist use case, and with a team that already knew the problem, a managed platform took one engineer five days to reach a result that beats what we built ourselves in months.
This comparison favors the new build in several ways, and an honest reading has to account for them.
None of this changes the main finding. It changes how far you should generalize.
The cost of a first working voice agent has dropped, which changes where the decision effort belongs. If a competent engineer can reach a usable agent in a week, building a prototype is no longer the big commitment. The big decisions move to what comes after.
Three of them stood out in the production case at the launch event, and in our own work:
There is also an organizational effect. If the architect can read conversations and tune the agent, the person doing the tuning is closer to a product owner than a prompt engineer. Someone still needs to define what "better" means and check that the agent's own changes are the right ones. In our test, the changes matched the engineer's judgment. That is one test, not a guarantee.
An honest limit on this advice: it comes from one use case and one vendor. A custom stack can still be the right choice when you need control over data, models, or deployment that a managed platform does not offer.
ML6's AI engineering team builds and runs voice agents for clients, on custom stacks and on managed platforms, and our advisory team helps you decide which fits your use case, risk profile, and EU AI Act obligations. If you are weighing build versus buy for a voice agent, talk to our team.