Software was always supposed to be soft and AI is about to make it so.
As I was saying in this short post, never have I been more certain about what comes next. AI is about to transform every aspect of business, but most profoundly the business of corporate IT, and by extension and necessity, the "harness" of software: business process management. Here's the prediction: much of the process and quality machinery built since the 1980s may become as obsolete as elevator operators. And I'm looking right now at my dusty and earmarked copy of The Machine That Changed the World (1990). Great book.
But that world is done.
The Nutshell
If you want to listen to my thesis on-the-go, there's a NotebookLM podcast here which you can listen to while stuck in traffic. Otherwise here, in a nutshell is the key point: for forty years, enterprise software forced human beings to adapt to machines.
We called that discipline. We called it process. We called it standardisation, governance, quality management, workflow, enterprise architecture and business transformation.
Much of it was necessary. Much of it worked. Modern banking, aviation, logistics, healthcare, public administration and global supply chains could not exist without the industrialisation of software and process that began in the late twentieth century.
But we may now be reaching the end of that bargain. The old bargain was simple: software is rigid, so people must become procedural. The new bargain is different: software can increasingly interpret human goals, context and intent in real time. That reversal changes everything.
It does not mean the end of software. It does not mean the end of ERP. It does not mean the end of Enterprise Architecture, governance, quality management or process discipline. Quite the opposite. It means their purpose changes.
IT moves from building applications to governing adaptive capability. Enterprise Architecture moves from mapping systems to stewarding the trusted environment in which human and machine agents act. Process management moves from enforcing predefined paths to legitimising the conditions under which new paths can safely emerge.
That is the software revolution I believe is now beginning. And I have never been more certain that corporate IT, business process management, quality management, enterprise architecture and HR are about to be forced into a profound transition. This is not because AI is magic. It is not because chatbots are impressive. It is because the basic relationship between human work and software is changing.
The Background
But before getting into the core of this thesis, there are a couple of very technical topics that need a bit of layman summary in order to allow for opening the discussion to the business. I'll try and make it brief, but we do have to cover a few foundational topics for my thesis to have a clear "red-thread." In the following topics, I'm going to explain some historical and foundational concepts that form that clear red-thread from the 1960s to the present day and that give me confidence we are about to transform almost everything in corporate methods.
Read on and debate. I am working on this dynamically trying to apply it to my own digital transformation endeavours. And so all criticism or adds are welcome and appreciated.
Smalltalk
Smalltalk was a bit of a religion back in the 1980s and one by which I was strongly influenced. It is a computer programming language invented by Alan Kay, at Xerox PARC in the 1970s, and yes, that's the same Xerox PARC that influenced Steve Jobs and Steve Wozniak from Apple.
Would you like to see something amazing? Here's the Apple Knowledge Navigator Video (1987). I watched this in my first year at University and it has never escaped my mind. Tell me that that is not a visionary prediction of OpenClaw, an AI agent technology framework from November 2025 that I will describe below.
Smalltalk, and all of the fantastic research coming out of Xerox PARC in the 1970s was about a vision for computing that failed commercially for about 40 years, but which is coming back strong now that the pure raw compute power, and the incredible mathematics of modern computing architecture, including AI, make the vision of Smalltalk possible.
So what was so great about Smalltalk anyway? Kay and the Xerox researchers believed that computing should be a dynamic, interactive knowledge environment for ordinary human beings. OK, at the time, the dominant models were punch cards, text terminals, static compilation and procedural programming. I remember well, through the kindness of a Chilean professor who was a friend of the family, giving me her allotted computer time on the single university mainframe computer. I was 10 years old and enthralled by the physical process of punching cards to provide procedural instructions into a machine that produced an output. But the key points to understand are procedural programming and static compilation.
Procedural programming is a philosophy of computer programming which describes how a problem is to be solved, or tasks performed instead of describing what needs to be done. It evolved from engineering disciplines. This difference between a goal and an ordering of tasks is critical to the widespread adoption of business process management and enterprise resource planning disciplines of the 1990s and 2000s. What did procedural programming offer? Simplicity and reusability.
Static compilation is an approach to creating a working computer software program that brings together all of the ingredients of software code to allow for you, the "user", to execute the program without having to access or load any other files later. It's like a complete microwaveable meal. I punch the card, put it in, and get an output or an error. The opposite of static compilation is, obviously, dynamic compilation. Languages like Java (inspired by Smalltalk but commercially more successful) are dynamically compiled.
OK, so how is this relevant to business? Because software mirrors the corporate frame. Smalltalk argued for elegance and human cognition. The software industry (and therefore you, dear buyer) chose complexity and control. Smalltalk introduced object oriented programming, where everything is an object interacting independently with all the other objects. Objects pass messages. Think of your car. The steering wheel is an object. The transmission is an object. The engine is an object. They pass messages one to the other and react from their internal context to the messages that they send and receive. The entire environment is an object system. That system is "alive." When you drive, you are reacting in real time to the road and its objects. You have not planned your procedure through the road prior to starting your journey.
But prior to and parallel to Smalltalk, the procedural approach required a sequence of stop, compile, deploy, and restart. Before driving from Paris to Prague, you program every turn and rest stop. Instead, Smalltalk philosophy was about user-centricity, interaction, and modification of the world around us in real time, as time flows through the hourglass. It's environment-centric, fluid, dynamic, and conversational.
Literally, the philosophy was this: I don't spend time planning a set of tasks that provide an input to a machine so that I will obtain a result or an error. Instead, I converse with a system and both of us learn in real time how to model and improve the world around us.
Why did Smalltalk fail? It was slow, expensive and hostile to the business environment. This was a period when the 20th century world wanted predictable binaries, simple operational models, and cheap infrastructure. Smalltalk felt exotic and academic. Unix (later Linux) and C (later C++ and Java) were closer to the engineering philosophy of the decade, closer to the "primitive" hardware that had to operate in real-world factories of the time. These engineering languages were just object-oriented enough to market, but just rigid enough to govern through 20th century mindsets.
Smalltalk was optimised for thought. Its competitors were optimised for organisational optimisation. Even W.E. Deming would roll in his grave to see the result of what happened to "continuous improvement." Because optimisation meant optimal for limitation.
Business Process Management and LEAN
And now we arrive at the part where software stopped being primarily about computing and engineering problems and started becoming about organisational control.
If Smalltalk was born in the universities and research laboratories of the 1970s, Business Process Management (BPM) was born in the boardrooms and factories of the 1990s and 2000s. It is impossible to understand modern corporate IT without understanding this shift. Because BPM became the "harness" of software in corporate environments. I'll describe harness in a moment, for now just remember that a harness keeps an animal in control. It's not a stretch to say that BPM was invented to harness the rapid technological advancement of computing in the 1990s.
LEAN emerged gradually from Toyota, and became globally dominant in the 1990s through the study of the astonishing rise of Japanese manufacturing and industrial quality management. The philosophy of LEAN is almost unassailable: eliminate waste, optimise flow, standardise work, reduce variance, continuously improve. That was my morning prayer for every day of my professional life from the 1990s until the early 2020s.
Why? It worked brilliantly. BPM and LEAN, and all of the quality management variants, transformed manufacturing, logistics, automotive production, supply chains, and eventually corporate management itself. Combined with the rise of ERP systems such as SAP, Oracle, PeopleSoft, and later Salesforce, the corporation itself increasingly came to be viewed as a machine that could be modelled, measured, optimised, and governed through software. Process harnessed software. And software harnessed the good people of the corporation.
This is where things become philosophically important. Because to sell their wares, the software industry absorbed industrial manufacturing logic. Everything is a machine! Even people! We will even call them human capital.
And here is the dangerous part. Over 30 years, an entire generation who forgot their own origins, the enterprise gradually came to believe that intelligence itself could be procedural. If only enough workflows, controls, KPIs, forms, approvals, process diagrams, governance boards, and enterprise architecture layers were added, then ambiguity could be reduced and the organisation would become efficient, measurable, predictable and scalable. And scalability was the name of the game during 20th century globalisation.
And also, to be fair, compared to the chaos of many 1970s and 1980s organisations, this represented enormous progress.
Business Process Management models organisational activity as a sequence of predefined steps, transitions, approvals, exceptions and rules. A process is designed, encoded, governed, monitored and continuously refined. The process becomes the machine through which work flows. Work and flow. Those are two separate words, but ironically with the rise of the software industry, the concepts were merged and rapidly pitched as automation of workflows. The verb became the noun! Work and flow became one.
Look carefully and you will recognise the same intellectual DNA as procedural programming: do this, then do that. If condition X, branch here, If error Y, escalate there. Wait for approval. Log the outcome. Generate the report. Repeat.
What happened at the end of the 20th century? Business itself became software. Humans became machines. Software (precisely, the procedural school of software which won commercially) became the operational grammar of business.
Stop and reflect why: because this approach was perfectly aligned with the technological limitations and management philosophy of the time. Computing resources were expensive. Interfaces were rigid. Humans had to adapt to software because software could not realistically adapt to humans. And software was vital to managing the emerging complexity of the late 20th century. Therefore organisations spent thirty years training humans to think procedurally. And 40 years later, we have forgotten why.
The implicit assumption beneath all of 20th century product is the same: organisational intelligence can be predesigned. And this is exactly where AI begins to destabilise the entire global model.
OpenClaw and agentic AI frameworks
Large Language Models (LLMs), just like natural humans, do not fundamentally operate procedurally. They operate contextually. Probabilistically. Dynamically. Conversationally. The workflow no longer needs to be entirely predefined because the system itself can increasingly interpret intent in real time.
Read that again. The work flow no longer needs to be entirely predefined because the system itself can increasingly interpret intent in real time. Any organisation, private or public, formal or informal, is goal oriented. In the late 20th century, business became task-oriented because hardware and software limitations drove task-orientation. The goal was lost to the task due to the primitive nature of the beginning of the software revolution.
Something radical happened in November 2025. It was not a paradigm shift, but it was a clear bend of the knee of the exponential curve. It was the milestone defined by Gemini 3, Grok 4, GPT 5, and OpenClaw, invented by Peter Steinberger.
For forty years, enterprise IT has largely functioned by forcing reality into predefined software pathways. AI inverts this relationship. Increasingly, software adapts dynamically to human intention instead of humans adapting to software.
OpenClaw is particularly important because it demonstrated in practical terms, what this new world actually looks like. At first glance, it appears to be "just another chatbot." But underneath sits something much more significant. A persistent conversational environment where contextual identity, memory files, tools, program interface access, scheduling and dynamic retrieval are continuously "injected" into the AI LLM's operating context.
Most of us have come to understand that the "magic" of LLMs is just a statistical trick. They don't think, they don't remember, they don't know. As powerful and useful as an LLM may be, it's just pattern recognition and prediction without a harness. OpenClaw gives those models an alarm clock that automatically and "invisibly" prompts the model(s) to predict. It provides memory files and search mechanisms that give the model the right information at the right time, and access to the use of tools. The word agent had been used already for some time to refer to a specialised chat-bot. But none of them were actually agentic and goal-oriented. True agent frameworks give models continuity. And, therefore, the ability to reconstruct continuity in real time. This gives rise to something that feels less like software execution and more like an adaptive computational entity operating inside of a useful environment. That is very different from just chatting with ChatGPT.
The point of this article is to engage you in a debate on the future of IT, but reflecting on OpenClaw is central to the thesis. On one side, OpenClaw still draws its cognition from LLMs. In that sense, it is just an even more impressive "party trick" based on the power of probabilistic mathematics. But at the same time, Peter showed us what agentic AI is supposed to mean, and introduced an early framework for how to achieve it. And that is fundamentally important to the future of software.
Workflows no longer need to be fully predefined because the system itself increasingly interprets goals, context, and intent dynamically as work unfolds. What Standard Operating Procedure can solve the current crisis at the Strait of Hormuz? It takes actual cognition. Do you see the point?
Huge portions of process-heavy organisational life become historically transient with AI. Just as elevator operators disappeared, not because elevators disappeared, but because the interface changed. User-centric goal orientation ("Bring me to the ground floor") replaced task orientation.
AI Harnesses
If you are like me, you might be confused about the jargon that seems to have invaded most of the AI discourse recently.
Historically, a "harness" was a hard-core engineering jargon within the type of software programming that is usually not with Corporate IT, but inside of the type of programming that directly drives machine in factories, called operational technology (OT.) It was also used in software quality assurance.
The term exploded in November 2025, because researchers realised that AI models are the least governable part of any system. Well, I don't count humans, but it is for the same reason. Probabilistic agents are naturally not governable. Given enough complexity, it's very hard to predict what a human or machine agent will say or do.
So a harness is, in its most simple term, something that sets ground rules, constraints and limitations on a naturally unpredictable system. After OpenClaw (strictly speaking, alongside the state-of-the-art of late 2025), it became clear that "agentic" AI was about an AI model and its harness. E.g., its controls.
Harness an LLM with memory, goal state awareness, rules, and dynamic context moderation, and you achieve "agentic" AI.
Packaged Software (COTS)
Another foundational point is the rise of packaged software over bespoke software. In the 1970s and 1980s, and even today in many tech companies, many corporations still built large parts of their own systems internally or through specialised contractors. Software was closer to craftsmanship — adapting the code to the company. But as corporations globalised and BPM philosophies spread, packaged enterprise software won commercially because it offered standardisation, supportability, governance, repeatability and lower operational risk. SAP, Oracle, Siebel, PeopleSoft and Salesforce did not merely sell software. They sold industrialised organisational templates. "Best practices." Adapting the companies' people to the code. Entire corporations increasingly adapted themselves to the assumptions embedded inside the package. Open source evolved in parallel as a reaction against vendor dependency and closed control, particularly in infrastructure layers like Linux, databases, middleware and cloud platforms. And now, ironically, AI may partially dissolve the distinction altogether. The future may not belong primarily to either packaged or bespoke software, but to fluid cognitive environments assembled dynamically on top of sovereign open infrastructure, governed by architectures, policies, memory systems and AI harnesses rather than fixed applications themselves.
Enterprise Architecture
Thanks for your patience. Remember you can always listen to the podcast.
Enterprise Architecture (EA) is the last foundational component that we need to explain to describe where software, and its harness (process and quality management) are going to end up very soon.
EA emerged as a formal discipline in the 1990s and early 2000s for a very good reason: the software industry was collapsing under the weight of its own success.
The corporation had become digital.
ERP systems were spreading everywhere. SAP, Oracle, PeopleSoft, Siebel, Lotus Notes, bespoke applications developed by well-meaning engineers divorced from the day-to-day of the business: data warehouses, middleware, document management systems, BPM engines, intranets, web portals, APIs, reporting stacks and early cloud systems began multiplying across large organisations at extraordinary speed.
Departments bought software independently. Consultants customised everything. Integration projects exploded in cost and complexity. Duplicate systems proliferated. Data quality deteriorated. Security became chaotic. Nobody knew which system was the "source of truth." Even the boardroom was confused.
And so Enterprise Architecture emerged as the nervous system of large-scale corporate IT. It was desperately needed. And the mission was noble, necessary, and heroic. Architects became the custodians of coherence inside increasingly fragmented technological empires.
What does an Architect actually do? At the simplest level, EA attempts to answer five fundamental questions: What systems do we have? How do they interact? What data do they manage? Which business capabilities do they support? What principles and standards ensure that the whole enterprise remains governable over time?
That may sound abstract, but without Enterprise Architecture, large organisations rapidly descend into digital entropy. EA defines standards, principles, patterns, data architectures and interaction rules. And most importantly: governance models.
Architects arbitrate between innovation and operational stability. They prevent local optimisation from destroying enterprise coherence. They protect organisations from vendor chaos, redundancy, and uncontrolled complexity. In many organisations, they are among the very few people capable of seeing the whole technological map of the enterprise.
And important for this article, EA is not just technical. It is philosophical. EA represented the belief that the corporation itself could be modelled as a coherent system. We can chuckle at the hubris. The entire corporation can be modelled as a coherent system — not just financially. Not only organisationally. Computationally. Business capability maps, process maps, application portfolios, reference architectures, technology standards, data models, target states, transition architectures. The enterprise became something that could be designed.
There is no shame in this. Our profession was deeply aligned with the BPM and LEAN worldview of the era. If BPM described how work should flow, EA described the technological city inside which that work would occur.
And again, to be fair, compared to the chaos that preceded it, this was an extraordinary achievement.
Modern banking systems, aviation systems, pharmaceutical supply chains, tax systems, global logistics, public administration, telecommunications and modern healthcare simply could not exist without the discipline, standardisation and quality controls imposed by EA over the last thirty years.
But now we arrive at one of one hundred uncomfortable questions. What happens when software itself becomes fluid and personal? You can write all the AI policies you want: everyone in your organisation except for the eccentric 1% are using GPT in violation of policy.
EA evolved in a world where systems changed relatively slowly and where process determinism was achievable through sufficient modelling, governance and standardisation. But agentic AI increasingly behaves less like traditional software and more like adaptive cognition operating over infrastructure.
That changes everything.
The big change that happened yesterday
As I said, never in almost 40 years of professional life have I been more certain of what is about to happen very soon within the business of business technology. Our industries have forgotten something fundamentally important. Software was supposed to be soft. It was supposed to be malleable, adaptive, and conversational as those Xerox PARC researchers understood.
Software is the medium through which human beings model and reshape reality together. Whereas enterprise computing gradually hardened into industrial infrastructure. We moved from building calculation tools (satellite orbit models, MRP runs, financial arbitrage models) to an attempt to model the whole of the enterprise itself, including its people (workflow, approvals, forms, roles, actors, use cases, processes, escalations, reporting chains, quality systems, standard operating procedures.)
And again, to be fair, this was necessary. The hardware was slow. Computing was expensive. Networks were primitive. Humans had to adapt themselves to software because software could not realistically adapt itself to humans.
The deeper assumption beneath the entire enterprise software revolution was that organisational intelligence itself could eventually be frozen into sufficiently detailed systems, workflows and governance models. E.g., that intelligence can be automated.
But living systems do not behave that way, and especially not the human species of living system. Reality changes faster than architecture committees can meet. Markets change faster than governance boards. Science changes faster than approval chains. Human beings change mind and heart faster than a BPM diagram can be spit out by a software program.
And now, for the first time in history, computing itself is beginning to adapt dynamically in real time. That changes everything. When I interact with my AI agent, as I do each day, I do not feel like I am operating traditional software anymore. I converse with an adaptive environment. It attempts something. It encounters failure. It changes strategy. "I'll try a different approach," it says. And it almost always succeeds.
That sounds trivial until you realise how profound it actually is.
For decades, software waited passively for humans to navigate predefined paths. Now software increasingly participates in problem solving itself. And once people experience that privately, they will demand it professionally.
Just as employees brought smartphones into the enterprise before IT approved them. Just as cloud collaboration appeared before governance frameworks existed. Just as people used ChatGPT before corporate "copilot pilots" emerged.
The workforce always arrives before the governance.
Which means the future enterprise may increasingly resemble a living conversational nervous system rather than a collection of applications.
Within just a few years, many knowledge workers may interact continuously with: personal corporate agents, personal private agents, team coordination agents, compliance agents, financial agents, project agents, scientific agents, negotiation agents, operational agents.
These are not dystopian humanoid robots! These are not science fiction holograms! This is just what software was always supposed to be. Conversational cognitive environments.
Hundreds of interactions occurring continuously across voice, meetings, documents, telemetry, collaboration systems and operational platforms.
And underneath this apparently fluid conversational world will sit something paradoxically even more important: serious architecture. Big IT. Because somebody still has to protect: identity, trust, memory, security, interoperability, traceability, sovereignty, governance, and systems of record.
The future does not eliminate Enterprise Architecture. It elevates it closer to constitutional law. It puts the enterprise into EA. Because admit it, what we have called Enterprise Architecture has never elevated itself into the board room even after 40 years of preaching.
But Architects increasingly govern the platform substrate upon which adaptive organisational cognition operates. Meanwhile the traditional Business Analyst to Developer release pipeline will compress dramatically. Business analysts and developers will increasingly become solution composers directly collaborating with AI. And then they will move closer to strategic business capability leadership. Operational engineers and architects will move deeper toward platform engineering, sovereign infrastructure, security and orchestration.
And the software industry itself may partially dissolve back into the business.
Because once software becomes conversational and adaptive, the distance between operational need and computational implementation collapses. The application stops being the product. What architects call enterprise capability became the new and continuously evolving product.
This world is coming, and it is coming fast. So if you are a CIO or senior leader in your organisation, take steps now to prepare for the coming software re-revolution.
Here is your to-do list:
1. Build enterprise-wide AI capability, not awareness
Generic digital literacy will produce generic capabilities and use cases. You need to move fast from literacy to operational capability.
Every employee should understand not only how to use AI tools but how to collaborate with probabilistic systems, evaluate outputs, escalate uncertainty, and adapt workflows continuously. This means your corporate governance focus should immediately shift to how quickly you can compress the cycle of SOP and release approvals. That cycle time is your single best metric for digital capability. The time from idea to business-as-usual.
2. Train employees to think with models, not operate models
Prompt training was a good start. But it's a soft-skills workshop. And prompting is already obsolete as I predicted during the height of the prompt engineering hype two years ago.
You need to train employees to think with models, not how to operate them, because model operation is about to go underground into the infrastructure itself. So teach staff to use AI as a cognitive sparring partner: hypothesis generation, critique, uncertainty management, adversarial thinking, inductive reasoning, collaborative judgment and structured challenge. This is the world of non-tokenised thinking (see my article here explaining the concept.)
3. Move beyond chat and build governed AI operating environments
Move beyond chat and harness the LLM models. Chat is like the email of an AI model.
Real value emerges only when models gain structured memory, tool access, permissions, orchestration and controlled execution environments through harnesses and agentic architectures. If you have a low-code/no-code platform in your organisation you already have a robust and trusted platform on which to build the cognitive harness you need to make LLM models work for your organisation. Without a harness, AI won't scale, it just remains the intelligent coffee partner for your employees.
4. Transform IT from application factory to cognitive infrastructure steward
Those agentic platforms will be built with you or without you. The corporate value leak that will occur if you are not part of your own build is significant. Transform IT from an application factory to a cognitive infrastructure steward.
The first job, already as of 2026, for architects and operations managers must be to preserve the system of record while exposing capabilities through secure, observable agent-ready platforms.
For now, protect your ERP. But expose dynamic capability. If you are already working closely with a software supplier who is trying to pitch you their internal chatbot, refuse the offer. Instead, negotiate hard for access to the flows and data models of the platform so that your agents can start making your enterprise more fluid.
Cognitive infrastructure steward. That's a big word, but it is already now the main role for architects. The old IT was about "we built the software like you asked. Now please use it." The new IT is about "we built the agentic environment and govern its sanctity. Now please show us what you need to achieve."
This shift in IT architect and operational roles, from application factory to guardians of trust is going to be painful for both sides, but there are ways to build trust across the corporate functions so that all can be successful in this transition that is already unfolding under our eyes.
5. Adopt an AI-first evaluation discipline, not an AI-first mandate
Every new process, service or investment should be evaluated for AI augmentation before traditional implementation — but AI should only be adopted where it reduces representational burden, improves adaptability or increases capability.
The problem with an "AI-first policy" is that AI doesn't solve every problem, just like more people or smarter people or more experienced people (like hiring consultants) is not the solution for every problem.
But more likely than not, your current AI governance is broken and divorced from your process governance, which is the mistake which prevents you from transitioning rapidly to an agentic AI platform providing the dynamic cognitive adaptation that your organisation needs. Ironically, that was always the real promise of Agile.
Before I build a new capability with my agent, I always ask it, "would a software solution help us?" Maybe the problem is just access to data. Maybe I have a trust issue. Maybe there is an irrational approval chain. And increasingly, as I learn to co-manage my personal life with an AI agent, the answer is no. I don't need a workflow or an app. Most of the time I just need to give it access to the right information, or give it agency and context, or connect it to an existing system, or to define better rules and guardrails. And then I allow the capability to emerge. I don't jump on its mistakes, but rather coach it toward the strategic goals.
Let's map this to the real world of business. In the "old IT," which is still alive and well today, a manager would request a new dashboard. Then we go through the tired 6 month factory process of defining business requirements, eliciting and forming them with a business analyst, procuring, developing, testing, releasing and then supporting that application until doomsday comes.
In the new IT world (which technology already exists today and is already being used at the margin of your organisation), the manager just asks their AI agent, "Monitor these KPIs, notify me if anomalies appear, and escalate exceptions. By the way, file the formal report into a log to ensure that the system of record shows a continuous monitoring."
That takes twenty minutes. It's a brave new world.
6. Treat governed data access as strategic infrastructure
Which brings me to the last and most critical action to implement now. Without data, it is too easy to blame the AI for failure. Hallucination, drift, forgetfulness and other artifacts of AIs operating without a harness and without access to the data it needs.
AI without trusted access to enterprise context becomes theatre. Build permissioned, observable and interoperable data environments so agents can operate on reality rather than speculation. Treat governed data access as strategic infrastructure.
But here's the problem in most organisations. Even if there is a pro-agent culture, the governance infrastructure we have built up often requires an agent asking for permissions on the data (or a human proxy working with the agent) weeks or months. And it usually has to go through an IT governance, an AI governance, a data governance, and other functional divisions of what should be governed as strategic infrastructure. It is no wonder that your AI use cases are struggling to produce any resulting value.
I'm not saying to open all the databases to your agents. That would be reckless. But I am saying, that like the first recommendation to immediately change your process governance, that your data governance and its silos and committees has to be treated as the energy driving the machine to deliver value. Without fluid process and access to the necessary data, AI is the side-show and investment leakage story that is dominating headlines. Those organisations that succeed are moving in this direction.
Never have I been more sure.
Conclusion
I may be wrong.
Perhaps ERP systems will continue to dominate for another thirty years. Perhaps enterprise architecture and process modelling will absorb AI as just one more lens and this article will age badly. Perhaps the great enterprise software vendors will adapt and become the dominant agentic platforms. History is not deterministic.
But after almost forty years in this industry, I have learned to pay attention when multiple forces begin moving in the same direction. And I have rarely seen convergence like this.
Research in the 1970s imagined conversational, personal computing. Then LEAN industrialised process. Then ERP industrialised organisations. Then Enterprise Architecture industrialised complexity. Then Cloud industrialised infrastructure.
AI is industrialising adaptation and suddenly much of what we assumed was permanent (how the world works) starts to look suspiciously temporary. So these are my questions.
What if applications are not the endpoint? What if workflows were never the destination? What if most of the software industry was a necessary transition technology created because humans had to adapt themselves to machines? And what if, for the first time, the machines are beginning to adapt themselves to us through the power of harnessed agentic AI?
Put down your arms, I am not predicting the end of software. I am not predicting the end of ERP. I don't need the cost and uncertainty of AI to balance an accounting ledger. But those will be niche applications.
I am not predicting the end of Enterprise Architecture, governance, process management or IT. Quite the opposite. I think they become more important than ever. But their purpose changes from software construction to capability composition. Less application ownership (because people push their own elevator buttons these days.) I'm calling for more trust stewardship, less process enforcement, more legitimacy and adaptation. Less planning and designing every path and more governing the environment in which paths emerge.
Perhaps in twenty years we will look back at our forms, tickets, workflows, application menus and steering committees the same way we now look at elevator operators or horse carriages with engines bolted underneath.
With gratitude instead of contempt because they carried us here.
If software was always supposed to be soft, what should your organisation stop building tomorrow? And if the future workforce arrives conversationally before governance catches up, what are you doing today to prepare for the world your employees are already quietly creating?
Debate me. I am still thinking.