Voice agents: we rebuilt our receptionist bot in one week, and it already beats the original.

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.

What happened at the Eleven Labs Netherlands launch?

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).

What are ElevenAgents and the architect?

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.

How did we test the new voice agent?

We rebuilt the internal receptionist bot, the same one our LiveKit-based stack already ran, on the ElevenAgents platform. The method was simple.

1. Setup. One engineer, one 40-hour week, 5-9 October 2026. The engineer already knew the old bot well.
2. Scope. The same as the old bot: greet the caller, answer questions, close the call.
3. First version. The engineer prompted the architect and had a working agent by the end of day one.
4. Testing. Colleagues played the role of callers and made 39 test calls.
5. Improvement loop. The architect analyzed those conversations and proposed changes. The engineer compared its suggestions with what they would have done themselves.
6. Done. We called the build finished when it worked and outperformed the old bot. After that, we only iterated.

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.

What did we evaluate the new voice agent?

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:

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.

Where are the limits of this comparison?

This comparison favors the new build in several ways, and an honest reading has to account for them.

• The engineer knew the old bot. The engineer already understood the use case, prompts, and lessons from the earlier work. A team starting from zero would take longer. Part of those five days is knowledge we already paid for.
• One engineer, one use case. A single receptionist flow is simple. We have not tested outbound calls, payments, or regulated workflows on the platform.
• "Better" needs a number. We say the new version exceeds the old one, and we believe it does. AI-analyzed sentiment shifted toward a more positive experience: positive ratings rose from 13% to 44%, while negative ratings also rose slightly from 3% to 17%.
• Git history is a rough measure. Commit days show when code was pushed. They do not show design, meetings, debugging, or review, and several people committed on the same days. For a firm figure, you need timesheets or tickets.
• Platform dependency. Our old stack was ours to run and change. The new one is a vendor's. Pricing, data residency, model changes, and exit costs matter. Calls using 11 Labs cost an average of $0.14 per phone call. On average, 55% of that comes from the voice platform STT, TTS & call handling, and 40% of those costs go to LLM tokens. The rest goes to small burst surcharges, for example, when multiple callers are on at once.
• We tried one vendor. We did not benchmark other managed platforms, so this post does not rank ElevenLabs against them.

None of this changes the main finding. It changes how far you should generalize.

What does this mean for decision-makers?

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:

1. Predictability. A voice agent that sounds natural but behaves inconsistently is a liability. This is a question of prompt design, testing, and monitoring, and the platform doesn't remove it.
2. Handover to humans. Deciding when the agent should pass a call to a person is a business decision. It sets cost, customer experience, and risk. It should be made by the process owner, not left as a default.
3. Compliance. Callers must be able to tell they are speaking to an AI system. The EU AI Act sets transparency obligations for systems that interact with people. Call recording and data residency add GDPR questions.

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.

What should you do next?

1. Prototype before you build. Run a one-week test on a managed platform with one engineer and one well-understood use case. Compare the result with your own estimate for a custom build.
2. Define "better" before you start. Pick two or three measures, for example, task completion, escalation rate, and caller satisfaction, and record them for the current system first.
3. Decide the handover rule early. Write down when a call goes to a human agent and who owns that rule.
4. Keep a person in the improvement loop. Let the platform propose changes, and have someone review them against your measures. Do not let it change a live agent unchecked.
5. Cost the exit. Before committing, estimate what it would cost to move away from the platform later, including data, prompts, and telephony.
6. Check compliance first. Confirm AI disclosure, call recording, and data residency before a pilot reaches real callers.

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.

How ML6 helps

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.

Sources

• ElevenLabs Netherlands launch event, 1 October 2026 (attended by ML6). http://elevenlabs.io/blog/elevenlabs-netherlands
• KPN Case https://www.kpn.com/zakelijk/thedigitaldutch/blog/voice-en-ai-gouden-combinatie http://elevenlabs.io/blog/elevenlabs-netherlands
• ElevenLabs documentation https://elevenlabs.io/docs/eleven-agents/overview https://elevenlabs.io/docs/eleven-agents/operate/architect
• EU AI Act (Article 50) https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
• ML6 internal git history, two repositories (data as described in the table note).