- Microsoft is organised around governance primitives. The open stack is organised around developer flexibility.
- Governance compounds across engagements. Flexibility decays as the estate grows.
- Pick by which constraint binds you, not by which stack is more capable.
The Microsoft-versus-open-stack argument usually gets fought on flexibility, and the open stack wins that fight easily. It is the wrong fight. If you are deploying agents with real authority inside a real business, the binding constraint is governance, and the two stacks are organised around opposite primitives.
Two stacks, two organising principles
Look at what each stack makes easy. Microsoft makes it easy to give an agent an identity, scope its permissions against your existing directory, log what it did, and apply the same compliance controls you already run. Those are governance primitives, and they are present before you build anything.
The open stack makes it easy to swap models, rewrite orchestration, and reach any API you like. Those are flexibility primitives, and they are extraordinary for building. Governance in that world is something you assemble.
Neither is a deficiency. They are different bets about what will be scarce.
Why governance compounds and flexibility decays
Governance built once gets reused. The second agent inherits the identity model, the audit trail and the approval pattern from the first. By the tenth, governance is infrastructure and the marginal cost of a new agent is small.
Flexibility runs the other way. Every bespoke choice is an asset at build time and a liability at maintenance time. Ten agents built ten ways means ten upgrade paths, ten audit stories and ten sets of tribal knowledge. The estate gets harder to change precisely as it gets more valuable.
That asymmetry is the whole argument. Constrained agency needs the thing that compounds.
Microsoft is organized around governance primitives; the open stack around developer flexibility. Governance compounds. Flexibility decays.
Where the open stack still wins
Two cases hold up. If your agent work is genuinely novel research where model swapping is the point, flexibility is the binding constraint and you should optimise for it. And if you have a platform team whose job is to own the governance layer as a product, you can build what Microsoft ships and tune it further.
Most mid-market operators are in neither case. The honest test: do you have a team whose full-time job is owning agent governance? If not, buy the primitives.
What to do next
- 01Name your binding constraint before you pick a stack. Governance and flexibility pull in opposite directions.
- 02Count the people who would own an assembled governance layer. If the number is zero, the decision is made.
- 03Whichever stack you choose, standardise identity, audit and approval patterns once and reuse them.