The roadmap reflex
When a company says "we want to adopt AI", the first reaction of the management system is almost always to turn that into a roadmap. The familiar sequence appears: research, MVP, pilot, rollout, scaling. Such a plan can be useful, but it answers only one question: what are we going to do?
A more important question sounds different:
What must our activity become, so that we can do what we currently cannot do?
These are different levels of thinking. Planning assumes the existing organization is already capable of performing the task and only needs an order of steps. In the case of AI this is often untrue. AI requires not simply a new tool, but a new operating logic. It changes how the company formulates tasks, collects data, assesses risk, makes decisions, distributes responsibility, and verifies results.
That is why many AI initiatives break down not at the level of the model, but at the level of the activity.
Where AI initiatives actually break
For example, the business may say: "we need to automate support", while the engineering team hears: "we need to embed a chatbot". The data team is responsible for the pipelines, but nobody is responsible for the meaning and the quality of the data. Lawyers are brought in at the end, although the constraints should have shaped the design of the solution from the very beginning. The KPIs of product, sales, support, and compliance can contradict each other. A team can build an MVP quickly, but have no procedure that allows it to be safely turned into a standing process.
In that situation the problem is not that the roadmap is bad. The problem is that the roadmap is being built on top of a system that is not capable of producing a good AI solution.
The honest diagnosis
The honest diagnosis then sounds like this:
The current system of activity does not allow AI to be realized — regardless of budget.
This is an important shift. We stop thinking only about the project and start thinking about the machine that produces projects.
There is a simple analogy. Writing a document is one thing. Writing the operating system inside which documents are created, updated, reviewed, and used is another. Most AI initiatives are trying to write a document: a strategy, a roadmap, a list of use cases, a set of recommendations. But real transformation requires rewriting the organization's operating system.
In other words, the result of the work should not be a PDF with conclusions. The result should be a new executable protocol of activity.
What a protocol has to answer
Such a protocol answers practical questions.
This is the transition from managing an AI project to programming the future work. At this level AI stops being merely a tool for generating answers. It becomes a way of designing the system that produces better answers.
Object, process, meta
Here three levels can be distinguished.
Object level
At this level the task itself is discussed: which use case to choose, which model to use, which product to launch, which decision to make.
Process level
Here the decision process is discussed: who participates, how the discussion runs, which data is used, who makes the final decision, how risks are recorded.
Meta level
At this level the system of collective thinking is designed: what the organization must become so that next time it can make better decisions without outside help.
What this means for multi-agent systems
Most modern AI systems work at the first level. They help find an answer. More mature systems begin to work at the second: they help structure a discussion, summarize meetings, compare arguments, record decisions. But the most interesting level is the third. There AI helps rebuild the very way answers are produced.
This matters especially for multi-agent systems. Often they are arranged as a set of agents that argue, check each other, and try to arrive at a better solution. But a stronger architecture should not only search for the best answer inside a given process. It should be able to notice that the process itself is bad.
For example, the system should not simply say: here is the best AI use case. It should be able to say:
You cannot choose an AI use case correctly, because you have no data owner, risk criteria are undefined, legal joins too late, and your teams' KPIs conflict.
And after that it should offer not only a recommendation, but a new protocol of work: new roles, rules, stages, conflicts, criteria, and feedback cycles.
A deeper role for the model
In this sense the future role of an LLM in organizations can be far deeper than "assistant", "copilot", or "moderator". An LLM can become the mechanism that helps an organization see its own activity, find the gaps inside it, and synthesize new ways of working together.
Where transformation actually starts
Final thesis: real AI transformation does not begin when a company adopts a model, and not when it launches its first pilot. It begins when the company changes the system of activity inside which those models, pilots, and decisions become possible at all.
AI should not only help to answer questions.
It should help to build the machine that will ask better questions, collect better data, create better conflicts, and make better decisions.
Get the next plate in your inbox.
One strategic memo or weekend-buildable AI product idea per week. No noise. Confirm your email to activate the subscription.
Working on AI transformation?
If you are building, managing, or advising AI transformation inside a company, I'd love to compare notes.
Where does it break for you — tools, workflows, org design, or decision-making?
