We’ve Seen This Movie Before

Every major shift in enterprise technology seems revolutionary when we are living through it. But look backward and a familiar pattern emerges.

We went from mainframes and green screens to graphical user interfaces. At first, many of those graphical interfaces were essentially new front ends placed over old systems. Eventually, applications were designed around the graphical interface itself.

Then came the internet. Initially, organizations found ways to put existing applications into a browser. Eventually, we stopped talking about “web-enabling” software because applications were simply designed for the web.

The same thing happened with cloud computing.

Early cloud strategies often meant moving existing software onto someone else's infrastructure. Then came software-as-a-service and, eventually, cloud-native architectures designed around an entirely different set of assumptions about infrastructure, deployment, scalability, integration, and consumption.

Each transition followed roughly the same pattern…

First, we attach the new technology to the old model. Then we optimize around it. Eventually, we rethink the model itself.

We think artificial intelligence will follow the same path.

The Bolt-On AI Era

Over the past few years, virtually every enterprise software company has announced AI capabilities. Some are impressive. Most focus on how AI can summarize documents, answer questions, draft content, populate fields, recommend actions, generate reports, and make traditional applications considerably easier to use. Those capabilities create real value.

But in many cases, something fundamental hasn't changed. Underneath the AI sits essentially the same application. The same forms. The same workflows. The same databases. The same screens. The same reports. And, perhaps most importantly, the same assumptions about how humans perform the work.

Here at Contxt Risk, we have added intelligence to the existing software model rather than asking what software should look like if intelligence were one of its foundational design assumptions. That distinction matters. And it raises a much more interesting question than whether a particular product “has AI”:

If you were designing this software today, from the ground up, knowing what AI can now do, would you design it the same way?

Increasingly, the answer is no.

We've Been Here Before

Microsoft CEO Satya Nadella described the current transition in strikingly similar terms.

Writing about Microsoft's AI strategy in early 2025, he said the industry was entering an AI platform shift in which “every layer of the application stack will be impacted.” He compared what is happening simultaneously to the introduction of graphical interfaces, internet servers, and cloud-native databases.

His conclusion was even more provocative: “Thirty years of change is being compressed into three years!”

Nadella described a future of agentic applications possessing memory, permissions and the ability to take action, not simply AI features embedded within conventional applications.

That distinction is important. This isn't merely a better user interface. It is potentially a different application architecture. And Microsoft isn't alone in seeing it.

Gartner recently estimated that as much as $234 billion of enterprise application software spending could be exposed to disruption from agentic AI by 2030. Gartner describes agents increasingly completing work across systems rather than requiring people to interact separately with each application's traditional user experience.

IDC makes a similar argument. It sees enterprise software moving toward an environment where agents become a new interface layer, orchestrating activity across systems while users increasingly focus on the outcome they want rather than navigating the applications required to produce it.

McKinsey has gone even further, describing generative and agentic AI as a foundational shift that could redefine “what software is, who builds it, who uses it and how companies are organized and operate.”

This is beginning to look less like another feature cycle and more like another generation of enterprise computing.

So What Does “AI-Native” Actually Mean?

There is understandable skepticism around the term AI-native and that's healthy.

Technology companies have an unfortunate habit of attaching “native” to whatever technology happens to be fashionable. So perhaps arguing about the label misses the point. Call it AI-native, agentic software, AI-centric software, or something else entirely.

The more meaningful distinction is this: Was AI added to make the existing way of working better, or was the system designed around the possibility that AI could fundamentally change how the work gets done?

That is a much higher bar. AI-native shouldn't simply mean that a product uses a large language model. It shouldn't mean that a chatbot appears on the right side of the screen. And it shouldn't mean that AI can summarize information already stored inside the application. It should mean reconsidering some of the fundamental assumptions underlying the software.

What work should humans perform? What work can an agent perform? What organizational context does that agent need? What should the agent remember? What relationships between information does it need to understand? What can it recommend? What can it do? Where should humans remain in the loop? And how can the combination of human judgment, organizational knowledge, and AI produce an outcome that wasn't practical before?

Those are fundamentally different design questions.

From Automating the Workflow to Questioning the Workflow

This distinction becomes particularly powerful in risk and resilience.

Consider the Business Impact Analysis.

For decades, organizations have periodically asked people across the business to complete questionnaires describing their activities, dependencies, recovery requirements, and impacts. Software digitized that process. Instead of paper questionnaires, we created electronic forms. Instead of spreadsheets, we created databases. Instead of emailing documents around for approval, we created workflows. Those were meaningful improvements.

Now imagine adding AI to that traditional application.

AI might help someone complete the questionnaire. It might summarize responses. It might flag inconsistencies. It might draft a report.

Useful? Absolutely.

But we are still assuming that the organization needs to periodically ask hundreds of people to reconstruct what the organization knows about itself.

An AI-native approach allows us to ask a different question: Why are we doing the process this way at all?

What if software could continuously consume existing organizational information?

What if it could understand business services, processes, technologies, facilities, suppliers, people, risks, controls, incidents, and the relationships among them?

What if it could recognize when something changed?

What if it could identify missing or conflicting information?

What if an agent could propose conclusions based on available evidence and then ask humans to validate the areas requiring judgment?

The objective hasn't changed.

We still need to understand business impact and business continuity requirements.

But the process for getting there could be radically different.

That's the difference between using AI to automate a workflow and using AI to rethink the work.

