Hey guys, um, in my last blog ‘I’m completely done with LLMs in the enterprise’ I apparently struck a nerve. Never in the history of TTS have I had close to 85k impressions on a blog on LinkedIn. Totally unreal, because what I write is not meant for the masses. I write for fellow practitioners who genuinely want to make agentic AI work. But apparently, this is a topic that triggers something in all of us.
We instinctively know that we – and by we, I mean the Enterprise AI grunts – are operating at the frontier of bloody unsexy AI. Yet we enjoy it, because it gets our creative engineering juices flowing. We are the poor bastards management lined up to turn this half-baked language transformer into something an enterprise might actually trust with more than rewriting an email.
Am I saying that an LLM has no place inside the corporate machine?
Nah, of course not.
It is one of the most beautiful inventions I have encountered in a very, very long time. It outclasses the social-media boom of the 2000s – yes, there was a time before social media – and perhaps even the rise of e-commerce in the 1990s. The most beautiful thing, at least for me, is that since November, 30th 2022, I no longer have to explain what AI is, though I still have to explain what machine learning is, but at least now I can shrug and say, “Ah, never mind. It’s just AI.”
Language Models have essentially become a household name and, increasingly, a generic term for AI itself – much like Luxaflex, Aspirin, Thermos (yes, that is a brand) and Post-it. But when you start equating AI with an LLM, every problem looks like a language problem. So we are increasingly forcing a model that was trained on language to execute workflows and operate tools, coordinate stuff or even make decisions and, eventually, run entire enterprises or “zero-human companies”, as if predicting the next word were somehow the same thing as understanding how an organization works.
Well, we all know that it ain’t.
People like Yann LeCun have been telling us for years that autoregressive language models are a dead end on the road to human-level intelligence. Even Sam A. declared that we were reaching the end of the era of building giant models through brute-force scaling. That was, naturally, before Kimi came along with a reported 2.6-trillion-parameter Mixture-of-Experts model.
But LeCun’s deeper argument isn’t so much that language models are useless, but that language alone is an inadequate representation of reality. An LLM learns how humans describe the world. It does not necessarily learn how the world itself behaves.
That is why attention is now shifting towards other architectures and other kinds of foundation models. Things like World Models* attempt to learn representations of actual physical environments, and the associated dynamics and actions. LeCun’s JEPA-style architectures, for instance, learn by predicting abstract representations of missing or future states instead of reconstructing every pixel or predicting the next token, and NVIDIA Cosmos applies a related ambition to physical AI where it is building models that are designed for simulation and physical reasoning and the consequences of actions in domains such as robotics and autonomous systems.
But alongside these broader world models, there is an explosion of specialized foundation models trained on the native data of a specific domain. The number of papers I’m tracking in this domain are growing with an ever increasing speed. Take for instance SensorFM that learns from wearable sensor data or Evo 2 that learns from DNA. ESM3 learns from protein sequences, structures and functions, and weather models learn from atmospheric states, materials models learn atomic structures and forces or robotics models that learn from observations, trajectories and physical actions.
My own CoordinationFM belongs to this ever growing family.
It does not use language as its primary representation of the world. Its world consists of process states, events, dependencies, controls and compliance. Evo2 develops a representation of the genomic world and ESM3 develops one of the protein world and likewise CoordinationFM develops a representation of the coordination world inside an enterprise.
Yeah, I know. It is slightly tragic if you are an AI condemned to experience reality entirely through the lens of protein sequences. Then again, most humans experience reality through LinkedIn, so perhaps the protein model got the better deal.
What we will increasingly see is a market moving towards these specialized models, and those models will inevitably find their way into our enterprises.
But nonetheless, I call it just an evolution.
The pundits predicted it several years ago, but the movement is now gaining momentum. Give it a few months and everyone will claim they saw it coming.
So, when I started working on CoordinationFM, I genuinely believed I was operating at the bleeding edge of enterprise AI – to boldly go where no one had gone before – and I could already picture myself delivering the keynote at NeurIPS, presenting the architecture at ICML, defending the mathematics at ICLR and of course confusing an entire Gartner audience until a consultancy repackaged it three years later as a colorful maturity model.
For me, CoordinationFM was already ambitious enough, a foundation model that wasn’t trained on language, but the underlying geometry of enterprise coordination instead like process events, handovers, controls and outcomes. It would learn how the enterprise actually moves instead of words that just describe it.
But behind CoordinationFM sat an even more outrageous idea which I call the Friedmann-Gleichung Machine, or FGM for short, that was supposed to be the next step after the foundational model boom. I wrote a paper about it** and then tucked it away safely, and I intended to unpack it within a year, once the foundation-model evolution was merrily underway, so I could do a “Verstappen” again.
The name behind the FGM was partly inspired by the Friedmann equations, which describe how the universe evolves and expands from a set of initial conditions. It was also a deliberate nod to the Darwin Gödel Machine which is an experimental architecture combining evolutionary exploration with systems capable of modifying and improving themselves. So, it’s about creating something from nothing, and an evolution from where we are now. The purpose of the Darwin Gödel Machine is that it evolves better versions of its own code, but I intended the Friedmann-Gleichung Machine to be a tool that would continuously reconstruct, generate and improve the enterprise itself, like anever evolving enterprise brain.
The FGM would begin with the enterprise’s existing reality like its processes, policies, controls, systems, data, roles, decisions, documents etc. and from these fragments, it would construct a dynamic representation of how the organization actually works and then, it could generate or redesign workflows or applications, with controls and interfaces and operating structures – and continuously update them as the enterprise changed. It was supposed to be paradigm shift from where we are now into a living computational model of the organization, with equal parts enterprise brain, part operating system and part generative transformation engine.
I honestly believed this was still at least a year away.
First, specialized foundation models would have to establish themselves in corporate life. Enterprises would need to understand that language is only one modality, and that models can also be trained on processes, coordination patterns, transactions, controls and operational behavior. Then, gradually, those different pieces might converge into something resembling the FGM.
I was so convinced of that timeline that I intended to build my long-awaited PhD around it, with the model, the architecture, the mathematics, the enterprise implications – the whole glorious academic ordeal. I had already written half a book about it.
Well, that was, at least, the plan.
Until this guy, Mario Schlener, part scientist, part evil genius, walked into the room and demonstrated what I can only describe as the Friedmann-Gleichung Machine already operating in practice.
My reaction at that moment was divided rather elegantly between exhilaration and personal devastation.
I had goosebumps because I watched the future arrive in real time, but at the same time, throughout the first half of the meeting, I was apparently swearing under my breath at a volume just loud enough to be heard, but low enough to remain technically professional. There is a peculiar joy in discovering that your most ambitious idea is possible, but there’s also horror in discovering that somebody else has already built the bloody thing, and that is why I am now including a picture of the man’s evolution, from corporate keyboard warrior into enterprise rockstar, just to get back at him. . .
Specialized foundation models is the next evolution of AI, and what Mario showed me is nothing less than a revolution, and in this piece, I will explain what that revolution is all about, and I think it will be televised as well, as it was on 11/30/22.
For some reason, mr Meeseeks looks just like Mario. . .
*Read:
- Controllable World Models are here and of course everyone is pretending they always wanted this | LinkedIn
- World Models are the next evolution of AI | LinkedIn
*All the papers I mention can be found at eigenvector/research
The enterprise is having its ChatGPT moment
The enterprise is having its ChatGPT moment, my smart friend, and one day, you may remember this as the place where you first saw it coming.
History usually arrives disguised as something ordinary.
On 30 November 2022, my world changed, and most people believed they were looking at a chatbot. In hindsight, they were looking at a new computational abstraction that changed our world. ChatGPT was never merely about generating text. It fundamentally changed the relationship between humans and software. In the past, we had to adapt to computers. We had to learn their interfaces and commands and programming languages and their strange little rituals. Then, suddenly, the computer began adapting to us.
The remarkable thing wasn’t that ChatGPT could answer questions because Google had been doing that for years with their search engine, but the real breakthrough was that language itself had become executable. You could describe what you wanted, and then the computer would attempt to make it happen.
Attempt. The caveat, indeed.
Everything that followed, from those darned copilots we’re now cursed with to coding assistants and autonomous agents, all of that was merely a consequence of that architectural shift.
And I believe enterprise AI is standing at a remarkably similar point today.
But the frontier guys are still obsessed with larger, sexier models, bigger context windows, smarter agents and increasingly elaborate orchestration frameworks. And those are truly interesting developments, but they increasingly feel as though we are discussing faster horses when someone else is inventing the automobile.
I really think that the discussion is taking place one layer too low.
For the past fifty years, enterprise software has digitized almost everything except the enterprise itself. We digitized transactions, and workflows etcetera, and every generation improved something. ERP transformed finance and operations and CRM transformed sales, BPM did the same to workflow automation and Cloud computing made infrastructure elastic and too expensive.
And yet, organizations still require meetings to explain themselves.
I think that I spend roughly half of my working time in meetings, retelling the same story, just to get people aligned, and I’m sure that the more program oriented readers among you, are wasting even more time on this, and that includes emails, Teams, Slack, the intranet and of course good ol’ PowerPoint.
And that should strike us as slightly strange.
The average large enterprise owns millions of documents with thousands of applications and when you’re lucky also hundreds of process models and enough PowerPoint presentations to block out the sun. It has immense databases that contain nearly every transaction it has ever performed, and policies that explain what people are allowed to do, organizational charts about who is supposed to do what, and dashboards that try to tell us why none of this happened according to plan.
But when you ask it a seemingly simple question like ‘Why does this process work this way?’ um, yeah, and suddenly the organization develops collective amnesia.
And that is because documents, and search is not about ‘understanding’.
A process description is evidence that coordination once happened, but it is not coordination itself, and along the same line of thought, a policy is a fossil that is left behind by organizational behavior. It may be incredibly valuable, but it is not the living organism.
So, someone reading this could perhaps conclude that the enterprise never actually existed inside the computer.
Perhaps we have only stored observations of it.
And here’s the funny thing. For decades, we have convinced ourselves that enterprises are collections of systems.
But no, they’re not.
They’re collections of . . . agreements.
SAP does not make your company work and neither does ServiceNow, or Salesforce for that matter, or Teams and so on. Those are systems that merely record or support agreements that people have already made.
And the enterprise itself lives somewhere else.
It is in the coordination between people, processes, engineering constraints, regulations, customer expectations, your suppliers, the systems and thousands of exceptions that the collective has accumulated through years of experience.
By the way, have you ever asked a process owner why a particular approval exists? Then you have probably heard one of my favorite answers in enterprise computing . . .
“Honestly, I’m not sure anymore.”
Read that sentence again.
“Honestly, I’m not sure anymore.” No, I didn’t mean it literally. . .
The person that is responsible for enforcing the process does no longer remember why the process exists, yet we somehow expect AI to reconstruct the original reasoning from a Visio diagram, three contradictory policy documents and an email attachment last updated in 2017.
Yeah, well, good luck mate. That’s why they hired us, right?
Every idea inside a large organization begins innocently enough. I started the factory concept because I wanted to improve processes at scale using intelligent executing. That idea than became a PowerPoint, which in turn led to a meeting that produced meeting notes. Then those meeting notes became requirements, which turned into user stories that led to architecture diagrams. The diagrams ultimately became software and that software now produces dashboards, and finally, I am now at the point where I’m creating a PowerPoint to explain that the transformation has been successful.
But the thing is that somewhere during that journey, the original intent behind all of this evaporated, because we have no institutionalized brain and memory.
Modern enterprises are astonishingly good at translating organizational knowledge from one format into another but at the same time, they’re surprisingly poor at preserving the reasoning that created it in the first place. We can trace what somebody wrote or what a system produced, with nanometer precision but we often cannot reconstruct why they made those choices in the first place.
That, my eloquent friend, is the world’s most expensive game of telephone.
A strategic objective begins in the boardroom and travels through management layers and transformation programs, process designs, requirements, controls, software and operating procedures, and by the time it reaches execution, it has mutated into something that is loosely related to the original intention.
Then we build a dashboard to measure the mutated version of the intent.
The thing is that AI can now read nearly every record the organization has ever produced. It can summarize policies, retrieve procedures, analyze meeting notes and compare process descriptions. That is useful. Sometimes enormously useful. But the darn thing still struggles to understand why those documents exist.
The problem is almost embarrassingly simple . . . we have mistaken information for understanding.
Owning a cookbook does not make you a chef, despite what I personally choose to believe, and reading every medical textbook ever written does not qualify you to perform heart surgery.
And equally so, Knowledge is not understanding.
And understanding is not judgement.
Modern enterprise AI assumes that if we ingest enough documents, that understanding will somehow emerge. But no, it won’t. Documents capture what somebody believed at the moment they were written, but they rarely explain why the organization behaves the way it does today.
And that is partially due to the fact that reality changes faster than documentation ever can.
The average enterprise process begins drifting away from its documentation almost immediately after approval because regulations, systems and markets change, but most of all because employees simply invent shortcuts, customers introduce new requirements and your enterprise acquires other companies. Before long, the official documentation is historically interesting rather than operationally accurate.
And then the enterprise compensates that in the only way it knows how.
It starts . . . talking.
Meetings are not merely evidence that documentation failed, but it is the enterprise that is attempting to rebuild context. Every architecture review, steering committee, workshop, stand-up and alignment session is essentially a federated cognition engine. Humans bring fragments of reality into a room and attempt to reconstruct a shared understanding of what is happening, why it is happening and what should happen next.
This is why enterprises continue to spend billions on meetings despite the fact they possess oceans of data and documentation. They are required to synchronize mental models. The enterprise constantly has to reconstruct itself inside the minds of the people running it because no technical system maintains a sufficiently complete representation of the organization as a whole.
And I think that this is the observation we have been missing for fifty years.
That the enterprise is not a database, and it’s not an application landscape either. It ain’t even a collection of workflows, but instead it is a continuously evolving cognitive system. Yes, an enterprise is a living coordination network in which thousands of decisions are made, postponed, or (usually in my case) ignored every minute, and those decisions ripple through the organization from departments, suppliers and regulations to software systems and human relationships, and that web of interactions is what keeps the enterprise alive.
Now, language describes fragments of that web.
Our documents capture snapshots of it, and our databases record selected transactions within it with process models simplifying parts of it. But none of them is the enterprise cognition itself. We have spent fifty years automating the visible artefacts of the enterprise but we have left the underlying coordination largely dependent on human beings.
We digitized everything, but humans remained the cognitive runtime.
Now, if that is true, then we must conclude that we’ve been trying to reconstruct a living nervous system from the paperwork it leaves behind, and that leads naturally to the following question . . .
If documents are not the enterprise, systems are not the enterprise and workflows are not the enterprise, then what exactly is?
That is the question that – in the words of Julian Goldie – changes EVERYTHING.
Because the real problem enterprise AI has to solve is not language nor search or agentic automation, but it is to understand what the enterprise currently is, why it behaves the way it does and how it must change without losing coherence along the way. And when your computer can maintain that kind of living representation, than the enterprise will have its real ChatGPT moment.
And we are close. Very close.
More rants after the messages:
- Connect with me on Linkedin 🙏
- Subscribe to TechTonic Shifts to get your daily dose of tech 📰
- Please comment, like or clap the article. Whatever you fancy.
LLMs were never supposed to run a company
I am about to commit another act of technological heresy, as if last week’s blog wasn’t enough.
Our dearly beloved Large Language Models, though they are astonishing feats of engineering, were never supposed to run a company. They are designed to predict language but not to coordinate thousands of systems with complicated regulations and conflicting interests in real time, but apparently, the industry decided that predicting the next word was close enough to running a multinational corporation, provided the demo contained enough animated arrows and ‘woosh’ sounds.
This is not meant as a criticism of LLMs. Criticizing a language model for failing to run an enterprise would be like, um, blaming a Formula One car for being unable to cross the Atlantic. It’s an extraordinary machine, but it just belongs to a different category, although I think someone is probably already preparing a PPT titled Transatlantic Mobility Through Formula One Transformation.
Language models predict language, and they do so very well, and everything else they can do follows from that capability. And then we started to assume that if a model understands language well enough, perhaps it could also understand organizations. After all, organizations produce documents that contain words and LLMs understand words, so the enterprise would presumably be able to run itself once the chatbot has been connected to SharePoint and a database through some tools.
But no.
Unfortunately, an organization is not a paragraph, nor is a document repo an ERP system. It is not even the sum of all those things. An enterprise is a living coordination network in which thousands of decisions are continuously made and they ripple through departments and regulations and software systems and human relationships. That shifting web of interactions is what keeps a company alive. And language merely describes fragments of it, usually several weeks later.
Take this example. . .
Say, you have to read every aviation manual ever written, including every checklist and the maintenance procedures plus the accident reports and engineering specs. You would acquire an extraordinary amount of information about aviation, but you would still not understand exactly how Heathrow Airport operates on a rainy day, or that your copilot called in sick and that the aircraft you were supposed to board would arrived late or that a flight controller just prevented a minor problem from becoming a major one.
The manuals describe the system, but they do not contain the system’s live coordination state.
Now, that same distinction applies to our companies.
Enterprises continue to spend billions on meetings even though they are possessing oceans of documentation because meetings are not merely information exchanges. Admittedly, many of them could have been emails (duh), but their real purpose is synchronization between people. Us humans use the meetings to reconstruct a shared mental model of reality and negotiate priorities, and in my case, decide which official rule should be ignored this week. Now, that shared (and constantly updated) model is what actually runs the organization. The documentation always follows behind, recording a reality that stopped existing before someone clicked “Save.”
At one point, Retrieval-Augmented Generation appeared to offer a solution.
RAG was one of the smartest ideas to emerge during the first wave of enterprise AI because it addressed an obvious limitation that language models knew many things, but they did not know your things and that giving them access to internal documentation made them dramatically more useful. But the mistake was that we assumed that the journey had ended because the chatbot could finally locate something like a travel-expense policy.
Now, RAG retrieves documents that are statistically relevant to a question.
It does not, however, reconstruct organizational intent or understand dependencies between teams or, say, know that Finance ignores paragraph 17 because Legal approved an exception following a supplier dispute in 2021. It can retrieve the official policy, but it cannot automatically recover the relationships and unwritten agreements that determine how the policy is actually applied. The information has been found, but the organizational understanding still needs to come from somewhere else, usually during one of the meetings AI was supposed to eliminate.
That’s why the current tech will not allow us to create 100% Zero Human Companies.
This is also why enterprise AI demonstrations appear magical during their first five minutes and strangely familiar after five months. The chatbot answers questions, summarizes reports and finds procedures, and everyone applauds because search has acquired conversational skills. Then somebody asks which operational process should be changed to reduce customer lead time without violating export regulations, disrupting production or increasing financial risk, and usually at that point, the magic leaves the room.
The real problem is not the retrieval itself but the representation. Enterprises are not libraries but they’re living systems whose behavior emerges from relationships, and here, processes depend on other processes and decisions influence other decisions and then controls exist because something unpleasant once happened somewhere else. These relationships are rarely documented explicitly, partly because everyone assumes somebody else understands them and also that documenting reality would interfere with the important work of attending meetings about documentation.
Hahaha… ok. Cynicism off
Giving an LLM access to every corporate document is therefore the same as giving someone access to every book ever written about football and asking them to predict next Sunday’s match. That person might know everything about sporting history and things like tactics but they still would not know who is injured and how strictly the referee will apply the rules.
Static knowledge is valuable, but dynamic understanding determines the outcome.
Documentation primarily explains yesterday, whereas operations are happening today. The future emerges from the interaction of thousands of moving parts and no amount of document retrieval can capture that reality completely, although increasing the vector-database budget will undoubtedly be proposed before anyone admits it.
And this is where LLM Wiki and its enterprise derivatives is a promising next step. It is a serious attempt to create an enterprise cognitive layer, a shared and continuously evolving representation of what the organization knows, how its different parts relate and why particular decisions, rules and exceptions exist.
The ambition behind the wiki is to connect documents with processes, decisions, systems, people, events and operational context. A policy then becomes more than a passage in a PDF because it’s now part of a network that can show who owns it and which processes depend on it. That is considerably closer to organizational understanding than returning the five most statistically relevant chunks of text and hoping the answer happens to be hiding among them.
But LLM Wiki should not be mistaken for a finished artificial brain for the enterprise. No system can automatically capture every informal agreement or improvised operational decision. However, it is a credible attempt to build the missing layer between scattered information and genuine organizational intelligence. It begins to turn isolated fragments of knowledge into a connected model that both people and AI can inspect, enrich and use.
Language remains the shadow cast by the organization rather than the organization itself.
Attaching a chatbot to a document repository therefore does not give an enterprise a brain, but only gives the filing cabinet excellent conversational skills. LLM Wiki is an attempt to go further by constructing something the chatbot can actually think with.
No, what I saw Mario demonstrate adds goes deeper. . .
A brain without hands is still just a library
With LLM Wiki we begin to construct something that an AI can think with. But understanding the enterprise is still only half of the problem, because sooner or later something has to happen. A process may need to be redesigned or an application may need to be built, and at that point, most enterprise AI systems hand the doing back to a human.
The AI may have reconstructed part of the context and produced a surprisingly intelligent recommendation, but someone still has to update SAP, redesign the process, configure the workflow and build the application. Human beings must still translate the policy into controls and determine what information must be collected to build a solution that matches the original intent.
In other words, the AI understands what should happen, but the enterprise still needs an army of people to make it happen.
That is useful, of course, but it is still not an Enterprise Brain.
It is an exceptionally well-informed librarian who has read every book in the building, knows precisely where everything is stored and can provide a remarkably compelling explanation of why the building is on fire, but unfortunately has no arms and therefore cannot reach the extinguisher.
A brain without hands is still just a library.
And that is where our next architectural leap begins.
A true Enterprise Brain cannot stop at understanding information. It must be able to translate that understanding into coherent changes across the organization and it needs to be able to interact with the same systems, processes and applications that us humans currently use to keep the enterprise moving.
And no, that does not merely mean attaching a few tools to an LLM and declaring victory because the chatbot can now create a ServiceNow ticket.
Yes, tool use by a LLM is valuable, but executing an isolated action is not the same as changing an enterprise. Running a company is not a longer version of booking a restaurant or updating a spreadsheet, and this is the difference between what you’re shown in the demo and what is happening in real life, where every meaningful action takes place inside a network of dependencies, constraints and . . . consequences.
The agents that I’m currently working with are becoming increasingly capable of completing individual tasks. They ain’t perfect, but they can generate code, update records and operate software interfaces. Those are impressive capabilities, but they remain local acts of intelligence. An enterprise does not become autonomous because thousands of agents can independently perform thousands of tasks.
That is the difference between an agentified process based on an LLM, those agents simply automate fragmentation at industrial scale, and an Enterprise Brain, with a shared representation of organizational intent and state, including the capability of execution.
The missing piece is an architecture that connects understanding and execution through a living representation of the organization. Before the system performs an action, it should understand why the action is required, which objective it serves, which constraints apply, which systems and processes are affected, and what evidence will demonstrate that the outcome is both correct and compliant.
After execution, the results should flow back into that same representation.
Then the Enterprise Brain observes what happened, compare the outcome with the original intent and update its understanding of the enterprise and when reality differs from the expected outcome – which it will, because reality has never shown much respect for transformation roadmaps – than the system should be able to detect that divergence and determine whether the process, control, application or even the underlying organizational model must change.
This creates a continuous loop between understanding and action.
The enterprise describes itself through documents, processes, systems, decisions and execution traces. The system uses those fragments to reconstruct how the organization currently works and from that representation, it can determine what needs to change, generate the necessary operational structures and observe whether those changes produce the intended result. The outcome then becomes new evidence that improves the representation.
The model is therefore never complete, because the enterprise itself is never complete.
It changes whenever a regulation is introduced or when a customer changes direction, a system is replaced, a control proves ineffective or an employee discovers a shortcut that works better than the official process. A genuine Enterprise Brain must evolve with those changes instead of waiting for the next transformation program to rediscover them eighteen months later during a workshop.
That is why this cannot be just another knowledge-management platform. Knowledge-management systems preserve what the organization knows, but the machine I am describing must also preserve why that knowledge matters, how it relates to current operations and what behavior should follow from it.
It must understand that a policy is not merely a document but a collection of constraints and intentions. It must also understand that a process is not merely a diagram but a sequence of coordinated state changes that is involving people, systems, decisions and exceptions. Most importantly, it must be capable of turning that understanding into something executable.
If the organization changes, say, a policy, the system should be able to identify the affected processes and applications, controls and even roles. It should then be able to propose or generate the necessary changes, simulate their consequences and determine where human judgement remains necessary and once those changes have been approved, it should be able to implement them across the operational landscape and continuously observe if they work as intended.
This, however, does not mean removing humans from the enterprise.
We’re only removing them as the compulsory translation layer between every organizational intention and every piece of software that is required to execute it.
When we’re implementing strategy, we translate that into programs that aim to change processes, leading to system requirements that produces software which hopefully changes operational behavior. And every one of these translation steps introduces delay, individual interpretation and the possibility that the original intention will mutate into something completely different, and by the time the finished solution comes into production, we all wonder if it still solves the original problem.
An Enterprise Brain with hands would compress that translation chain.
Strategic and operational intent would remain connected to the processes, applications, controls and agents generated from it. When the intent changed, the system could trace the consequences through the organizational model instead of forcing another group of consultants to reconstruct the entire puzzle from workshop notes and color-coded sticky notes.
The importance of this goes far beyond faster automation.
The moment when understanding and execution all share the same underlying model, then governance also changes. Controls no longer have to be added after the solution has been designed, because they can be generated as part of the solution itself.
Evidence doesn’t have to be reconstructed after execution, because it can be captured continuously and compliance no longer consists solely of proving that someone once designed the correct process, but by simply observing if the organization continues to behave within its intended boundaries.
Even human involvement becomes more precise. We are now inserting people into every workflow because we don’t trusts the system (HITL), but with a true actionable Enterprise Brain, human judgement can be positioned where uncertainty, impact or responsibility would require it. Routine decisions can be automated and ambiguous decisions can be escalated and high-impact decisions can remain explicitly human.
The objective is not maximum autonomy like with Zone III autonomous agentic AI, but it is COHERENT autonomy, and yes, that distinction matters, because the enterprise does not need thousands of agents enthusiastically doing things. It needs a system that is capable of making damn sure that everything is being done, still contributes to a shared organizational purpose.
Agents are therefore also not the brain. They are the muscles. The applications, workflows and interfaces are the limbs. Policies and controls define the boundaries within which movement remains acceptable. Evidence provides the sensory feedback needed to determine whether the action produced the intended result.
But none of those components can coordinate itself. For that, the enterprise requires a living computational representation of its own structure, constraints and behavior, a model that is capable of understanding the organization, generating what it needs and learning from what actually happens.
And this is where the Enterprise Brain is an entirely new operating model for enterprise computing.
But I’ve been keeping you in the dark for too long.
I’m sure, your question is what the bloody thing would actually have to look like.
What would an enterprise brain actually look like?
To start with, an Enterprise Brain would not be a single model.
I know that this is slightly disappointing, because the AI industry has trained us to expect that every major breakthrough arrives as one enormous model with a dramatic name like Mythos or Fable plus screaming about an incomprehensible benchmark and boasting a parameter count that is large enough to cause a temporary electricity shortage in Scandinavia (Hi Kimi K3!).
But unfortunately, enterprises are more complicated than that, something these frontier labs still can’t get between their ears.
Because an enterprise is not one problem waiting for an optimization.
It is a collection of interacting worlds and each has its own language and rules and systems and yes, also a dash of historical trauma. Finance only sees transactions and controls whereas manufacturing sees materials and production constraints and then, the guys of engineering see designs and dependencies, etcetera etcetera, so therefore, a single model cannot simply ingest all of that and magically become the organization, regardless of how enthusiastically it built a 3D world when Julian Goldie, Matt Wolfe or Matthew Berman demoed it.
An Enterprise Brain would therefore have to be an architecture instead of only a model. It would have to combine different forms of intelligence inside a shared representation of the organization. Language models would certainly be part of it, because language is the primary interface through which we can describe what we want and explain things like exceptions and ask the thing some questions. But, then again, the LLM would no longer be expected to carry the entire enterprise on its probabilistic little shoulders. It would be just one cognitive component inside a much larger machine.
No, the architecture would begin with . . . evidence.
Every enterprise leaves behind an enormous trail of evidence about how it operates.
Some of that evidence is intentional, such as policies, process descriptions, organizational models, architecture diagrams, control frameworks, yadayadayada, whereas other evidence emerges from execution, and generates system events and transactions, tickets and other forms of operational telemetry. There is also the wonderfully chaotic human layer of emails and meeting notes, dull corporate presentations, spreadsheets and expert knowledge tucked away on Sharepoint or Slack, Confluence, and what have you, that all explain why the official process is followed except on a Tuesday, at quarter-end or whenever a particular customer calls.
But these artefacts are distributed across hundreds and sometimes thousands of systems (sic), and each fragment tells a part of the story and none of them has the complete picture.
And therefore, the first function of an Enterprise Brain would be to collect and interpret these fragments as observations of the same underlying organization.
The system would not merely copy everything into one enormous data lake and declare the enterprise understood because all the documents now happen to be in the same location. It would have to use the available evidence to actually reconstruct the entities, relationships, constraints and behaviors that make the organization work.
For instance, a policy could be connected to the regulatory obligation that caused it to exist, the processes in which it is applied, the controls that enforce it, the applications that support it and the evidence demonstrating whether it works. A process could be connected to its intended outcome, the roles responsible for it, the decisions made inside it, the information it consumes and the systems whose states it changes. And an architecture component could be connected to the business capability it enables, the data it depends on and the risks that emerge when it fails.
That is what it needs to be able to do.
The resulting representation should resemble what is called an enterprise ontology and made explicit through a knowledge graph, but those terms do not quite capture its intended function. Traditional ontologies describe concepts and relationships, but this Enterprise Brain-model would also have to represent state, behavior, intent, uncertainty and change. It would not merely know that Procurement and Finance are related as is the case in a traditional ontology. It needs to understand how a procurement decision alters a financial commitment and which controls apply with certain permitted exceptions and what consequences it would have elsewhere in the organization.
It would be a living computational representation of the enterprise and naturally, the first version of that representation would be wrong.
Bummer, but hey, that is the way it would work.
This isn’t a defect but actually an unavoidable consequence of attempting to reconstruct reality from evidence that is produced by an organization that has spent decades contradicting itself. The process model may say one thing but an experienced employee who actually keeps everything running may say that the process has been ignored since 2021 because of a decision that only he knows.
The Enterprise Brain would therefore require validation by subject-matter experts.
It could infer a first representation from the available material, identify contradictions and expose missing relationships, but people would still have to confirm that the reconstructed model matched operational reality. The role of the expert will shift from manually describing the organization from scratch (like it used to be when creating ontologies), to validating and correcting what the machine had already inferred.
That may sound like a subtle difference, but economically it is enormous. When we initiate an process agentification program, we have to start with six months of workshops to discover how the company supposedly works, but with the Enterprise Brain, the organization could begin with a computational hypothesis that experts inspect, challenge and improve. That would lead to a huge benefit.
And once that living representation exists, a reasoning layer can begin operating on top of it.
This reasoning layer would reason over the structure and current state of the organization. If a manager wanted to reduce customer lead time, the system could trace which processes contribute to that outcome and which constraints prevent them from moving faster and which controls cannot be violated and which changes would produce consequences elsewhere. It could also distinguish between the official process and the process revealed by execution data, because it has access to every living document in the enterprise and therefore it would be able to recognize that a policy conflicts with current operational behavior.
Yes, I hear you think, so would an Enterprise Brain be comparable to say, a RAG but for enterprise reality? Yes, that would rhetorically be correct, but with the distinction that a RAG collects information on the enterprise, whereas the Enterprise Brain would maintain a model of the enterprise itself.e
A thing like strategic planning would then become grounded in organizational reality instead of something that you generate from a prompt.
The system could evaluate alternative interventions and simulate their likely consequences and construct a sequence of changes that preserves coherence across the enterprise. It would not merely propose that Procurement should “collaborate more effectively with Finance”, like a LLM would, which is the sort of sentence produced when an AI has nothing useful to say but still has several hundred tokens remaining. No, this thing would identify which systems, controls and responsibilities actually need to change.
Memory would also become part of the architecture, because the enterprise must remember more than facts. It must preserve why decisions were made and also which alternatives were rejected and what evidence supported the decision and under which conditions the reasoning remains valid because that would prevent the organization from repeatedly rediscovering the same lessons after everybody involved has moved to another department or escaped to a small farm in France.
But still, all of that reasoning, planning and memory still do not give the brain hands. The next layer would have to translate organizational intent into executable structures.
From the same enterprise model, the system should be able to generate workflows, applications, interfaces, agents, decision rules and controls. If a policy changes, it should identify where that policy is operationalized and propose the corresponding changes. If a process is redesigned, it should generate the required workflow, user interaction, system integrations, evidence mechanisms and escalation paths.
This would fundamentally change the relationship between enterprise knowledge and enterprise software. Today, documentation and applications drift apart because they are created through separate activities, by separate teams, using separate tools. A process model may describe an intended workflow, but the implemented software becomes an interpretation of that model. The controls are then added by another team, the reporting is added later, and eventually somebody updates the documentation to describe a solution that has already changed.
But with an Enterprise Brain, those artefacts are generated from the same underlying organizational representation. The process, application, control and evidence model all remain connected to the intent from which they emerged and when that intent is changed, the system identifies which generated structures were affected, and we would all be exempted from performing another archaeological excavation.
Every generated action would require a degree of trust.
Routine and reversible actions might be executed automatically, but uncertain or high-impact decisions would still require human validation. The necessary level of human involvement should depend on risk, confidence, consequence and organizational policy and not being inserted into every process as a ritual sacrifice to the gods of governance.
Controls would therefore not sit outside the system as an additional compliance layer, but embedded inside the generated processes, applications and agents. The system would need to understand which boundaries apply, and monitor if its behavior stays within those boundaries and it needs to escalate when uncertainty or a certain deviation exceeds an acceptable threshold.
The same principle applies to evidence too. Every important action should generate a trace explaining what happened and why it happened. But evidence would no longer have to be reconstructed six months later when an auditor asks a question nobody expected. It would be produced continuously as a natural consequence of execution.
And by the way, this also makes replay possible. If a decision produces an unexpected outcome, the organization should be able to reconstruct the state of the enterprise at the time and determine if the problem originated in the evidence, the organizational model, the policy, the decision logic or the execution itself.
Versioning then becomes essential.
And that is because an enterprise changes continuously, which means that its computational representation must also have versions. A new process design, policy interpretation or organizational structure should be tested before becoming part of operational reality. The Enterprise Brain would require environments that are resembling development, testing, acceptance and production and not merely for software but for the organizational model itself.
And the entire architecture would also have to learn from outcomes.
A process that appears efficient in theory may fail because suppliers behave differently from what the model expected or an automated decision may be accurate on average but consistently wrong in the exact situations where the financial impact is largest, so those outcomes must flow back into the enterprise representation. The system should continuously compare intended behavior with observed behavior and use the difference to improve its understanding, recommendations and generated structures.
That is what transforms the architecture from a static digital model into an evolving Enterprise Brain. It observes the organization, reconstructs its current state, reasons about desired outcomes, generates operational change, executes within governed boundaries and learns from what happens next. The enterprise is both the subject being modeled and the environment producing the evidence through which the model improves.
Then Mario demonstrated me the thing
The concept of an Enterprise Brain is not new, but they said that constructing a complete model of an enterprise would take ten years, and under normal circumstances, they would be absolutely right.
Building an enterprise ontology in the old days would means months or even years of interviews, and discussions about if something should be classified as a capability, a process, an object or yet another word invented to avoid making an actual decision, and by the time the ontology is finished, then the organization has moved on and three of the subject-matter experts have left and somebody has acquired a new platform that performs roughly the same function but uses different terminology.
That used to be the reality surrounding an ontology creation.
But Mario’s starting point is different.
He said, the enterprise already knows itself.
It has described itself in policies, process models, PowerPoints, spreadsheets, engineering documents, emails, ServiceNow tickets, architecture diagrams, system configurations and execution traces and it is available in disconnected fragments, scattered across systems and written for different purposes by people who were not attempting to create a unified model of the enterprise. Mario’s platform starts with those existing fragments. It ingests the evidence the enterprise has already produced and uses AI to infer the entities, relationships, constraints, responsibilities and behaviors hidden inside it.
And by doing so, a policy becomes more than a document because the system identifies the obligations, roles, controls and processes that have been described within it, a process model now will become connected to the applications, decisions, information objects and outcomes that support it and an engineering document is now part of the same organizational reality as the systems that it affects.
With his platform he showed me he could automatically construct an enterprise ontology made explicit through a graph, but the machine does not pretend that its first reconstruction is perfect. Subject-matter experts still need to inspect what has been inferred, correct the relationships, resolve contradictions and confirm that the model is how the organization actually works.
And this changes the role of the expert entirely.
The person doesn’t have to spend months describing an empty world to a modeling tool, but they validate a world that the machine has already attempted to reconstruct. Discovery turns into validation, and those endless workshops are now focused conversations to discern if the inferred model is wrong or based on a policy that really no one has followed since the financial crisis.
And once the experts approve it, the model becomes what Mario calls the corporate brain.
And that was the first moment during the demonstration when I began swearing.
Because now, the platform had created a shared computational representation of the enterprise through which different parts of the organization can be understood in relation to one another.
Mario and the people at Evolver call the platform ARIA, and within ARIA, organizational capabilities are represented through intelligent objects that they call cartridges (in the FGM, I called them ‘intelligent objects’, slightly less cool). Some cartridges represent vertical domains, such as a business unit, operational area or industry-specific capability, and others cut horizontally across the enterprise through functions such as Finance, IT, Risk or Compliance etc.
Now, this is important because an enterprise does not consist of one enormous undifferentiated blob of knowledge. Different parts of the organization understand different worlds, but those worlds overlap continuously. A Finance cartridge may understand financial controls and a Manufacturing cartridge understands production constraints and operational states, and their shared enterprise representation allows the platform to reason across both without pretending that one general-purpose model somehow became an expert in everything after reading the intranet plus RAG.
Below that representation is a layer for reasoning, planning, memory and execution.
Yes. Execution.
The platform can use the corporate brain to determine what an organisational request means, which dependencies are involved, which constraints apply and what must be generated or changed to achieve the intended outcome.
And with this part of the demo, he showed me that the brain grew hands.
From the validated enterprise model, ARIA can generate processes, applications, interfaces, reports, controls, HITL’s and yes, also agents. It can take an ‘intention’ and then translate it into an executable solution and make sure it is keeping that solution connected to the policies and dependencies and outcomes from which it was derived.
This was not another chatbot attached to SharePoint, and it wasn’t an agent that was enthusiastically ‘computer-using’ around in SAP while everybody prayed that the undo button still worked. The system was actually generating the operational structures required to execute the intent.
If a process required human input, than it would generate an input screen.
Automatically, yes.
If the process produced information, it would generate the appropriate output or report and when a decision would require validation, then it could create the interaction through which that validation occurred and if a control applied, it embed that control directly into the generated process instead of waiting for somebody to discover its absence during the final review.
The platform also determined where human involvement was necessary based on a trust score.
A routine action with sufficient confidence could be automated, but a high impact decision will be routed to a human. Human-in-the-loop isn’t a nervous reflex that you apply to every process because it’s now a deliberate mechanism based on uncertainty and risk.
Also, controls, quality and evidence were not separate activities added after the solution had been built, like with current agentic solutions. They are part of the same generated structure. Actions produced execution traces, decisions retained their reasoning, human interventions become visible and value could be connected to actual operational outcomes.
I say, ‘value could be’, because this part isn’t something I’ve seen. When running simulations, it would be great to see what the impact of the changes are on quality, cost, human effort etc. The enterprise could therefore observe not only what the machine had generated, but also how that generated structure behaved after deployment.
The corporate brain itself was also versioned. Changes could move through development, testing, acceptance and production, which meant that the organisation could test modifications to its computational representation before allowing them to influence operational reality. Decisions could be replayed, previous states could be inspected and changes traced back to the evidence and reasoning that produced them.
Existing enterprise systems did not disappear.
SAP remained SAP and SharePoint continued performing whatever mysterious function SharePoint performs when people ain’t watching. ARIA sat above and between them as a cognitive and generative layer and it was turning the fragmented knowledge that was contained across those systems into a coherent representation from which new behavior could be generated.
That position above and between the existing systems is important, because ARIA is not intended to replace the enterprise data structures underneath it. ERP systems, databases, document repos and such will continue to store records and operational facts, but ARIA adds a new layer on top of those structures whose purpose is to turn the fragments into a shared model of enterprise reality and then it uses that model to reason, plan and act.
Why would you want to do that at all?
A database can tell you that a purchase order changed, but it does not understand why that change matters or what decision caused it. That additional layer connects those facts to their organizational meaning, we developed in the beginning. It makes the underlying data structures part of a larger semantic model.
This is the layer they call NEXUS and it provides context and memory because it keeps the relationships between organizational knowledge, decisions and changing enterprise state. DIOS is the layer we described at the beginning of the article, that provides domain intelligence and it makes sure that knowledge belonging to areas such as Finance, Manufacturing or Risk retains its meaning, rules and ownership. Then there’s ARC, and that is the toolset. It is the execution substrate through which plans are turned into processes, applications, controls, interfaces and actions.
In that sense, ARIA (the name of the entire system) is intended to function as an operating system for the enterprise instead of another application inside it. It is a totally different abstraction layer altogether.
Systems of record that are underneath record reality as it happens, and ARIA reconstructs what that reality means and determines what should happen next and coordinates the capabilities required to make it happen.
But when you’re creating an operating system that is generating enterprise behavior, well, you’re now introducing a fairly obvious problem that if the machine can generate processes and applications with controls and even be allowed to make decisions, then the enterprise needs something considerably stronger than the model simply announcing that it has checked its own work and found itself, once again, magnificent.
That is why Evolver added what they call the 3LoMI, or the Three Lines of Machine Intelligence.
The first line focuses on operational correctness and it verifies if the generated process or application etc performed the task that it was supposed to do and checks if the evidence was produced. It inspects execution against the expected outcome.
The second line performs an independent and more adversarial form of reasoning validation. It challenges its assumptions, policies and risks that it used by the first line. Its total purpose is to make sure that the result was executed correctly and also that it is based on valid reasoning and the correct organizational constraints. This line is introduced to prevent the intelligence that generated a solution from becoming the only authority for approving it. Hahaha, that would be the same as letting one of my students perform an exam, grade his exam himself and then nominate himself for an academic award.
The third line examines coherence. It searches for nasty things like drift and other weird patterns that can appear to be correct locally but it could stir things up elsewhere. A generated procurement change can function exactly as designed, but it may increase financial exposure or create a compliance problem somewhere downstream. The third line is intended to detect precisely that kind of emergent behavior.
The cool thing is that these three lines are part of the machine and not a governance ceremony you perform after the damage has been done. That is how agentic AI works at this moment. That’s why the industry is pumping huge amount of coin into observability and explainability. But what if you can prevent this nastiness from happening in the first place? Quality assurance should be continuous and machine-enabled.
Circling back to the data layer, this is what turns this layer into more than an enterprise knowledge graph. It does not merely represent organizational knowledge and it doesn’t only generate new behavior, but it also observes and challenges and governs that behavior, and that closes the loop.
And that was the point at which I didn’t see ARIA anymore, as an advanced AI platform, and decided I’d do a writeup about it. Not with the intention of selling it. I have no stake in the company, apart from the fact that I want to be involved in the implementation of it because I want to experience how it operates under raw enterprise conditions.
And when it does what it promises outside the demo, this is the layer through which the enterprise can begin to understand, generate and continuously improve itself. An Enterprise Operating System.
My first world-changing event was 11.30.22. The second was 07.13.26.
Signing off,
Marco
For my daytime job, I’m a researcher and factory builder at Eigenvector, a commercial research lab operating at the frontier of unsexy AI. In the evenings, I write about why building this stuff is a lot harder than the vendors would have you believe.
Leave a Reply