Vol. III · Essays on work after AI
Saturday, October 3, 2026
evolving.work
Architecture · Models · Essay № 057

Centralized Intelligence vs Orchestrated Intelligence: Why Your Model Choice Is Really a Systems Choice

Frontier models are not just different in quality — they express fundamentally different bets on how intelligence should be organized.

H Héctor Reinoso Aug 24, 2026 11 minute read Share · Save

What Model Rankings Leave Out

Most comparisons between frontier models focus on who is better. That matters, but it misses the more interesting distinction.

Pull up any 2026 model roundup and the table looks like a benchmark drag race: context windows in millions of tokens, SWE-bench scores in the eighties, latency in milliseconds. Useful, but the rankings churn every quarter. What persists across the churn is something the benchmarks do not capture — the way each model organizes the work of being intelligent.

I have spent the last year watching teams pick models the way you might pick a phone. They scan the spec sheet, find the highest score, and standardize on it for the next six months until the next launch resets the conversation. The interesting thing is that the teams getting more out of AI are doing the opposite. They run two or three models. They route between them. And if you ask them why, they tend to wave a hand and say something like “well, this one is better for the long stuff.” They have noticed the distinction the benchmarks do not measure. They have just not named it.

One model family is betting that more capability should be absorbed into a single learned control system. The other is betting that structure, persistence, and task decomposition across long trajectories deserve more explicit weight [5]. GPT-5 operates as a router-based system, switching internally between rapid response and extended reasoning. Claude uses Adaptive Thinking to allocate reasoning depth dynamically and Agent Teams to coordinate sub-tasks. Two leading systems, both excellent, expressing two different bets on where intelligence should live.

This is not a quality ranking. It is a philosophical divergence — and it is becoming one of the most consequential architectural decisions in enterprise AI.

Centralized Intelligence: One Model, Internal Routing, Unified Control

A centralized intelligence model tends to feel like a very strong general operator.

You give it work. It decides how much reasoning to spend, which expert paths to activate, which modality layer to engage. The control loop is folded inside the model. The product surface looks like one thing. Underneath, it is doing a lot of routing — just where you cannot see it.

Mixture of Experts is the hardware substrate for this. Since early 2025, nearly all frontier models use MoE designs, and over 60% of open-source releases have adopted it [2]. NVIDIA reports that MoE on Blackwell delivers roughly 10x performance-per-watt and 10x cost-per-token reductions versus prior dense architectures [3]. An architecture roundup from Largo.dev calls MoE “the default for frontier models” in 2026 — convergence at the substrate level, divergence at the philosophy level.

The mildly amusing part is that “one model” is actually a committee. MoE routes every token to a subset of expert sub-networks. The unification is in the user experience, not the computation. But the committee is inside the model boundary, the routing decisions are the model’s own, and from outside you call one API. From the user’s seat, it is one mind. That framing is the centralized bet — not “no routing” but “all the routing folded into one boundary.”

Google’s Gemini 3 Pro is the purest expression of this bet [9]. It implements a true unified embedding space where text, vision, audio, and code coexist as first-class citizens in one latent representation. One model, one representation space, one reasoning loop. The strength is real: tightly coupled cross-modal tasks — where coordination overhead between specialists is the bottleneck — get faster and cleaner. The cost of an orchestration handoff is zero when there is no handoff.

That is the centralized bet, distilled: absorb the routing, eliminate the seams.

Orchestrated Intelligence: Deep Work, Long Horizons, Explicit Coordination

An orchestrated intelligence model tends to feel more like a system built for deep, structured work over long horizons.

The orchestrated bet inverts the centralized one. Instead of folding control into the model, it makes control explicit — persistent context, structured decomposition, sub-agents with their own scratch space, verifiable handoffs between steps. Claude Opus sits at this end. Opus 4.5 reportedly posted an 80.9% SWE-bench score in Largo.dev’s 2026 comparison — the highest among frontier models in that roundup. The result comes less from raw scale than from coordinated reasoning sustained across long trajectories. You can feel it when you use it. The model holds a problem the way an engineer holds a refactor — for hours if needed, without losing the thread.