From Systems of Record to Systems That Understand Context

Traditional enterprise applications became extraordinarily good systems of record.

They store information. They organize it. They apply business logic. They route work. They report on what has been entered.

But risk and resilience rarely suffer from a shortage of information. The problem is that the information exists everywhere. Policies live in SharePoint. Technology dependencies live in architecture repositories. Vendor information lives in procurement systems. Incidents live somewhere else. Risk assessments exist in GRC platforms. Plans sit in continuity applications. People exchange critical information through email, Teams, meetings, documents, and spreadsheets.

The challenge isn't simply storing another copy of that information.

It is understanding what all of it means together. That's why we believe context becomes foundational to the next generation of enterprise software.

An intelligent agent needs more than access to documents. It needs memory. It needs relationships. It needs permissions. It needs skills. And it needs an understanding of the organization in which it operates.

This is where concepts such as ontologies and knowledge graphs become much more than technical architecture. They create organizational context. The agent doesn't simply retrieve a document containing the words “payment processing.” It can understand that payment processing is a critical business service, supported by certain technologies, dependent upon particular vendors, exposed to identified risks, protected by specific controls, and connected to recovery plans and responsible people.

That changes what AI can do.

The Interface May Be Changing Too

For decades, enterprise software has required humans to learn how the software works.

Open the application. Navigate the menu. Find the module. Open the record. Complete the fields. Run the workflow. Generate the report. AI agents potentially invert that relationship.

Instead of humans learning the application's workflow, the software increasingly understands the human's objective.

“Which critical services are currently exposed because of this supplier disruption?”

“Which recovery strategies depend on the same cloud region?”

“Which business continuity plans are inconsistent with what we now know about their technology dependencies?”

“Prepare the executive briefing and identify the decisions leadership needs to make.”

Those aren't requests for records. They're requests for outcomes.

IDC describes this emerging environment as one in which AI becomes a new interface layer over enterprise systems. Gartner similarly argues that agentic systems can increasingly deliver outcomes while making some of the underlying software effectively invisible.

That doesn't necessarily mean SaaS disappears.

Deloitte, among others, argues for a more nuanced future in which existing SaaS platforms and AI-native capabilities coexist and evolve together.

History suggests that is probably how transitions happen anyway. Green screens didn't disappear the day Windows arrived. On-premise software didn't disappear when Salesforce appeared. Data centers didn't vanish when AWS launched. Old and new architectures coexist for years.

But eventually, the new architecture changes what customers expect from software.

And once expectations change, simply attaching the new technology to the old experience becomes increasingly difficult to distinguish from the transitional architectures that preceded it.

This Is Why We Built Contxt Risk Differently

At Contxt Risk, we had the advantage - and the challenge - of starting with a blank sheet of paper. We weren't trying to add AI to a twenty-year-old risk and resilience application.

We could instead ask: Knowing what AI is becoming capable of, how would we design risk and resilience software today?

That led us toward a very different architecture. Ingest information rather than requiring everything to be manually entered. Create an ontology that gives information meaning. Build a knowledge graph that understands relationships across the organization. Give an agent persistent organizational context. Equip that agent with skills specific to risk and resilience. Allow it to identify gaps, recognize change, make proposals, and perform work. Keep humans in the loop where experience, accountability, and judgment matter. And, most importantly, don't assume that today's workflows have to be tomorrow's workflows.

That last point may be the most important.

Our objective isn't to use AI to make someone complete a BIA questionnaire 30% faster. It is to ask whether that questionnaire needs to exist in its current form. It isn't simply to use AI to write a continuity plan faster. It is to ask whether a plan should increasingly assemble itself from what the organization already knows. It isn't merely to summarize a risk assessment. It is to ask whether emerging changes in the organization should continuously inform our understanding of risk.

The opportunity isn't just faster work. It's better outcomes through a different way of working.

Bolt-On AI Isn't Bad. It May Simply Be a Stage.

None of this means bolt-on AI is useless. Far from it.

Graphical interfaces layered onto legacy systems delivered enormous value. Web-enabling existing applications delivered enormous value. Moving traditional workloads into the cloud delivered enormous value. Transitional architectures are often how industries learn what the next generation should become.

AI may be no different. Adding AI to existing enterprise software can improve productivity today while teaching us what users actually want from intelligent systems tomorrow. But history also suggests we shouldn't confuse the transitional architecture with the destination. Eventually, software designed around the assumptions of the previous generation tends to give way to software designed around the capabilities of the next one.

We believe that transition is beginning now.

The Question Isn't Whether Your Software Has AI

Soon, virtually every enterprise application will be able to claim that it “has AI.” That distinction will become meaningless. The more useful questions will be different.

• Does the AI understand the context of my organization?

• Can it reason across information rather than simply retrieve it?

• Does it understand relationships and dependencies?

• Can it recognize when something changes?

• Can it recommend what should happen next?

• Can it perform meaningful work while keeping humans appropriately in control?

And perhaps most importantly:

Did AI make the old software easier to use, or did it unlock an entirely better way of working possible?

We've watched this pattern before. Green screens gave way to graphical applications. Client-server gave way to the web. On-premise software gave way to SaaS. Each transition started by bringing the new technology to the old model.

Eventually, someone stopped asking how to improve the old model and started designing around what the new technology made possible.

AI may be the next chapter in that same story. And this time, the transition may happen much faster.