On 21 September we set out to answer a narrow question. Could a small firm, with no engineering team and a modest budget, stand up a working browser-based contact centre by describing what it wanted in plain English to an AI coding assistant, and testing every step on a real phone line? It was a proof of concept in the textbook sense: prove the thing can be done, write down what you learned, and move on.
We did not move on. Five days later the proof of concept has an AI receptionist called Illiriya answering our UK line, a callback queue, a wallboard, a knowledge library, an audit log and 611 automated tests. The question is no longer whether it can be done. It is how far it can be taken before the limits start to show, and that is a more useful question for anyone weighing AI in their own customer operation.
What the proof of concept was meant to prove
The first version was deliberately plain. One small Python web app, hosted on Render, with Twilio carrying the calls and texts. An agent signs in, and the browser becomes the handset: answer, dial out, send a text. It took most of the first two days just to make that behave, and the lessons were the unglamorous ones. A cryptic Twilio error that looked like a network fault turned out to be a single missing setting. For a while the app was saving everything to a temporary file that vanished on every deploy, without complaining once. The original code had published a working password in a public repository; it was retired, sign-in with it refused and the repository made private.
By the end of day two it worked. That should have been the end of the exercise, and in most organisations it would have been. The pilot passes, a slide goes to a steering committee, and the momentum drains away while someone writes a business case.
The moment it stopped being a pilot
What changed the trajectory was putting a voice AI on the front of it. Every call now reaches Illiriya first. She answers questions, takes messages, and when a caller needs a person she transfers them with a short summary of who they are and what they want. Returning callers are greeted by name. Out of hours she takes messages instead of transferring, unless something is genuinely urgent, in which case she rings the on-call mobile.
Before choosing the model behind her, we tested eight open-weight models on the same three scripted calls. The fastest, at about half a second to the first word, was also the cleanest. Others read their reasoning aloud to the caller, promised to connect someone and then did nothing, transferred in silence, or took more than ten seconds to speak. None of that shows up on a model provider's benchmark table. All of it shows up on a phone line within a minute.
Once a caller can talk to the system, the gaps become obvious in a way a dashboard never makes them. A message taken is useless unless someone calls back, so messages and missed calls became callbacks with due times drawn from the caller's own words, "tomorrow morning" or "after 3". A transfer to a colleague needs hold, a warm hand-over and a way back if nobody answers, so answered calls now move into a conference room with those controls. Each feature was the obvious next question raised by the one before it.
Letting it build overnight
On the evening of 24 September we wrote down six more features, approved a plan with hard rules attached (never touch the main code line, never deploy, never send a real text or make a real call, never read a secret) and went to bed. The work ran as separate branches. Each feature was built by one AI agent and then attacked by another whose only job was to find what was wrong, three rounds over. Usage limits stopped the work twice in the night, and each time it picked up from a written progress log without losing anything.
The reviewers earned their keep. They found a caller hanging up during a whisper briefing and leaving the agent alone in an empty conference room, withheld numbers all counted as one very persistent repeat caller, and a wallboard wait timer that reset to zero when a call moved to a mobile. None of those would have surfaced in a demonstration.
The merge the next morning is the part we find most instructive. All 611 tests passed, and the deploy still failed. A database library had released a new version overnight that quietly changed its default driver, and because that dependency was not pinned, the live build fetched the new one while the tests ran against the old. The previous version kept answering calls while the cause was found, and the fix was live by 11:56. Every dependency is now pinned. It is a small story, but it is exactly the kind of failure that separates something that works on a laptop from something a business can rely on.
What we have learned so far
The most useful fixes came from testing against the real thing, not from the code passing its own tests. Real models misbehave in ways scripts do not anticipate: one repeated a previous caller's message to whoever next rang from that number, and another occasionally wrote a tool call into its reply as text, so a caller heard a line of code read aloud and the transfer never happened. Each of those became a rule enforced in code rather than a line in a prompt. Asking for a person always transfers. A promised follow-up always happens. Earlier contact is never read back to a caller.
Privacy is far easier to design in than to bolt on. Recordings play only through the app, the wallboard never shows a full number, and the knowledge sent to the model is kept to public information. The same thinking applies to the ordinary failure cases. A call forwarded to a mobile can be picked up by voicemail, which the network reports as answered, so the mobile now asks for 1 to be pressed; voicemail never presses 1, and the call is logged as missed instead of disappearing.
And writing the plan down matters more than the tooling. Because the rules, the plan and the progress log lived in files rather than in anyone's memory, an interrupted night's work resumed cleanly twice. That is not an AI lesson. It is a programme delivery lesson that AI makes impossible to ignore.
How far can this go?
We do not yet know, which is rather the point. The honest caveats first: much of the overnight work has passed its tests but has not yet handled a real caller, the database still sits on a free tier with a thirty-day clock on it, and a security review of this week's code is waiting its turn. This is a working system, not a finished product, and we would not advise anyone to run a regulated operation on something five days old.
However, the economics of the experiment have shifted. The question used to be whether a pilot justified a build. When the build costs days rather than quarters, the pilot and the product start to merge, and the discipline that matters moves elsewhere: clear rules, real-world testing, independent review, and someone who knows when a feature is solving a problem and when it is just possible. That is where most organisations' AI programmes will be won or lost, and it has very little to do with the model.
Illiriya is live on our contact page. Ring her, ask her something awkward, and see how she does.