The pattern is already showing up in deployment. The most common production setup among enterprise teams in 2026 is the 80/20 split: GPT-5.4 for roughly 80% of tasks — fast, broad, cost-efficient — and Opus 4.6 for the hard 20% that need deep reasoning, long-context coherence, and high-stakes accuracy [6]. Nobody told them to do this. They arrived at it by working with the tools and feeling where each one shines.

Million-token context windows are now common across Claude, Gemini, GPT, and Kimi K2. TeamAI’s 2026 comparison puts the differentiator bluntly: “Long context is table stakes; efficient long context is the differentiator.” The question has shifted from “can it see the whole document?” to “does it actually attend to all of it intelligently?” That second question is the territory orchestrated intelligence was built for.

A Parallel in Software Architecture

The monolith-to-microservices transition offers a useful comparison.

Software architecture went the same way: monolithic to modular, single deployment to composable services, one runtime to many. Gartner now identifies composite AI — modularly combining multiple AI and non-AI technologies — as one of its strategic technology trends for 2026, and forecasts 50% of enterprises will shift from monolithic to modular AI architecture by 2028 [4]. MixFlow, citing McKinsey’s 2025 Global AI Survey, reports that composite AI adopters achieve 2.4x higher AI project production rates than single-LLM strategies [7]. IDC pushes further: by 2028, 70% of top AI-driven enterprises will use multi-tool architectures for dynamic model routing [1].

This is the second time enterprise architects have walked this road [10]. The lessons from the first pass still apply: interface contracts, observability, graceful degradation, blast-radius containment. The CTO Advisor’s recent piece on AI control layers makes a sharper version of the same point — the value of decomposition was never just performance; it was the ability to insert logic between steps, enforce rules before execution, and trace how outputs were generated. Routing AI requests is a control problem before it is a performance problem.

This is not just a product distinction. It is a systems distinction.

One limit to the comparison: the software analogy is instructive but incomplete. AI systems have emergent behaviors that microservices do not. They surprise you in ways modules cannot. A misbehaving microservice throws an exception; a misbehaving model writes you a paragraph explaining why it is right. The same disciplines apply, but the failure modes are different in kind, and the observability stack you used for services will not be enough for models.

Is This Just Temporary?

What looks like a philosophical divergence may simply be different companies at different points on the same convergent roadmap.

The history of platforms supports it. Browsers converged. Operating systems converged. Cloud platforms converged. If OpenAI adds persistent memory, long-context orchestration, and agent teams to GPT, and Anthropic adds internal routing and faster response modes to Claude, the two approaches collapse into the same thing. The distinction the thesis draws becomes a snapshot of 2025-2026 product positioning rather than an enduring architectural principle.

That risk is real. Surface feature convergence is probable, and worth taking seriously.

But there is a layer below the surface where convergence is not free. MoE inference requires disaggregated serving — physically different GPU pools for prefill versus decode phases, expert parallelism orchestrated through frameworks like NVIDIA’s Dynamo [8]. That is not a product feature to be toggled on. It is foundational infrastructure that took years to build and constrains what each system can efficiently optimize for. The labs that built this way will keep optimizing it. The ones that did not will not retrofit it cheaply.

Even the academics are careful here. A recent arXiv paper on agentic AI (“The Cartesian Cut”) frames the centralized-versus-orchestrated split as two design directions, not a settled hierarchy — and notes that bounded external control is sometimes a safety choice, not a capability ceiling. Intelligence Strategy’s 2026 briefing puts it more strongly: “AGI is not one trick — not a single ‘giant model’ or a single training recipe — but a composite control architecture.”

