BotSharp

You will end up here for one honest reason: your platform is a managed runtime and every other framework on this board assumes a different one. Being able to add an agent as a package inside the application you already deploy is the deciding daily trait, because the alternative is standing up a second service, a second deployment pipeline and a second on-call rotation for what should be a library call.

Pick it if that constraint is real for you. Pick Microsoft Agent Framework when you want the same language with a vendor behind the roadmap.

Age is the risk here, not immaturity. A codebase that began as a conversational bot platform carries assumptions about turns, sessions and channels that do not map cleanly onto an agent that plans and calls tools, and retrofitting rarely removes those assumptions, it layers over them. Several planning approaches coexist in the same project, which means behaviour depends on which one you selected and comparing them is your own experiment.

What it does right: conversation state is a first-class abstraction rather than an afterthought, which most newer frameworks discover the hard way.

1. The composition model is a pipeline of decoupled plug-ins, so capabilities are added without editing the core, which is the right shape for a framework meant to live inside somebody else's application. 2. Routing between agents is by declared responsibility rather than by a model's free choice, bounding the space of who can be asked what. 3. Verification is absent; an agent's answer is returned, not checked.

No evaluation is published and the documentation is a generated site. The observation: the plug-in boundary is the most reusable idea here and the least discussed.

A volunteer collective is a real governance model and a poor counterparty. There is no entity to sign a support agreement with, no revenue to fund maintenance, and 3,099 stars accumulated over eight years is steady rather than accelerating interest. The niche it serves is defensible precisely because it is unfashionable, which also caps how many contributors it will ever attract.

There is no acquirer for a community organisation and no pivot available to it. Position: treat it as source you have adopted rather than a product you have bought, and staff accordingly.

The demo is a routed conversation and it is unremarkable. What is remarkable is how little rollout there is: it enters through the same dependency manifest as everything else we ship, so there is no new deployment surface and no new agreement. The spend is inference on a contract we hold. Against that, the bundled administration interface is a separate application to host, secure and patch, and there is no identity story in a library.

Onboarding is two days for anyone already fluent in the platform. Approved with conditions: library only, no hosted console.

The licence is permissive and the whole thing installs as a dependency, so there is no daemon, no account and no vendor in the loop. Tool server integration comes with a visual management surface, which I would normally sneer at, except that discovering a server's schema by trial and error is genuinely worse.

Providers span five vendors including an open model hub, so routing is my decision. The gap is local inference: no runtime is documented for my own hardware, so anything on my box has to impersonate a hosted API. In a permissively licensed codebase that is a patch, not a blocker.