The Part of Digital Transformation No Tool Comes With
Around five million times a year, someone calls KPN, the largest telecommunications provider in the Netherlands.
They are not calling to catch up with a friend.
They are calling because the internet stopped working just before a meeting, because an order never arrived, because they need to reschedule a technician's visit, or because moving house has turned an almost invisible service into an urgent problem.
For KPN, every call is part of an enormous operation.
For the person on the other end, it is usually an interruption to their life.
The company is building AI agents capable of holding voice conversations, accessing internal systems, and taking action. Its ambition is for these agents to handle between 10% and 20% of customer-service calls by 2027, while preserving a simple path to a human whenever one is needed.[1]
Told quickly, it sounds like another story about a large company adopting AI:
There were too many calls.
A technology appeared that could handle them.
The company decided to use it.
Everything fits.
It sounds like the familiar script: another organisation following the trend because it cannot afford to be left behind.
But KPN did not begin there.
Before an agent ever said "hello," something less impressive-looking—and far more important—had to happen:
Listening, classifying, and deciding.
KPN did not begin by choosing a model.
It began by listening.
The KPN Case, in Four Numbers
Listen Before You Automate
The team used a language-model-based system to analyse large volumes of call transcripts and chat conversations.
The data had been anonymised. The initial objective was not automation, but understanding.
Why were people calling?
How often did each need appear?
What processes were hiding behind those conversations?
Should those processes be automated, simplified, or perhaps redesigned so that customers no longer needed to call in the first place?
Technical and customer-experience teams then evaluated each opportunity according to its potential impact, cost, complexity, feasibility, and the need to keep a person involved in the process.
That analysis produced the first use cases: identity verification, order enquiries, technician appointment management, and the initial diagnosis of connection problems.[1]
AI was useful from the beginning.
It could review more conversations than any human team could possibly read. It could group topics, count recurring issues, and identify patterns scattered across millions of words.
But frequency is not the same as value.
The fact that a question appears thousands of times does not yet tell us whether we should answer it with an agent, change the process causing it, or remove the need for the customer to ask it at all.
That requires a different kind of work.
Fred Brooks wrote in 1986:
"The hardest single part of building a software system is deciding precisely what to build." —Fred Brooks.[2]
Brooks was not diminishing the importance of code. He was separating two kinds of difficulty that we often confuse.
One is expressing a solution: writing it, testing it, deploying it, and maintaining it.
The other is understanding the problem well enough to know what solution should exist.
AI is rapidly reducing the cost of the first. It can generate code, explore repositories, compare alternatives, and produce prototypes in minutes.
The second remains.
At KPN, the model helped the organisation understand. The decisions about what to prioritise remained human.
AI could find patterns.
Judgement still had to decide which patterns mattered.
As a software engineer, I have learned that my greatest advantage on the teams where I have worked has rarely been being the best programmer. I have met better programmers than me.
Nor has it been being the most articulate person in the room, or the one who knows the most technologies.
My small trick has been something else:
Trying to understand the business.
When you understand the business, you understand where the real pain is. You know what problem sits behind a feature, where time is worth spending, and what actually deserves priority.
Perhaps that is why the KPN case felt so familiar.
I work in systems technology. I write software, design architectures, connect services, and automate processes. These are the tools I know best for intervening in reality.
But I do not consider myself an engineer merely because I know how to use them.
I consider myself an engineer when I can enter a problem that is still unclear, separate symptoms from causes, and find a reasonable path from the current state to a better one.
Sometimes that path ends in software.
Sometimes it does not.
Today, as AI removes part of the technical friction, understanding the business and making critical decisions matters more, not less.
The House Move That Would Not Fit Into a Workflow
Among the situations KPN analysed, one was particularly revealing:
Moving house.
From a technical perspective, changing the address attached to a service looks like a perfect candidate for automation.
There is an old address, a new one, a date, and a set of products that need to be transferred.
It is easy to imagine the diagram: four boxes, a few rules, and several arrows.
But moving house is not merely an administrative task.
It is one of those moments when everything becomes open to reconsideration: expenses, contracts, providers.
When someone is already changing homes, changing telecom providers may feel like a relatively minor additional decision.
The customer may be most willing to reconsider their relationship with the company at precisely the moment when the process looks easiest to automate.
That is why KPN did not evaluate only whether an agent could complete the operation. It also considered which moments should preserve human involvement, particularly when the risk of customer churn was higher.[1]
Peter Drucker offered a warning that is especially useful in cases like this:
"There is nothing so useless as doing efficiently that which should not be done at all." —Peter Drucker.[3]
Artificial intelligence adds an unsettling variation to that idea.
We can now do the wrong thing faster, more cheaply, and with enough autonomy to repeat it thousands of times.
A poor process performed manually is friction.
A poor process automated can become infrastructure.
It can reduce processing times, increase volume, and produce apparently healthy metrics. The machine works. The dashboards are green.
And yet we may be doing, with admirable efficiency, something that should never have been preserved in that form.
KPN did not reject the automation of house moves.
It asked a more careful question.
The difficult question was not whether an agent could manage the move.
It was what would be lost if the agent handled it alone.
Two Seconds
Once the problems had been selected, the part we more easily recognise as technology began.
KPN needed its voice agents to respond in less than two seconds.
On a performance dashboard, two seconds looks insignificant.
During a phone call, it can be long enough for someone to think the connection has dropped, repeat the question, or say "hello?" while waiting for an answer.
Voice has no loading indicator to explain the silence.
Latency stops being an infrastructure metric.
It becomes part of the experience.
The team also worked on barge-in: the ability to let a person interrupt the agent while it is speaking without causing the system to lose context.
It is an easy detail to underestimate.
Human conversations do not respect perfect turns. We interrupt, hesitate, correct ourselves, and change direction halfway through a sentence.
A system unable to tolerate that imperfection may have a flawless voice and still feel profoundly artificial.[1]
Those requirements guided the architecture.
KPN evaluated different alternatives and selected an integrated, managed conversational platform. The decision reduced integration complexity, offered more predictable latency, and allowed the company to move quickly, although it also introduced a degree of vendor dependency.[1]
They did not choose the most flexible solution in absolute terms.
They chose the solution that best answered the problem in front of them.
There is something important in that order.
First, they decided how the conversation should feel.
Then they chose the technology capable of producing that experience.
Sometimes what we call a "technical requirement" is really human behaviour translated into a number.
The architecture did not create the judgement.
It made the judgement visible.
When the Voice Was Given Permissions
KPN was not trying to build a chatbot that merely explained how a customer could complete an operation.
It wanted agents capable of completing it.
A chatbot can say:
"You can change your appointment by visiting this section."
An agent can check availability, reschedule the appointment, and confirm the new date.
The difference takes only a few words to describe.
Operationally, it is enormous.
To make this possible, the agents were connected to core systems through standardised APIs and MCP, a protocol that provides structured access to tools and data. The architecture included layers for the agent platform, orchestration, and audio integration, and it was designed so that components could be reused across new use cases.[1]
The moment a model receives permissions, it stops being merely a language generator.
It becomes part of the operation.
A wrong answer can confuse someone.
A wrong action can alter an appointment, access inappropriate information, or leave a process in an inconsistent state.
When language receives permissions, its mistakes stop being only words.
That is why KPN introduced limits on what agents could say and do, along with observability tools, end-to-end logging, and evaluation systems combining human reviews with automated checks.
It was not enough to know whether the response sounded convincing.
The organisation also needed to know what information the agent had accessed, what action it had taken, whether it had respected its limits, and whether the customer's problem had actually been resolved.
The caution was not excessive. KPN was building agents intended to interact with more than 100,000 customers per week. At that scale, a rare error stops being a small exception.[1]
Judgement does not live inside the model.
But it can be expressed through the architecture surrounding it.
It lives in the permissions we refuse to grant.
In the actions that require confirmation.
In the information the agent is not allowed to access.
And in the moment when it must stop improvising and transfer the call to a person.
One Hundred Calls Every Morning
KPN brought minimum viable versions into production, ran tests with multidisciplinary teams, and involved real customers through a user-experience laboratory.
Then it began a cycle that, to me, contains one of the most important lessons in the entire case.
Every morning, the team reviewed transcripts from up to one hundred real calls.
There, they found unexpected expressions, ambiguities, and situations no one had imagined during the design process.
By the afternoon, those discoveries had become prompt adjustments.
The changes could be live that same day.[1]
It is tempting to attribute that speed to artificial intelligence.
The model made changing the system's behaviour cheaper. But the model did not create the learning cycle by itself.
It did not decide to review the calls.
It did not bring together people from technology, business, and customer experience.
It did not give them the authority to change the system.
Nor did it create a culture capable of admitting that a hypothesis had been wrong.
The organisation did all of that.
Agility is not simply the ability to produce faster.
It is the ability to reduce the distance between observing reality, learning something from it, and turning that lesson into change.
A company can use the most advanced model on the market and still take three months to approve a correction.
Another can work with less sophisticated technology and improve every day because it knows how to listen and decide.
AI reduced the cost of making corrections.
KPN reduced the time between listening and acting.
KPN's agility was not inside the model.
It was in the distance the organisation managed to remove between listening and correcting.
The People Missing From the Diagram
There is a common way to represent digital transformation.
Data enters through one side.
A model processes it.
An action comes out of the other.
In the middle, there are boxes, arrows, and APIs.
People are usually left outside the diagram.
But procedures, responsibilities, training, and the fears of those working inside the organisation are also part of the system.
KPN created a dedicated team to update operating procedures, develop training programmes, and support the evolution of employee roles. It also involved frontline workers in development and testing.
The company reports a success rate above 86% for its adoption strategy. As agents take over routine tasks, human specialists can focus on situations where judgement and empathy matter more.[1]
AI does not automatically free people to do more valuable work.
For that to happen, someone has to redesign the work.
Procedures, escalation paths, responsibilities, and metrics all need to change. The people receiving the problems the agent could not resolve need to be prepared for them.
Otherwise, the technology does not remove a layer of complexity.
It adds another one.
Perhaps the most important asset KPN is building is not any of its current agents.
It is the internal ability to discover opportunities, choose them carefully, build solutions, observe them in production, and correct them without starting from zero every time.
The models will change.
The platforms will change.
Many of today's agents will be replaced.
But an organisation that learns how to listen, decide, and correct retains something valuable even when all its tools are replaced.
That looks much more like digital transformation.
Not because the company has AI.
But because it is learning to solve problems differently.
A Necessary Interpretation
The Part That Is Still Ours
I will continue using artificial intelligence.
I will probably use it more and more.
It helps me research, explore alternatives, write code, and confront problems that once would have required far more time.
Ignoring a tool with that kind of power would be absurd.
But confusing the speed it gives me with the judgement I am expected to provide would be dangerous.
My field is systems technology. It is the collection of tools I know best for intervening in reality.
But I do not consider myself an engineer because every problem I touch eventually becomes software.
I consider myself an engineer because I understand that it might not.
The work begins before the architecture, when we try to understand why the problem exists, what forces keep it in place, and what change would genuinely produce a better state.
It continues as we choose between imperfect alternatives.
And it begins again after deployment, when reality reveals which parts of our solution were correct and which merely sounded reasonable inside a meeting room.
The most important lesson from KPN is not that every company should build voice agents.
It is that, before building them, someone had to listen to millions of conversations and decide which ones mattered.
Then someone had to choose what not to automate.
Translate human experience into technical constraints.
Accept architectural trade-offs.
Surround the model with boundaries.
Listen to real calls.
Correct the system quickly.
And prepare the organisation to work differently.
Artificial intelligence was present throughout the journey.
But it did not bring the judgement that gave the work direction.
Nor did it bring the agility that transformed mistakes into learning.
Those are not features of a tool.
On the other end of every call, there is no "use case."
There is a person whose day has been interrupted.
Remembering that may be the first act of engineering.
Before the agent, someone had to listen.
That part is still ours.
Sources and Further Reading
McKinsey & Company and QuantumBlack. How KPN Is Building an Agentic AI Engine for Customer Care. Case study published June 24, 2026.
Frederick P. Brooks Jr. No Silver Bullet: Essence and Accidents of Software Engineering. University of North Carolina at Chapel Hill, 1986.
Peter F. Drucker. Permanent Cost Cutting. The Wall Street Journal, January 11, 1991; archived by the Drucker Institute.