The honest answer is that we do not yet know where convergence stops. The surface will converge. The infrastructure has already chosen sides. And the practical question — which model fits which workflow — is going to outlive the snapshot regardless.

Matching Intelligence Architecture to the Shape of Your Work

In the meantime, the distinction matters enough to act on.

You already do this with your engineering team. You do not assign every problem to your strongest individual contributor. You match the shape of the work — sustained architecture review goes to the senior who can hold ten variables in their head; quick parallelizable bug fixes go to whoever has bandwidth. You have just not formalized it for your AI stack.

A four-dimension profile is enough to start:

The mapping is not subtle. Short, cross-modal, fast-turnaround work routes to centralized intelligence — the coordination overhead of orchestration is dead weight on tasks that finish in seconds. Deep, broad-context, sustained work routes to orchestrated intelligence — internal routing alone cannot hold the trajectory across a half-day refactor. Diverse portfolios route to hybrid: a coordination layer that profiles each request and sends it to the right architecture, with monitoring on cost, quality, and completion time per model per workflow.

McKinsey’s CIO/CTO guide reinforces the operational point. Enterprise generative AI should be operated as a platform, not a series of isolated pilots. A centralized cross-functional team defines protocols, hosts the model hub, enforces governance — but provisions multiple approved models for product teams based on workflow fit. The architecture insight and the org-design insight collapse into the same recommendation: one platform team, many routed models.

The scope matters here: this analysis sits within the frontier tier. The open-source / self-hosted lane — Kimi, GLM, DeepSeek, with 5 of the top 10 intelligence-index models now open weight, per DiscreteStack — is a third axis worth its own piece. Within the frontier tier, the centralized-vs-orchestrated lens is the more useful frame.

By 2028, IDC expects 70% of top AI enterprises to be running multi-tool architectures [1]. Most are still standardized on one model. The window to get ahead of this is now, while the routing layer is still being defined company by company rather than imposed by the next platform shift.

Putting the Distinction to Work

Four things to do this week:

  1. Stop asking “which model is best.” Start asking “what shape of work does this model’s architecture optimize for?”
  2. Assess your top 10 AI-assisted workflows against the four-dimension profile — duration, context scope, modality mix, error cost.
  3. Build a routing policy. Make it a governed systems decision, not a developer preference that survives by inertia.
  4. Measure cost, quality, and completion time per model per workflow. Treat your routing rules as testable hypotheses, not permanent truths.

They are not just different in quality. They are different in how they organize intelligence. And that is becoming one of the most important things to understand.

The benchmark tells you how smart the model is. It does not tell you how that intelligence is organized — or whether that organization matches your work.

References

AI modelssystem-design
About the author
Héctor Reinoso writes about how organizations should be designed when intelligence becomes abundant. He works on enterprise AI adoption inside a large industrial organization, after 25 years as a strategy consultant and transformation executive across four continents. Harvard MBA, industrial engineer, and still writes the code he writes about. More →
Continue reading
Architecture · Sep 13, 2026

The Smooth Frontier

The jagged frontier that defined AI capability in 2023 was not an intelligence problem.
Architecture · Sep 2, 2026

AI Does Not Think Like Software

Language models are probabilistic systems being deployed where deterministic logic belongs.
Models · Aug 30, 2026

A Reasoning Model Is a Simulator of Thought

Modern reasoning models simulate what reasoning looks like well enough to produce real reasoning behavior — but without the guarantees of formal reasoning.
Models · Aug 27, 2026

Why the Best Model Depends on the Shape of the Work

Model selection still happens as if intelligence were one-dimensional: find the strongest score on a leaderboard, deploy it everywhere, optimize later.
Architecture · Aug 22, 2026

Want Some Python With Your Burrito?

Companies are stuffing general-purpose intelligence into single-purpose systems and calling it innovation.
Architecture · Oct 1, 2026

From Writing Code to Managing Agents

Coding agents let developers work with larger units than individual lines. The skill is knowing how to delegate, check, and investigate.