Microsoft Agent Framework

The trait that decides this one is that the same shapes exist in both languages. A C# team and a Python team can build against consistent APIs and review each other's designs, which almost nothing else on this board offers, and for a company with both stacks that is worth more than any individual feature.

The pull toward Azure is real but not compulsory: it works with OpenAI directly and with the Copilot software development kit as well as the vendor's own services. Pick it when .NET is in the building. Pick LangGraph when the codebase is Python and you want the framework to stay a framework.

The risk is that consistency is a goal rather than a guarantee. Python and C# share a repository; Go is a separate project with its own documentation, samples and issue tracker, and the main page sends you there twice rather than explaining the relationship. Feature parity across three implementations maintained on three schedules is a promise no framework has kept, and the first divergence lands on whichever team picked the smaller one.

Check parity before committing a language. What it does right: agents can be defined declaratively in a versioned file rather than assembled in code, which makes a configuration reviewable in the same pull request as everything else.

1. Orchestration is offered as named patterns rather than improvisation: sequential, concurrent, handoff, and group collaboration, each with defined control flow. 2. Execution is checkpointed, and a stored state can be revisited and re-run, which turns debugging a nondeterministic system into an experiment you can repeat. 3. Human intervention is a supported step rather than an interruption. 4. Instrumentation follows the OpenTelemetry standard, so traces are portable.

Replay from a prior state is the property research on agent behaviour actually needs, and very few of these frameworks provide it.

Look at how the hosting is advertised: deploying an agent to the vendor's managed infrastructure is described as two additional lines. That sentence is the business model. Give away the framework, make the default deployment target a metered service, and let developer convenience do the selling that a sales team cannot.

The moat is distribution rather than technology, and distribution here means every enterprise already holding a cloud commitment. There is no acquirer because there is no company to buy, and no shutdown risk worth modelling. Position: long, with the observation that adoption is also a gradual commitment to one cloud's billing.

Procurement is the easy part for once. There is nothing to buy, and the organisation behind it is one we already have agreements with, so the questionnaire is a formality rather than a quarter. The consistent surface across our two main languages means a single set of internal patterns and one set of examples, which is where the sixty-engineer saving actually comes from.

It runs unattended, so agents belong to services rather than to individuals. Onboarding is a week for a mid-level engineer, mostly the orchestration vocabulary. Approved. Condition: decide deliberately where agents are hosted before the default decides for us.

MIT, so the code is genuinely mine to fork, and it installs from the ordinary registries rather than a vendor portal. Middleware is the extension point I would use: wrapping requests and responses lets me insert logging and my own policy without patching the loop.

What I cannot do is plug in the tool ecosystem everything else in my setup speaks, since the board records no client for the protocol. The provider list also leans on hosted services rather than the machine on my desk. It is well built and it is built for somebody with a cloud account, not somebody with a rack.