When you are building a system where many agents collaborate to produce software, the orchestration runtime is not a detail - it is the foundation everything else stands on. Choosing it badly means re-platforming later, after you have built dozens of agents against the wrong abstractions. We wrote this decision down as an architecture record because the reasoning matters more than the conclusion.
What we were choosing between
The practical contenders were Semantic Kernel and the newer Microsoft Agent Framework. Both come from Microsoft, both speak .NET fluently, and both can call models and tools. The question was not which is "better" in the abstract, but which is the better long-term bet for a multi-agent platform that needs to run in production for years.
The criteria that decided it
We scored the options against the things that are expensive to get wrong:
- A supported, converging runtime. The Agent Framework is where Microsoft is consolidating its agent investments. Betting on the converging platform reduces the risk of building on something that gets superseded.
- First-class multi-agent orchestration. Our system is inherently many agents handing work to each other. We wanted orchestration primitives - agents, threads, handoffs - as native concepts rather than patterns we hand-roll.
- Standard tool integration via MCP. Tools are how agents touch the real world. Native Model Context Protocol support means the tools we write are reusable across agents and clients instead of bespoke per integration.
- A model abstraction we already use. The framework builds on
Microsoft.Extensions.AI, so the sameIChatClientabstraction carries through. That keeps model choice a configuration decision, not an architectural one.
Why MCP tipped the balance
If there was a single deciding factor, it was tool standardization. In a mesh of agents, the same capability - query a catalog, open a pull request, run a test suite - is needed by many agents. With MCP, we write that tool once and any agent can discover and call it. Without a standard, every agent-to-tool connection becomes a small bespoke integration, and the maintenance cost grows with the square of the system. Standardizing the tool surface is what keeps a large agent system tractable.
Note: An architecture decision record is not about declaring a winner. It is about capturing the trade-off so that, in two years, someone can understand why the choice made sense given what we knew.
What we gave up
No decision is free. The Agent Framework is younger, so some patterns are less worn-in and the community is smaller. We accepted that because the trajectory and the native multi-agent and MCP support outweighed the maturity gap - and because our model abstraction insulates us if we need to adjust later.
Wrapping up
We standardized on the Microsoft Agent Framework because it is the converging runtime, it treats multi-agent orchestration and MCP tools as first-class, and it builds on a model abstraction we already trust. The broader lesson is the one worth keeping: pick foundational technology by the durability of the bet, write down the trade-off, and let abstractions protect you from the parts you cannot predict.
Building an agentic system and weighing the same choices? Talk to our AI engineers.
