The Integration-Automation AI Framework (2026 Update)

I first published the Integration-Automation AI Framework back in 2023.

Since then, it has become a central piece of my work. I’ve frequently used it in keynotes and dedicated a section in my book.

Today, I still use it a lot because it gives decision makers a simple way to think about a very confusing AI landscape.

(Almost 3 years is a lifetime in AI, so I guess it can't be that bad!)

But the technology has evolved significantly. Agents are no longer experimental toys, and AI is now embedded across mainstream business software.

So I decided it was time for an update.

Here's the Integration-Automation AI Framework for 2026.

The basics haven’t changed at all.

I still find it useful to classify business AI use cases along two independent dimensions:

Those two dimensions give us four basic types:

Don’t obsess over these terms too much. Everyone uses them differently.

Microsoft, for example, bundles much of its AI products under the Copilot brand. But they also give you “Copilot agents,” which shows how quickly the terminology starts to blur.

Other vendors just call everything – even simple chatbots – AI Agents because it’s simply the zeitgeist.

So don't get too hung up on the labels.

Instead, look at what the solution actually does – and what you need it to do.

That usually tells you much more.

Let’s go through the 4 types.

Assistants are AI solutions with relatively low integration and low automation.

Tools like ChatGPT or Claude, as they come out of the box in basic chat mode, are the best example.

By default, they’re not connected to your internal systems and they don’t do anything without your prompt. You have to log in, provide relevant context, prompt them, take the result and then decide what to do with it.

Typical use cases are:

To be clear, you can turn these tools into much more powerful platforms than that. You can connect them to your internal files, run tasks automatically on a schedule, or use them to code apps.

But they don’t do this by default.

You have to actively set this up.

That’s why I still classify the basic chat experience as an Assistant: it waits for your command, helps you with the task, and leaves the execution with you.

= “I need answers when I ask.”

Copilots are similar to Assistants, but they’re more integrated into the tools you use every day.

The AI can typically access relevant context without you having to manually move that context into a separate tool.

For example:

Instead of opening a separate AI application and bringing your work to the AI, the AI comes to where you already work.

Usually, Copilots come as vendor solutions sold with the software you already use, sometimes as an add-on.

A Copilot may suggest, draft, summarize, or surface relevant context – but a person still owns the work by reviewing, changing, or acting on the AI output.

= “Help me in the tool I already use.”

As we move to the right side of the framework, something changes fundamentally.

We’re moving from helping to perform the task to performing the task.

An Autopilot performs a defined job automatically, but inside a relatively narrow lane.

Imagine an AI-powered support system that automatically answers common customer questions based on your documentation.

It may handle hundreds of conversations without anyone approving each response.

That’s a high degree of automation.

But if the customer asks for a refund, the system can’t do it. If someone wants to update an order, there’s no connection to the ERP. No CRM access.

The system is designed to do one well-defined job automatically, not more.

Other Autopilot examples include AI systems that automatically:

All without a human approving each individual action.

= “Do this automatically for me.”

Agents are where most of the attention is right now.

Unlike Autopilots, they don't just execute one narrow task in a predefined way.

Instead, you give them a goal, access to tools and some boundaries, and they decide how to get there.

For example:

An Agent might inspect the customer history, query a knowledge base, check the status of an order, decide whether a refund is appropriate, update the CRM and send a response.

The important part is that you didn't prescribe every step.

The Agent decides how to reach the goal.

“Figure out how and do it for me.”

For this, it needs high integration – access to the systems around it – and high automation – the ability to perform the necessary steps without much handholding.

This might sound complex to you, but in fact, AI Agents are no longer particularly hard to build. Any reasonably technical person can put together an impressive Agent demo over lunch.

The difficult part is operating AI Agents inside a real organization.

Because giving an AI autonomy plus access to your systems doesn't remove the need for human responsibility. It increases the need.

AI Agents are dogs, as I call it.

And while the technology is increasingly ready, organizations typically aren't.

The framework also separates two very different economic games.

The left side – Assistants and Copilots – is Productivity AI.

AI helps a human work faster or better, but a human still produces the outcome.

The right side – Autopilots and Agents – is Engineered AI.

The system executes the work itself. The outcome is produced by the system, which now needs to be owned, monitored and operated.

The problem starts when companies pay for Engineered AI but only capture Productivity AI benefits.

Like building a “Company Second Brain” with a complex RAG setup and ongoing maintenance. If the main outcome is simply “Our employees spend less time doing research” you might be funding an Engineered AI architecture for only marginal productivity gains.

Whether that investment is justified depends heavily on how important that research task is for your company.

This is where I use this framework as an economic tool as well:

Profitable AI determines how much architecture your business case deserves.

The goal isn't to move every use case toward the most sophisticated architecture.

Build only as much system as the anticipated outcome justifies.

I still believe that Assistants are usually the best place to start.

You can learn quickly:

Get proof before you plumb.

From there, only add what the use case actually needs.

If using AI outside the workflow creates too much friction, increasing integration and moving toward a Copilot-type solution makes sense.

If the task is repetitive and predictable enough to run without constant human involvement, increasing automation makes sense.

If the system needs to interact with multiple tools and figure out its own route, you may need an Agent.

The goal isn’t necessarily to reach the top-right corner. The goal is the simplest architecture that solves the problem – and that your organization is ready to operate.

Going in reverse gets expensive fast. Once you start plumbing an Agent into the organization, building integrations, permissions and processes before proving the use case, you’ll likely end up burning a lot of money and trust.

So, next time someone says:

“We need an AI Agent.”

Ask three questions:

Then keep calling it an Agent – and build an Autopilot anyway.

That’s the Integration-Automation Framework.

Let’s see if it survives another three years.

See you next Saturday,
Tobias