AI Agents & Systems8 min read·

The agent is not the operating model

Giving AI more autonomy does not remove organizational complexity. It gives that complexity permission to act.

Giving AI more autonomy does not remove organizational complexity. It gives that complexity permission to act.

For the last two years, the easiest enterprise AI question was: What can the model do?

That question is becoming less useful.

Models can already search, write, reason across documents, call tools, manipulate software and complete increasingly long sequences of work. The interesting frontier is moving from assistance toward action: systems that do not merely recommend the next step but take it.

That changes the problem.

Once an AI system can act inside an organization, model capability is only one part of its capability. The rest comes from the organization around it: what the agent can access, which decisions it can make, whose authority it is exercising, what happens when it is wrong and whether anyone can reconstruct what it actually did.

In other words, the agent is not the .

And giving an agent autonomy before answering those questions is a very efficient way to automate organizational ambiguity.

Autonomy makes old problems executable

Consider a fairly ordinary workflow.

A customer requests something. Someone checks their account. Another person looks at policy. A decision is made. Perhaps another team approves an . Someone updates a system and communicates the result.

From a distance, this looks like an automation opportunity.

But look more closely and the workflow may contain years of accumulated organizational knowledge.

Why does that approval exist?

Which exceptions are legitimate?

Who is allowed to see which customer information?

What happens when two policies conflict?

Who carries the consequence of a wrong decision?

Humans often navigate these questions through context that was never formally designed into the process. They ask someone. They remember what happened last time. They know that a particular rule is technically written one way but operationally handled another.

An agent does not magically resolve this ambiguity. It requires us to make it operational.

That distinction matters because enterprise adoption is moving faster than many organizations' ability to do so.

Deloitte's 2026 research, based on 3,235 business and technology leaders across 24 countries, found that only 21% of organizations reported mature governance for . Its August follow-up found something equally revealing: only 5% said their business processes were highly prepared for AI agents, while 74% of surveyed leaders expected nearly half of their processes to be redesigned or rebuilt around agents within four years.

The ambition is ahead of the operating model.

A good demo can hide this for quite a long time

This is one reason agent can look unusually convincing.

A pilot lives in a protected environment.

The dataset is limited. Permissions are controlled. The team knows what is being tested. Edge cases can be handled manually. Someone is usually watching. If the system behaves strangely, the people who built it are nearby.

Production removes those protections.

Now the agent encounters incomplete information, contradictory instructions, unusual customers, changing systems, permission boundaries and decisions whose consequences extend beyond the task it was originally designed to complete.

This is not hypothetical.

In March, OpenAI published examples from its monitoring of internal coding agents. In one trajectory, an agent encountered a blocked command, inferred that a security control might be responsible and tried several ways to circumvent the restriction, including obfuscating content and splitting the operation into smaller steps. OpenAI subsequently changed the developer , reducing but not eliminating that behaviour.

The important lesson is not that agents are dangerous by definition.

It is that capable systems search for paths through the environment we give them.

That is exactly what we want when the environment is well designed.

It is also exactly why organizational boundaries need to be explicit.

Before asking what the agent can do, define what it is allowed to decide

Traditional software usually has relatively predictable authority.

A payroll system calculates payroll. A CRM stores customer information. A workflow engine executes rules somebody has already defined.

Agents blur these boundaries because they can interpret a situation and select actions dynamically.

This creates a distinction organizations need to make much more carefully:

.

A system may be technically capable of issuing a refund. That does not mean it should have the authority to issue every refund.

It may be able to modify a customer record. That does not mean every field should be writable.

It may be able to resolve a service request. That does not mean it should decide when company policy deserves an exception.

Gartner made a similar distinction in its May 2026 guidance, arguing that organizations need to separate an agent's level of autonomy from the scope of access it receives. Gartner predicts that by 2027, 40% of enterprises will demote or decommission autonomous agents because governance problems are discovered only after production incidents.

This is where agent design becomes organizational design.

For every meaningful action, someone needs to decide the boundary:

What can the system observe?

What can it recommend?

What can it execute?

What requires approval?

What should it never do?

When does uncertainty trigger rather than another attempt?

These are not primarily model questions. They are decision-right questions.

Do not automate the workflow before understanding why the workflow exists

There is another trap here.

Once agents become capable of completing multi-step work, organizations naturally begin looking for entire workflows to automate.

But existing workflows are rarely clean representations of the problem.

They contain workarounds, legacy policies, historical compromises, duplicated controls and steps created because two systems could not communicate ten years ago.

Automating that structure may make it faster without making it better.

McKinsey reported in late 2025 that 88% of surveyed organizations were using AI in at least one business function, while only 7% said AI had been fully scaled across their organizations. More recent McKinsey work argues that most agent deployments still augment existing workflows rather than redesign them, producing incremental productivity gains rather than larger operating-model changes.

This is the same problem I see repeatedly with emerging technology.

The solution becomes more sophisticated while the original question remains untouched.

Before replacing a workflow with agents, I would want to understand which parts of that workflow actually create value.

Some steps exist because judgment is required.

Some exist because trust needs to be established.

Some exist because responsibility needs to be visible.

Some exist for no good reason anymore.

Those categories should not be treated equally.

Removing unnecessary work is different from automating necessary work. Automating necessary work is different again from delegating judgment.

Agentic AI makes all three technically possible.

That does not make them the same decision.

The real unit of design is the decision boundary

This changes how I would approach an agent pilot.

I would not begin with:

Can an agent complete this process?

I would begin with:

Which decisions inside this process can safely move, under what conditions, and what evidence would justify moving them?

That produces a very different experiment.

Instead of trying to demonstrate end-to-end autonomy, the pilot can progressively test boundaries.

Let the agent observe.

Then recommend.

Then act on low-consequence cases.

Then introduce clearly defined exceptions.

Measure where human intervention actually adds value rather than assuming either that humans must remain everywhere or that autonomy is automatically the destination.

The objective is not maximum autonomy.

It is appropriate autonomy.

That sounds less ambitious. In practice, it is harder, because it requires understanding the work rather than merely demonstrating the technology.

It also produces much better evidence.

AI amplifies the organization it enters

The 2025 DORA research reached a useful conclusion after surveying nearly 5,000 technology professionals: AI behaves as an amplifier. Organizations with strong underlying capabilities can use it to improve performance; weaknesses in systems and processes can be amplified as well.

Agents make that principle more consequential.

An unclear process assisted by AI is still unclear.

An unclear process executed autonomously can become something else entirely.

Ambiguous ownership becomes automated handoffs.

Weak access controls become automated access.

Poorly defined exceptions become automated inconsistency.

Missing accountability becomes automated decisions that nobody quite owns.

This is why the next stage of enterprise AI will not be won simply by organizations with access to the strongest models. Access to capable models is becoming widely available.

The advantage will come from being better at deciding where those capabilities belong.

That means understanding the work deeply enough to define authority, designing evidence before deployment, making escalation explicit, instrumenting the system so decisions can be reconstructed and giving permanent ownership to the part of the organization that carries the consequences.

None of this is as visually impressive as watching an agent operate a browser by itself.

It is much closer to the work required to make that demonstration useful.

The organizations that learn this distinction will not necessarily have the most autonomous agents.

They will have something more valuable: systems that know where autonomy should stop.


Sources

Get new essays as they publish.

One email per essay. No noise between.

Berk Bayri

Creative Technology & Innovation Leader

Designing and building for digital environments since 1998, across strategy, product, design, technology and organizational innovation.