Ok, hand on heart: when I read articles about AI in the enterprise today, it is always about the same things. Chatbots, language models, governance, compliance, security, and how to get all of it into the existing IT. All important, no question, I write about it myself. But sometimes I wonder whether we are losing sight of the goal. We build ever better chatbots, put ever more control around them and discuss how to monitor the answers. Was that the task? We did not want to manage chatbots. We wanted to solve problems.
Was that the task?
I regularly sit in workshops with companies that want to know where AI helps them. The first reflex is almost always the same: a chatbot on the website, an assistant in the intranet that searches documents. That is not wrong. It is just rarely what hurts. What hurts is the process where for years someone has been collecting data from three systems by hand, because the three systems do not talk to each other. Nobody in the workshops talks about that, because it does not sound like AI. It sounds like work.
An order comes in
Take a perfectly normal business process, one I know from a telecommunications project. An order comes in. Data has to be checked, information collected from various systems, decisions made and further steps triggered. Today several people and several applications are involved, and the edge cases land with the two people who have known them for years.
Now we integrate a chatbot. The employee can ask questions about the order, search documents, have the status explained. That is an improvement. But the process is the same. The work still has to be done, the systems still have to talk to each other, and someone has to make sure the next step actually happens.
Why should the AI only answer questions here? Why does it not recognise by itself which information is missing, which step is due, and trigger it? For the telco process I described that as a proposal: edge cases are not random, they have patterns, and an agent that knows the patterns can prepare a large part of them before a human looks. That is where the saving lies. Not in the dialogue window.
The problem is not the model
We have models today that write code, analyse documents, recognise connections. Still, many projects fail at turning a prototype into a solution that runs every day. Why? Because a company does not consist of information. It consists of business rules, dependencies, departments, security requirements and applications that have grown over decades. A model does not know that. And just because you give it a thousand documents does not mean it has understood the architecture and the processes.
I saw that at full scale for the first time at a large telecommunications provider, long before it was called AI: the data is never in one place and never in one form. Customer data here, contract data there, usage data in a third system, each with its own truth. And the first question I have asked in every first conversation since is not which model, but: who is responsible for the data with you? If the answer is "that is distributed", the project fails, no matter how good the model is.
Knowledge is not the amount of information that fits into a context window. Knowledge has to be built, structured and kept available: which systems are involved, which data belongs together, which rules apply, which dependencies exist, and what happens when you change a process. That is exactly the first step in every one of our projects, and exactly why we built NeoCoder so that an agent first gets to know the system before it touches the first line. Without that understanding no automation arises. Only another application that at some point nobody understands anymore.
AI needs architecture, not just context
This gets too little attention in the discussion. Everyone talks about bigger context windows, better models, more capable agents. But a big context window does not replace software architecture. Whoever gives an agent ever more information, tasks and responsibility without separating them gets a system that works as long as nothing happens. It gets problematic with the next requirement, the first change, the first error. Then it shows whether you have a maintainable solution or an impressive prototype.
That is why the same principles apply to AI that have made good software for decades: clear responsibilities, modular components, defined interfaces, traceable flows, clean separation of the business domains. Plus a structured knowledge base that specialised agents access deliberately. Not every agent has to know everything. It has to know what it needs for its task, and recognise when it has to involve other components or humans.
That is also the reason we do not use one big model for everything, but many small ones for one task each. A model that assigns company descriptions to around 900 categories is small, runs locally and does exactly one thing. Fifty such models are easier to understand, test and replace than one that can do everything and where nobody knows why it answers differently today than yesterday.
And governance?
Of course we need governance. As soon as AI executes tasks on its own or accesses systems, we have to know what it may do, what it did and why. Permissions, logging, clear responsibilities. A week ago I described what happens when the guardrail is missing in a single place: 169 overwritten files, by an agent that only wanted to deliver.
But should we build an ever larger administrative architecture around a chatbot for that? Or build security and control into the architecture of the processes from the start, as permissions an agent does not have, instead of rules it is not supposed to follow? For me the answer is clear. Governance is a prerequisite. It is not the goal. A secure chatbot is not yet process automation. The added value only arises when the AI understands the business context, executes tasks reliably and stays within clear boundaries.
First understand, then simplify, then automate
And here it gets interesting. We should not be satisfied with executing existing processes faster. Perhaps they have long been unnecessarily complicated. Perhaps information is captured three times. Perhaps a work step exists only because two systems do not talk to each other. Perhaps delays arise from decisions that could be automated with clear rules. A good solution helps to find exactly these places before you automate them.
That is how we proceed, and that is how we did it with the test data for a public authority: not everything at once, but a prototype that solves one problem, then look again with some distance, find three mistakes, and only then continue. And when requirements change, the solution has to be able to evolve without starting from scratch. That is a more sensible approach than the question of which chatbot to introduce next.
How to measure it
In the end a customer does not care how many agents we use or which model runs in the background. He wants to know what gets better.
Are orders processed faster? Not the chatbot's response time. The throughput time of the process, from receipt to completion.
Does the error rate drop? Fewer queries, less rework, fewer edge cases landing with the two people who know them.
Do employees have to do less by hand? Less typing, less collecting, more deciding.
Can new requirements be implemented faster? That is the test for the architecture. If every change is a project, it was a prototype.
Does the solution get cheaper and easier to maintain in the long run? An AI solution that impresses today and can only be adapted with great effort tomorrow is not a good investment.
What stays
Perhaps we should remember again why we build software at all. Not to use as many technologies as possible. Not to try every new model. Not to integrate as many chatbots as possible. We build software to solve problems. AI gives us possibilities for that which did not exist three years ago: build knowledge, analyse connections, deploy specialised agents, automate processes across system boundaries. The requirements stay the same: thought-through architecture, clear business structures, reliable functions, solutions that can evolve.
And sometimes the best solution is not an agent. Sometimes it is a simple improvement of an existing process that someone has been proposing for years and that never got budget because it does not sound like innovation. I say that too, even when it costs me the job.
The future of AI in the enterprise will not be measured by how intelligently the chatbots answer. But by how reliably we solve real problems with it, improve processes and move companies forward. First understand, then simplify, then automate, then measure. That is what we should focus on. If you have such a process that has been hurting for years: write to me. The "Meet" page says how.
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by a twin model of my own, trained on my texts. Sometimes that turns into a mix. Of course I read everything again, but nobody is infallible. Whatever stays in is mine too.