
Agent harnesses are release platforms
Microsoft Foundry advertises 11,000+ models — but the number that ships agents is one control plane over identity, tools, evals, traces, and rollback. Model choice is one release input; the harness is the product.
Microsoft has been marketing Foundry with the numbers you would expect: more than 11,000 models, over 1,400 business-system connections, used across 80,000-plus organizations including 80% of the Fortune 500. Impressive, unverifiable from the outside, and — I'd argue — the least important figure in the announcement. Because tucked among the model counts is the phrase that actually explains why enterprises adopt a platform like this: one control plane spanning agents, tools, knowledge, identity, policy, evaluations, and deployment.
That is the tell. When a platform vendor leads with catalog size and closes with control plane, the control plane is the product. The 11,000 models are the loss-leader.
Model choice is one release input among seven
Here is the mistake I watch enterprise teams make, at length, this year: they spend weeks comparing model scores — this one's 3% better on that benchmark, this one's cheaper per token — as if selecting the model were the hard part of shipping an agent. Then they "win" the model bake-off and discover the actual work hasn't started, because an agent's production behavior barely comes from the model. It comes from everything around it: the grounding (what data it retrieves), the tools (what it can call), the permissions (what it may touch), the orchestration (how steps chain), and the policy (what it must refuse). Swap the best model in the world into an ungrounded, over-permissioned, untraced harness and you get a confident liability. Swap a mid-tier model into a disciplined one and you get something you can ship.
Model choice is one release input. There are at least seven, and the other six are where deployments live or die.
What a real harness has to make true
The reframe that helps: an agent harness is a release platform, and the unit it releases is the whole agent, not the model. Judge any harness — Foundry, a rival, or the one you're accidentally building yourself out of glue scripts — by whether it makes an agent version four things at once.
Testable. A version can be run against an eval suite before it ships, and promotion is gated on passing — the same eval-record discipline any AI artifact needs, enforced by the platform instead of by hope. Observable. Every run leaves a trace you can inspect — which tool it called, what it retrieved, why it decided — because an agent you can't watch is one you can't debug or defend. Promotable. A tested version moves from staging to production as one artifact, config and prompts and tool contracts and model together, not as six manual steps someone forgets. Reversible. When it misbehaves, one action rolls the whole version back — model, prompt, tools, policy — because partial rollbacks are how 2 a.m. incidents become 6 a.m. incidents.
rendering diagram…
Notice what that list is: it is continuous delivery, restated for agents. Testable, observable, promotable, reversible are the exact properties CD gave software a decade ago — and the reason enterprises will pay platform prices is that building those four properties bespoke, per agent, is the unglamorous work nobody scopes and everybody underestimates. That is the same lesson as loops-are-release-artifacts, now at platform scale: the thing that runs without you has to be engineered like software, and a harness is what industrializes that.
The catalog can be a liability
One sharp caveat on the 11,000 models, because a huge catalog is not free. Every additional model is additional change surface — a version that behaves differently, a new failure mode, another thing to re-evaluate. Optionality only helps if routing and evaluation are automated; otherwise "11,000 models" means 11,000 ways for an untested swap to reach production. The catalog is an asset exactly to the degree the harness disciplines it, and a liability to the degree it doesn't. Buy the control plane; treat the catalog as inventory to be governed, not a feature to be celebrated.
At work, the diagnostic I now run first: a team shows me their agent platform and I ask to see a version get promoted — eval gate, trace, one-click rollback. Teams with a real harness demo it in five minutes. Teams that "chose a great model" show me a model dropdown and a deployment process held together with runbooks and courage. The second group hasn't chosen a platform; they've chosen a model and postponed the platform.
Steal this evaluation order: score any agent platform on the four release properties first — can I test, observe, promote, and reverse a full agent version as one artifact — and score the model catalog last, because you can swap models but you cannot swap a missing release process. If the demo is a benchmark chart, ask to watch a rollback instead. What they do next tells you whether you're buying a platform or a catalog.
The model is a component; the harness is the product — buy the thing that makes an agent testable, observable, promotable, and reversible, because that is what actually ships.


