The AI Model Is the Engine. But the Enterprise Needs the Whole Machine.

AI models are advancing at an extraordinary pace.

They reason better, handle more context, use tools, plan, and increasingly execute complex tasks autonomously.

Enterprises have largely understood that an LLM alone will not transform their business. They are looking for platforms that allow them to put AI to work.

Microsoft is building around Copilot and agents. Anthropic is expanding Claude with tools for getting work done. OpenAI is building its own agentic platform.

This makes perfect sense.

Frontier model providers want to bring their models into as much everyday work as possible. The easier their platforms are to adopt, the more AI gets used — and ultimately, the more tokens get consumed.

But there is an important distinction:

Easy AI adoption and enterprise transformation are not the same problem.

An LLM is an engine

I find the combustion engine a useful analogy.

The combustion engine was a technological revolution. But an engine is not a car, excavator, tractor, power generator, or fighter jet.

All these machines may rely on similar underlying principles, but each requires a completely different system around the engine:

• Different controls and power transmission
• Different safety mechanisms
• Different operating and maintenance procedures
• Different requirements for the operator
• And, most importantly, a completely different purpose

I see LLMs as a similar technological component.

They are extraordinarily versatile engines for knowledge work. The same underlying model can power a personal assistant, coding copilot, analytical tool, customer-service chatbot, or autonomous Digital Employee.

But just as an engine is not an excavator, an LLM — or even an agent runtime — is not a new way of running an enterprise.

Building blocks are not an operating model

Today's AI platforms provide increasingly powerful building blocks:

• Models and agent runtimes
• Memory and context
• Tools and connectors
• Enterprise search and identity
• Workflows and human-in-the-loop controls

These are important components. In many cases, exceptional ones. But standardized building blocks do not imply a standardized enterprise.

They give companies components from which to build. They do not define what should be built, how it should operate, or how authority, accountability, security, and organizational context should work inside a particular organization.

We cannot expect Microsoft, OpenAI, Anthropic, or anyone else to create one universal AI operating model equally suitable for a bank, pharmaceutical company, logistics provider, hospital, and manufacturer. Or even for two different banks.

Enterprises differ in their:

• Organizational structures and processes
• Systems and data
• Regulatory environments
• Cultures and risk appetites
• Delegation models and distribution of responsibility

AI does not make these differences disappear.

SAP has already taught us this lesson

Enterprise software has dealt with this problem for decades. SAP comes relatively close to providing a standardized model of how an enterprise should operate, with reference processes, best practices, and data models derived from thousands of organizations.

Yet virtually no large enterprise simply switches SAP on and starts operating.

Companies spend enormous amounts on:

• Implementation and integration
• Configuration
• Process redesign
• Organizational transformation

Some customization is undoubtedly unnecessary. An SAP consultant may tell you that if your process differs from SAP standard, the problem is your process.

Sometimes they are right.

But not always.

Differences between organizations are real.

If we have never created one universal operating model for relatively deterministic enterprise processes, it seems optimistic to assume we will create one for autonomous AI.

The building blocks can be standardized. Your operating model cannot.

"Where the user can go, the agent can go" is not enough

A tempting way to simplify AI adoption is to give an agent the context and permissions of its user.

Where the user can go, their AI can go.

For a personal assistant, that is a practical starting point.

For autonomous work, it is not an operating model.

Consider a procurement director with access to contracts, supplier proposals, internal pricing, analyses, and budgets.

Does that mean an AI acting on their behalf can:

• Select a supplier?
• Disclose internal pricing?
• Negotiate commercial terms?
• Make a financial commitment?
• Reuse information obtained in one context in another?

And when does it need approval? Who is accountable for the outcome?

These are not questions a larger context window will solve.

They are questions of organizational design.

Complexity can be hidden. It cannot be eliminated.

We are trying to hide enterprise complexity behind simple AI interfaces.

From a UX perspective, that is exactly what we should do.

But the underlying complexity does not disappear.

If we do not explicitly address it in architecture and the operating model, we move it somewhere else — increasingly, into the model itself.

We expect the model to infer from context:

• What it may do
• Which information is sensitive in a particular situation
• When approval is required
• When work should be handed to a human

That is problematic precisely because an LLM is probabilistic.

Organizational governance cannot simply be an emergent property of prompts and context.

A frontier model just showed us why

A recent security incident during frontier-model testing provides an interesting demonstration.

During an internal cybersecurity benchmark, frontier models were tasked with solving exploitation challenges inside an isolated environment.

The boundary was not sufficiently robust.

The models discovered a vulnerability in one of the few permitted network mechanisms, gained broader network access, and eventually reached third-party production infrastructure while looking for information that could help solve the benchmark.

The interesting part is not that the AI became malicious.

It didn't need to "want to escape."

It was doing its job.

The sandbox was not a moral or organizational boundary to the model. It was part of the technical environment through which the model searched for a path toward its objective.

The intended boundary existed.

But the system had left a path around it.

Boundaries must exist outside the model

Autonomous AI makes it difficult to enumerate every path a sufficiently capable model might discover while pursuing an objective.

And many important enterprise boundaries are not simple technical restrictions.

• Technical: "Do not call this API."
• Semantic: "You may know this information, but not use it in this commercial context."
• Organizational/legal: "You may create this purchase order, but not create a new legal commitment."
• Operational: "You may operate autonomously until the risk exceeds our tolerance."

Enterprises need to enforce all of them.

Which is why an apparently obvious point is worth repeating:

The more capable AI becomes, the less we can afford to rely on the model itself as the place where governance happens.

The next phase of AI adoption

A better sandbox is necessary. But it addresses only one class of boundary.

An enterprise AI operating model has to answer much broader questions:

• Who is this AI within the organization, and who is accountable for it?
• What is it responsible for, and what authority does it have?
• What information may it use, and in which context?
• When can it act autonomously, and when must a human intervene?
• How is its work audited, measured, changed, revoked, or stopped?

An LLM provider cannot answer these questions for an enterprise.

Every organization has to answer them for itself.

Frontier AI platforms will remain enormously important. They will provide increasingly capable models, runtimes, tools, connectors, identity mechanisms, context systems, and other building blocks.

Some will become standards. Others will become commodities.

But enterprises still need to determine how those components fit into the way their organization actually works.

They need to define their own AI operating model.

And that operating model cannot remain a PowerPoint architecture or a set of governance principles.

It has to become executable.

It must be reflected in:

• Identity and authority
• Policy enforcement and context boundaries
• Workflows and human oversight
• Auditability and organizational accountability

This is where I believe an important and still relatively open category of enterprise AI is emerging:

• Not another model
• Not another universal agent
• Not another collection of AI building blocks

But a platform in which an enterprise can explicitly define, operate, govern, and continuously evolve its own AI operating model.

This is the direction we are taking with AyDEO.

The objective is not to prescribe how every company's digital organization should work. It is to provide an environment in which enterprises can define their own digital workforce — its roles, responsibilities, authority, organizational relationships, policies, security boundaries, and ways of working with humans.

Because the AI model is the engine.

Microsoft, OpenAI, Anthropic, and others are building increasingly powerful engines and increasingly sophisticated building blocks around them.

But every enterprise still has to build its own machine.

And designing that machine may turn out to be a much bigger part of AI transformation than we currently assume.