What happens when intelligence stops living in one model?

I have spent most of my career thinking about products, systems, organizations and the messy space between them.

For roughly the last 18 months, I have been thinking much more seriously about AI.

At some point, those two lines of thinking collided.

I found myself asking a question that initially seemed almost obvious:

If AI models keep becoming more capable, what happens when an enterprise has dozens of them, thousands of agents, millions of pieces of organizational knowledge, hundreds of systems, and humans still making consequential decisions?

The answer, I thought, was orchestration.

Then I started looking.

And I discovered that I wasn't the first person to think about it.

Researchers were already talking about compound AI systems. The industry was building agent frameworks. Anthropic had introduced MCP. Google and others were working on agent-to-agent interoperability. Multi-agent patterns such as planners, critics, supervisors and workers were becoming established architectural approaches.

So this isn't a story about discovering a missing technology.

It is a story about arriving at a question from one direction, finding an existing body of work around it, and then trying to understand what it means for the enterprise.

The question that remains interesting to me is this:

Are we still thinking about AI primarily as intelligence inside a model, when we should increasingly be thinking about intelligence emerging from a system?

1. The Thing That Didn't Sit Right

The dominant AI story is remarkably intuitive.

Make the model better.

Give it more data.

Give it more compute.

Give it more context.

Make it reason better.

Then give that increasingly capable model access to tools and information.

There is nothing wrong with this approach.

In fact, it has produced extraordinary results.

But coming from a product and systems background, something about the framing bothered me.

An enterprise isn't a model.

It isn't even an AI application.

An enterprise is a collection of systems, people, processes, knowledge, policies and decisions.

AI enters that environment rather than replacing it wholesale.

That means the interesting question isn't simply whether an AI model can solve a task.

It is whether the enterprise can coordinate all the intelligence available to it.

That distinction became the starting point for this line of thinking.

2. I Thought I Had Found Something New

This is where the story gets more interesting.

My first instinct was to think:

We are missing an orchestration layer.

Then I started reading the research.

Berkeley AI Research had already introduced the idea of compound AI systems: systems in which multiple AI components work together rather than relying on a single monolithic model.

The idea is straightforward.

Instead of asking one model to do everything, compose systems from models, retrieval, tools and other components.

That sounded familiar.

Then came MCP — the Model Context Protocol — designed to standardize how AI applications connect to external tools and context.

Then A2A — Agent2Agent — aimed at enabling agents built by different systems to communicate and collaborate.

And around them, an expanding ecosystem of multi-agent architectures.

Planner and executor.

Supervisor and workers.

Critic and generator.

Debate.

Specialists.

These aren't speculative ideas anymore.

They are becoming part of the architecture of AI systems.

Which forced me to revise the original thesis.

Orchestration isn't something the industry has forgotten.

It is something the industry is actively building.

The interesting question is what happens when we take that capability seriously at the enterprise level.

3. Capability Is Not Intelligence

This is the distinction that has become increasingly important to me.

A model has capabilities.

It can reason.

Write.

Code.

Analyze.

Search.

Generate.

Use tools.

But enterprise intelligence is something larger.

Consider a cybersecurity decision.

A detection system identifies suspicious activity.

An investigation system gathers evidence.

Identity systems provide information about the user.

A knowledge system provides historical context.

A policy engine determines what actions are permissible.

An AI model interprets the evidence.

Another model might challenge the initial conclusion.

A security analyst decides whether the evidence is sufficient.

A workflow executes the response.

Governance records what happened.

Which one is the intelligence?

The answer is uncomfortable.

None of them, individually.

The intelligence emerges from how they interact.

That leads to a distinction I find useful:

Capability is a property of a component.
Intelligence is a property of a system.

A more capable model gives the system a more capable component.

It does not automatically make the system more intelligent.

4. Scaling Intelligence vs Orchestrating Intelligence

This is where my thinking currently lands.

I don't see these as competing strategies.

We will continue scaling models.

We should.

Better models expand the capability available to every system built on top of them.

But scaling changes the components.

Orchestration changes what those components can accomplish together.

That creates an interesting paradox.

The more capable the components become, the more important the architecture connecting them may become.

A brilliant individual can make a brilliant decision.

But an organization doesn't make decisions through one individual.

It makes them through information, expertise, authority, constraints, processes and people interacting with one another.

AI systems may be heading in the same direction.

5. The Enterprise Makes This Much Harder

This becomes obvious once you look at what an enterprise already contains.

ERP.

CRM.

Identity.

Security.

Finance.

HR.

Customer data.

Operational data.

Knowledge bases.

Policies.

Workflows.

Humans.

Approvals.

Regulatory constraints.

Now add AI.

The instinct is often to put an AI layer over everything.

But the hard questions immediately appear.

Which information should the AI see?

Which source is authoritative?

Which policy applies?

Which tool should it use?

When should another agent be involved?

When should the system stop reasoning?

When should a human take over?

Who has authority to approve the action?

What happens when two sources disagree?

How does the enterprise learn from the outcome?

These aren't merely model questions.

They are system questions.

And increasingly, they are enterprise design questions.

6. The Infrastructure Is Arriving

One reason this topic feels different now is that the underlying infrastructure is beginning to catch up with the idea.

