Microsoft 365 + Foundry is the default for mid-market professional services firms.
For firms under ~500 people, the build-vs-buy debate is over. The contrarian take inside the take: the firms that will most regret it are the ones too big to be well-served by Copilot defaults and too small to build the alternative.
For a professional services firm under 500 people, the agentic stack decision is functionally over. Microsoft 365 with Copilot Studio for agent design, Microsoft AI Foundry for runtime, Entra Agent ID for identity, Purview for compliance, Dynamics 365 (or Business Central, or a Microsoft-aligned PSA) for the operating system. The path of least resistance is also the path of best alignment with the firm’s existing footprint, the deepest integration with the data layer, and the most coherent governance fabric available at this firm size. Firms in this band are picking it not because it is best-of-breed but because it is the only stack that ships agentic delivery at this scale without a platform engineering team the firm doesn’t have.
The contrarian observation embedded in this position: the firms that will most regret the Microsoft default are not the firms picking it. They are the firms in a specific band — roughly 500 to 2,000 people — that are too large to be well-served by the Copilot defaults and too small to build the alternative. This piece names that band, names the trade-off it uniquely faces, and gives the operator move for each scenario.
Two firm bands, two answers.
Under 500 people: Microsoft 365 + Foundry, full stop.
The firm at this size cannot afford a platform engineering team. The firm at this size already runs Microsoft 365. The firm at this size needs the agentic stack to ship in 90 days, not 9 months. Every variable points the same direction. The build-vs-buy debate consumes more partner time than the actual deployment would. End the debate. Default to Microsoft. Reinvest the saved cycles into the operating-model layer (per Piece 03), which is where the actual differentiation lives anyway.
2,000+ people: Microsoft + custom layer, deliberately.
The firm at this size has the engineering depth to extend Microsoft. The right move is not to leave Microsoft; it is to standardize on Microsoft for the substrate (identity, lineage, agent runtime) and build firm-specific layers on top — proprietary methodology agents, specialized industry models, custom telemetry that the standard Copilot stack cannot deliver. Microsoft is the platform; the firm’s engineering builds the differentiation above it.
500–2,000 people: too big for defaults, too small to build.
This is the band where the Microsoft default actively misfits. The firm at this size has enough complexity that Copilot defaults produce friction (specialized practice areas with non-standard workflows, M&A-driven heterogeneous environments, mid-market client demand for customization) but does not have enough engineering depth to extend Microsoft credibly. Picking Microsoft as the default produces a stack that doesn’t quite fit. Picking the open stack produces a stack that doesn’t ship. The right move is the third path: pick Microsoft and explicitly fund a 3–5 person platform engineering team to build the firm-specific layer. Operators in this band who refuse to fund the platform team are choosing one of the two unhappy paths by default.
The strongest argument against this position.
The strongest counter is that defaulting to Microsoft creates strategic dependence on a single vendor whose roadmap may diverge from the firm’s needs. This is right and should be planned for. The honest answer is that the alternative is not freedom but a different kind of dependence — on the firm’s own platform engineering team, which is more expensive, slower-moving, and harder to staff than Microsoft. For most firms in the under-500 band, this is not a real choice; for firms in the 2,000+ band, the dependency on Microsoft is real but bounded by the customizations the firm builds above it. The dependency is the cost of execution speed; treat it as a managed risk, not as a reason to take the longer path.
Three things to do this quarter.
01 · Place your firm in the band. Under 500: default to Microsoft, end the debate. 2,000+: standardize on Microsoft and fund the firm-specific layer. 500–2,000: you have a problem that requires deliberate solving — read on.
02 · For the 500–2,000 band, fund the platform engineering team explicitly. 3–5 senior engineers, named lead, dedicated budget, charter to build the firm-specific layer on top of Microsoft. This is the only credible path through the problem band. Skipping this hire is choosing one of the two unhappy alternatives without admitting it.
03 · Whatever band you are in, redirect the saved cycles to the operating-model layer. The platform decision is not the differentiator. The constraint engineering, governance design, and contracting model migration are. Spend the partner time there.