By Louiza Boujida
A colleague sent me a LinkedIn post recently that made a claim which would have sounded absurd two years ago: parts of Microsoft Copilot now run on Anthropic’s Claude. I checked. It holds up. Microsoft’s own blog states plainly that it has integrated “the technology behind Claude Cowork into Microsoft 365 Copilot,” and Copilot more broadly has gone multi-model, with Claude selectable in features like Researcher and Copilot Studio. Meanwhile Scout, the always-on agent Microsoft unveiled at Build, is built on OpenClaw, an open-source agent framework that started as one developer’s weekend project in late 2025.
Which raises a question I keep hearing in meeting rooms, in slightly different words each time:
“If Copilot uses the same model as Claude… why does Claude still feel smarter?”
It’s a fair question. And the honest answer, the one rarely discussed, is that we’ve been comparing the wrong thing all along.
Here’s the simplest way I know to explain it. It’s the version I use when someone outside the field asks what I actually do all day.
Two cars can share the exact same engine. One glides. The other rattles your teeth on every pothole. The difference isn’t under the hood. It’s everything around the hood: the transmission, the suspension, the seats, the software that decides when to shift gears.
AI products work the same way. The model (GPT, Claude, Gemini) is the engine. But you never talk to an engine. You talk to a product: an assembly of routing logic, context pipelines, safety filters, formatting layers, and pricing decisions wrapped around that engine. At the core of that assembly sits a layer researchers call the harness: the system that manages the model’s context, tools, state, permissions, and recovery. Hold onto that word; it’s the main character of this story. Two products with identical engines can behave nothing alike.
So when someone asks “which AI is smarter?”, they’re asking “which engine is best?” without ever looking at the car. And for the past two years, nearly the entire public conversation, from the benchmarks to the leaderboards to the launch-day hot takes, has been an engine conversation.
The engine conversation is over. Here’s why.
When you type a prompt into an enterprise AI assistant, your words don’t go straight to the famous model on the label. They go to a butler first.
The butler’s job is economics. Frontier models are expensive: industry analyses put the per-token price gap between the cheapest workable model and the most capable one at up to two orders of magnitude. So the butler looks at your request and makes a judgment call: this looks simple, the intern can handle it; this looks hard, wake up the professor.
This isn’t a conspiracy theory; it’s published research. The RouteLLM framework (Ong et al., 2024) showed that a trained router can send easy queries to a weak, cheap model and reserve the strong one for hard queries, cutting costs by more than half while keeping most of the quality. Every serious AI platform now does some version of this. Microsoft even surfaces a piece of it in the interface: that little model picker offering you a “fast” and a “thinking” tier? That’s the routing trade-off, made visible and handed to you.
But most of the routing stays invisible. The rewrite button in your word processor, the analysis feature in your spreadsheet, the sub-steps of a research agent: each of these may call a different model, at a different size, with a different budget, and no dropdown will ever tell you which.
You thought you were talking to the professor. Often, you were talking to a very well-briefed intern.
Routing is just the doorman. Behind him, an enterprise assistant runs your prompt through a whole assembly line:
Interception and enrichment. Copilot is not a thin gateway to a model. It’s an orchestration engine that intercepts your prompt, queries your organization’s data through Microsoft Graph, and grounds the request in your emails, files, and meetings before the model ever sees it.
Context trimming. Sending a model everything it could possibly need costs money, so products trim aggressively. And even when context makes it through, models don’t read it evenly. The landmark “Lost in the Middle” study (Liu et al., Stanford, TACL 2024) showed that accuracy follows a U-shaped curve: models attend well to the beginning and end of their input and degrade sharply, by 20 to 30 points, on information buried in the middle. Follow-up research on “context rot” found this degradation appears at every input length, in every frontier model tested. More context is not automatically better context; curated context is.
Safety and compliance filters. Enterprise platforms layer their own content filtering on top of the model provider’s, often stricter. The same model that engages freely in one product will decline, hedge, or flatten its answer in another. Not because it got dumber, but because its employer changed.
Output formatting. Finally, the response gets reshaped to fit the product: shortened, templated, stripped of the conversational texture that makes a direct chat feel alive.
Each layer exists for a defensible reason. Each layer also changes what you get. Stack four or five of them and you understand why the same engine can feel like two different vehicles.
If the story ended there, the moral would be simple: wrappers degrade, always go direct. But that’s not what the evidence says, and this is where the article most people write goes off the rails. The harness, that scaffolding around the model, can degrade performance or dramatically improve it. In 2026 this stopped being anecdote and became measurement:
And there’s a business-world proof point, with the caveat that it comes from the vendor. Microsoft claims its multi-model research pipeline, where one model drafts and Claude critiques, scores 13.8% higher on a deep-research benchmark than standalone tools, including those of the labs that built the models. Take the number with vendor-grade salt; the direction is still telling. Orchestrating someone else’s model well can beat the model-maker’s own product.
A methodological note before anyone quotes these numbers out of context: benchmark findings apply to the products, tasks, and configurations tested, not to every model in every setting. That is, in fact, the whole point: results are properties of configurations, which is exactly why leaderboard rankings of bare models tell you so little about the product on your screen.
The harness is not a tax on intelligence. It’s a multiplier, and multipliers work in both directions. A brilliant model with no access to your world can lose to a modest model that knows your calendar, your files, and your last email thread with the client. This is precisely the bet Microsoft is making: it stopped competing on engines years ago and now sells, as one commentator put it, the kitchen, the staff, and the lease.
Here’s where this stops being an interesting technical curiosity and becomes my day job.
When a company approved an AI assistant two years ago, the compliance file had a simple answer to a simple question: which model processes our data? One vendor, one model family, one data-processing agreement. Done.
That answer no longer exists.
Inside a single interface, today’s assistant can route your request to models from different providers, running on different infrastructure, in different legal jurisdictions. Per task, per feature, per capacity spike.
Three concrete examples from the Microsoft ecosystem, all documented in Microsoft’s own admin literature:
Provenance is now dynamic. Microsoft’s own admin documentation treats Anthropic as a sub-processor whose models are excluded from the EU Data Boundary commitment, and independent analyses of that documentation note that inference for these models runs on Anthropic-operated infrastructure on third-party clouds, predominantly in the United States. Microsoft accordingly ships them disabled by default for EU, EFTA, and UK tenants. Enabling them is not a support ticket; it’s an explicit governance decision. And here’s the part worth reading twice: no new contract gets signed. The consent mechanism is an admin toggle. Flip it, and your organization has accepted a new sub-processor, on new infrastructure, in a new jurisdiction, with the data-transfer analysis now your problem. A compliance team that signed off on “Copilot” in 2024 approved a different product than the one shipping today: same name, different data flows.
Even geography is dynamic. A capacity feature called flex routing lets inference leave the EU boundary during peak load, and it’s enabled by default for newly created tenants. The product didn’t change its name. What it does with your data changed underneath you.
Cost is now dynamic too. Agentic features are increasingly priced per usage, on top of the seat license, metered in credits. Seat-based license management, the muscle every IT department has spent a decade building, tells you who has access. It tells you nothing about who is consuming what. A single enthusiastic user running heavy autonomous tasks is a budget line nobody is watching.
Model provenance, data geography, and metered consumption used to be procurement footnotes. They are now live variables that change per request, and all three live in the product layer around the model, not in the model itself. Which means that layer, from the harness up through the vendor’s routing and pricing decisions, is now the primary object of AI governance. If your governance framework has a box that says “approved model: X,” that box is already fiction.
Not a framework. Just three questions I now insist on before any AI product gets a green light, and that I’d suggest you ask too, whether you run governance for a company or just pay for a subscription:
1. Evaluate combinations, not models. Stop asking “is model X better than model Y?” Ask “is this product’s assembly of model + context + constraints better for this task than the alternative’s?” Run your own tasks through the actual product, not the leaderboard.
2. Demand provenance as a feature. Which models can process my data? Where does inference physically run? What changes when the vendor adds a new model or a new routing behavior, and how will I be told? If the vendor can’t answer, the product isn’t enterprise-ready, whatever the logo says.
3. Govern consumption, not just access. Usage-metered AI needs the same treatment cloud spend got a decade ago: visibility, budgets, alerts, and an owner. Before the invoice teaches you the lesson.
Inventory the routing.For each AI product in use, list which models itcancall, per feature, not just the one on the marketing page.
Check your tenant toggles.Sub-processor settings, regional routing settings, and their defaults. Defaults change; yours may have changed with them.
Map the data boundary.Which features can process data outside your committed region, and under which conditions (model choice, capacity peaks)?
Put usage-based AI spend under FinOps.Budgets, alerts, and a named owner. Before the first surprising invoice, not after.
Re-review on vendor change, not on calendar.A new model, a new routing behavior, or a new default is a trigger for re-assessment. The product’s name staying the same means nothing.
The question “which AI is the smartest?” made sense in 2023. It’s the wrong question in 2026. Models are converging; the interesting differences in quality, behavior, risk, and cost have migrated into the layer between you and the model, with the harness at its core. That layer is engineered, opaque, commercially motivated, and changing under your feet.
The model is the ingredient. The product is the recipe, the kitchen, and the bill.
And if there’s one thing worth keeping from all of this, it’s the oldest question anyone has ever asked before trusting an unfamiliar kitchen:
Who’s the cook?
Start asking it about your AI tools. You’ll be surprised how often nobody at the table knows.
The Model Is Not the Product was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.