MCP provides a common way for AI applications to connect with tools and external context.

A2A addresses communication between agents.

Multi-agent frameworks make it increasingly straightforward to distribute work across specialized AI components.

The industry is building the plumbing.

That matters.

But plumbing isn't the same thing as an operating model.

A protocol can allow two agents to communicate.

It doesn't tell you whether they should.

A framework can let five agents collaborate.

It doesn't tell you whether five agents will produce a better decision than one.

A debate architecture can create disagreement.

It doesn't guarantee that the disagreement is useful.

And this is where I think the enterprise question becomes interesting.

Once orchestration becomes technically possible, what should we actually orchestrate?

7. A Different Way to See the Enterprise

I've started thinking about the emerging enterprise intelligence stack like this:

Applications
↓
Agents
↓
Models
↓
Tools
↓
Knowledge
↓
Policies
↓
Humans
↓
Governance
↓
Infrastructure

This isn't meant to be a canonical architecture.

It is a mental model.

Applications provide context and execution.

Agents provide specialization.

Models provide reasoning capability.

Tools provide action.

Knowledge provides memory.

Policies establish constraints.

Humans provide judgment and authority.

Governance provides accountability.

Infrastructure connects everything.

The interesting part isn't any individual layer.

It is the space between them.

That is where intelligence gets translated into decisions.

And decisions get translated into action.

8. The Question Changes

Once I started looking at AI this way, I noticed something else.

We tend to optimize individual layers.

Model performance.

Agent performance.

Retrieval quality.

Tool reliability.

Workflow automation.

But an enterprise doesn't ultimately care about the performance of these components in isolation.

It cares about outcomes.

Revenue.

Risk.

Security.

Customer experience.

Speed.

Quality.

Capital allocation.

Strategic decisions.

Is the Sum greater than its parts?

So perhaps the higher-order optimization problem is:

How do we coordinate the right combination of models, agents, data, tools, policies and humans to produce better enterprise decisions?

That creates a completely different set of questions.

When does adding another agent improve the outcome?

When does it merely add latency and cost?

When is disagreement useful?

When does disagreement become noise?

When should models challenge one another?

When should they converge?

When should a deterministic rule override a model?

When should a human override the entire system?

And perhaps the most important:

How does the enterprise learn from the decisions it makes?

These are not questions that a larger model answers automatically.

9. What This Means for Leadership

This also changes how I think about leadership in an AI-enabled enterprise.

The traditional boundaries remain useful.

Product understands outcomes.

Engineering understands systems.

Architecture understands integration.

Data understands information.

Security understands risk.

Legal and compliance understand constraints.

Business leaders understand trade-offs and authority.

AI specialists understand models and agents.

But intelligence now crosses all of those boundaries.

Someone has to design how they work together.

That doesn't necessarily mean creating a new job title.

It means developing a new capability.

The ability to decide:

where intelligence should live, how it should interact, what constrains it, where humans belong, and how the system learns.

That is what I mean by orchestrating intelligence.

Not simply deploying more AI.

Not simply connecting more agents.

Designing the system in which intelligence becomes useful.

10. The AI Council: Putting the Idea to Work

This is where an experiment of mine comes in.

I've been building an AI Council to test some of these ideas in practice.

The premise isn't particularly novel.

Multi-agent debate and critic architectures already exist.

And I'm not interested in claiming that putting several models in a room magically produces superior intelligence.

The question is much more practical:

Can deliberately orchestrated disagreement produce better decisions than asking one model for an answer?

The council gives different models different roles and perspectives.

One can challenge an assumption.

Another can investigate.

Another can synthesize.

A human can introduce context and judgment.

The system can then attempt to converge.

But the experiment has also made the limitations visible.

More agents can mean more cost.

More perspectives can mean more noise.

More reasoning can mean more latency.

A council can create the appearance of rigor without actually improving the decision.

And if the models share the same assumptions, five voices may simply be one voice wearing five hats.

That is precisely why the experiment matters to me.

Not because the pattern is new.

Because the results are real.

What worked?

What failed?

Where did orchestration create leverage?

Where did it create complexity?

When did multiple perspectives actually improve the outcome?

Those are the questions I want to explore next.

11. Where This Leaves Me

I started with what felt like a simple observation:

AI models were getting better, but enterprises were going to need more than better models.

Then I discovered that researchers, engineers and companies were already building toward that idea.

That was useful.

It changed the question.

I'm no longer interested in arguing that orchestration is a hidden idea the industry hasn't discovered.

It isn't.

I'm interested in what happens when we take orchestration seriously as an enterprise design problem.

Because there is a fundamental difference between:

making intelligence more capable

and

making intelligence work together.

The first is largely a model problem.

The second is a system problem.

And the second becomes increasingly important as the first succeeds.

That, for me, is the interesting paradox.

The better AI gets, the less useful it may become to think about AI as a single thing.

The unit of intelligence may be shifting.

From the model.

To the system.

From capability.

To coordination.

From AI as a component.

To intelligence as an enterprise property.

I don't yet have all the answers.

I'm trying to build my way toward them.

The AI Council is one experiment.

This series is another.

And the next question I want to explore is perhaps the biggest one:

If an enterprise can orchestrate intelligence, what should the operating system for that intelligence actually look like?