Sneeuberg Insurance's architecture board asked its platform team for a one-page comparison of "the main agent frameworks", with a recommended winner. Sneeuberg Insurance is fictional, and its teams and systems are illustrative. The team started a spreadsheet with five columns: LangGraph, Pydantic AI, Google's Agent Development Kit, the OpenAI Agents SDK and Microsoft Agent Framework. By the third row it was stuck. One product called itself an SDK, another a framework and runtime, a third a framework that deploys to a managed runtime. Comparing them on the same row felt like comparing a gearbox, a car and a taxi service.
The problem was not the products. It was the categories. The words "framework", "SDK", "workflow tool" and "platform" are used loosely, often by the same vendor for different things. Until a team decides what responsibility it wants a component to take, it cannot compare components sensibly.
This article does that in two steps. First it defines four categories by the responsibility each one takes away from you, and the responsibility it leaves behind. Then it records the current status of the five named frameworks, verified against their own documentation on 7 November 2026, and maps them to Sneeuberg's real workloads. There is no overall score.
Four categories, defined by responsibility
A useful test for any agent component is: what does it take off my hands, and what does it leave in them?
A development SDK gives you the agent loop. It handles the model call, tool calling, structured output and usually tracing. You still own the control flow around it, the runtime it runs in, and everything about governance. An SDK is the thinnest layer, and the easiest to replace.
An orchestration framework gives you control-flow abstractions. Graphs, state, checkpoints, interrupts for people, and multi-agent patterns. You still own hosting, identity, authority and operations. A framework shapes how your code is written, so its exit cost is higher than an SDK's.
A workflow tool gives you composition and a runtime. Triggers, connectors, a visual or declarative way to wire steps, and often its own execution engine and user interface. You still own testing, promotion between environments, and the licence terms. Workflow tools let more people build, which is their strength and their governance challenge, as Citizens build, agents execute, experts govern discusses.
An agent platform gives you a managed place to run agents. Deployment, scaling, an identity integration, monitoring and evaluation services, typically as a hosted service from a cloud provider or framework vendor. You still own the agent's design, its authority rules and its business accountability. A platform has the highest exit cost, because operations, data and identity all bind to it.
The boundaries blur in practice. Several products now span two or three categories: a framework that ships an SDK and offers a hosted runtime, for example. Classify by the responsibility you intend the component to take in your design, not by the word on its homepage. Choose the orchestration pattern before the framework covers the step before this one: deciding who should control the next step at all.
Four selection questions
Before naming a product, Sneeuberg's platform team now asks four questions about the workload.
- Use case. Is this a single agent with tools, a multi-step process with pauses, or an open-ended task? The answer decides whether an SDK is enough or orchestration is needed.
- Skills. Which language and runtime does the owning team already operate well? A .NET team running a Python framework it does not understand is a support risk, whatever the framework's merits.
- Runtime. Where will it run: in an existing service, on a container platform, or on a managed agent runtime? This is where the cloud estate matters.
- Governance. What must be traced, where may traces go, who approves actions, and what evidence must survive? Some defaults, such as where traces are sent, matter here.
Five frameworks, checked on 7 November 2026
The following summary uses each project's first-party documentation and repository, checked on 7 November 2026. Version numbers are the latest Python releases on PyPI on that date unless stated. They will be out of date soon, which is the point of dating them.
| LangGraph | Pydantic AI | Google ADK | OpenAI Agents SDK | Microsoft Agent Framework | |
|---|---|---|---|---|---|
| Describes itself as | Orchestration framework and runtime for stateful agents | The Python AI SDK, a typed agent loop | Open-source agent development framework | Lightweight package with very few abstractions | Framework for production agents and multi-agent workflows |
| Licence | MIT | MIT | Apache-2.0 | MIT | MIT |
| Latest checked | 1.2.20 | 2.66.0 | 2.14.0 | 0.24.0 | Python 1.24.0, .NET 1.28.0 |
| Languages | Python checked | Python | Python, TypeScript, Go, Java, Kotlin | Python checked | Python, .NET; Go in public preview |
| Control model | Explicit graph of nodes and edges | Agent loop; typed graphs when needed | Agents plus sequential, loop, parallel and graph workflows | Agents, handoffs, agents as tools | Agents plus graph-based workflows |
| State and durability | Checkpoints, resume, interrupts | Durable execution through external engines | Graph workflows, new in 2.0 | Sessions | Sessions; workflow checkpointing |
| Typing | State schema defined in code | Typed end to end | Language-native | Python types | .NET and Python types |
| Observability | LangSmith observability | OpenTelemetry-native; Logfire | Logging, metrics and traces; built-in evaluation | Built-in tracing; uploads to OpenAI by default | OpenTelemetry integration |
| Managed runtime option | LangSmith deployment | Not part of the SDK | Google's Agent Runtime, Cloud Run, GKE | Not part of the SDK | Foundry hosted agents |
What the check found, framework by framework
LangGraph. The overview positions LangGraph as the runtime beneath LangChain's higher-level agents, and says it does not require LangChain. It is the most explicit about state of the five: checkpoints, resumption after failure and interrupts are first-class. LangSmith is the vendor's platform for tracing, evaluation and deployment across frameworks.
Pydantic AI. The documentation describes "a typed, extensible agent loop with every model a string swap away". Its distinguishing features are type safety end to end, a typed dependency-injection system that also helps with testing, and durable execution delegated to established engines, with the documentation naming Temporal, DBOS and Prefect among nine. Instrumentation is OpenTelemetry-native.
Google ADK. The ADK documentation lists five languages and announces TypeScript 2.0 as generally available. Graph workflows are marked as new in 2.0, alongside template workflow agents. The documentation says ADK "can work with almost any generative AI model" and lists Google's Agent Runtime, Cloud Run, GKE and self-hosted containers as deployment targets.
OpenAI Agents SDK. The documentation calls it "a production-ready upgrade" of OpenAI's earlier Swarm experiment. Its primitives are agents, handoffs and guardrails, with sessions, tracing and sandbox agents as further features. The models page shows non-OpenAI providers through a custom model provider and two beta adapters. One governance detail matters: by default, traces are uploaded to OpenAI's servers. Tracing can be disabled or sent to another processor, and for an insurer handling personal information under POPIA that choice should be made deliberately, before the first claim passes through.
Microsoft Agent Framework. This is the one where status has changed most, so it is recorded exactly.
- Microsoft's overview (updated October 2026) says: "The Agent Framework is the direct successor, created by the same teams" as Semantic Kernel and AutoGen, and that "Agent Framework is the next generation of both Semantic Kernel and AutoGen." It describes combining AutoGen's agent abstractions with Semantic Kernel's enterprise features and adding graph-based workflows.
- The 1.0 announcement, dated 3 April 2026, declared version 1.0 for .NET and Python, with "stable APIs, and a commitment to long-term support". Several features shipped as previews at 1.0, including Foundry hosted agent integration and the agent harness.
- The AutoGen README now states that the project "has been archived and is no longer actively maintained", that Microsoft is not providing bug fixes, security fixes or support, and that new users should start with Agent Framework.
- The Semantic Kernel README states that "Semantic Kernel is now Microsoft Agent Framework". Semantic Kernel packages were still being released on the date checked. A Microsoft blog post from October 2025 committed to supporting Semantic Kernel v1.x for at least a year after Agent Framework became generally available, with critical bugs and security issues addressed, and said most new features would go to Agent Framework.
In short: Microsoft Agent Framework has superseded both projects as Microsoft's agent framework. It is described as a successor that combines their ideas, not a literal merge of the two codebases. Both older repositories still exist. AutoGen is marked as archived and unsupported. Semantic Kernel is in a supported maintenance phase. New Microsoft-centred work should start on Agent Framework, and existing code has published migration guides.
Scenarios, not scores
Sneeuberg replaced the single winner with workload-specific guidance. Each scenario names a first candidate and the reason. A different organisation with different skills would reasonably choose differently.
Household claims triage with a pause for a handler. A multi-step, long-running process that must resume after an approval. First candidate: an orchestration framework with durable checkpoints, such as LangGraph, or Agent Framework workflows if the owning team works in .NET. Why: the pause and the resume are the hard part, and both frameworks make them explicit.
Structured extraction from claim forms in an existing Python service. One agent, typed output, strict validation. First candidate: Pydantic AI. Why: the requirement is a guaranteed output type and testable dependencies, not orchestration. Adding a framework would add surface without adding control.
Broker query assistant in the .NET estate on Azure. A team that already runs .NET services, Azure identity and Azure monitoring. First candidate: Microsoft Agent Framework. Why: skills and runtime fit. Do not start new work on AutoGen, and plan Semantic Kernel migrations using the published guide.
Reinsurance analytics agent for a team on Google Cloud. Sneeuberg's reinsurance analytics team already runs its data platform on Google Cloud. First candidate: Google ADK. Why: the deployment targets and evaluation tooling sit where the team already operates.
Small internal assistant routing between specialist agents. A handful of handoffs, OpenAI models, low risk. First candidate: the OpenAI Agents SDK. Why: few abstractions, quick to build. Condition: configure tracing before any personal information is processed.
Operations team automating report distribution. No model-driven path, many connectors. First candidate: a workflow tool, after a licence review, or plain code. Why: this is automation, not an agent, as Use a workflow until the unknown forces an agent argues.
Notice that the scenarios use three of the four categories, and that the agent platform question is separate. Whether Sneeuberg runs its agents on a managed runtime is decided by its operating model and cloud estate, and part 4 treats it as a build, buy or reuse decision.
Before you choose
| Check | Evidence to collect |
|---|---|
| Which category of responsibility do we need? | One sentence: what it takes off our hands |
| Is the project current, renamed, superseded or archived? | README banner, latest release, migration notices, dated |
| Does it fit the owning team's language and runtime? | Named team and its existing services |
| Where do traces and telemetry go by default? | Documentation reference and the configured setting |
| How does it pause for a person and resume? | A working test of the approval path |
| What is the exit path? | The interface it sits behind and the effort to replace it |
| Which parts are preview? | Feature list marked stable or preview at the version used |
Key points
- Define categories by responsibility: an SDK gives you the loop, a framework gives you control flow, a workflow tool gives you composition and a runtime, a platform gives you a managed place to run.
- Compare products within a category and against a workload, not on a single league table.
- Microsoft Agent Framework is Microsoft's stated successor to Semantic Kernel and AutoGen. AutoGen is marked archived; Semantic Kernel is in a supported maintenance phase (checked on 7 November 2026).
- Defaults are governance decisions. The OpenAI Agents SDK uploads traces to OpenAI unless configured otherwise.
- Record status with dates, because names, versions and support positions in this market change within months.
This is part 3 of Building an Enterprise Agent Platform Without Buying Everything. Previous: LangGraph and MCP solve different problems. Next: Choose the smallest agent stack that can survive production.
How CloudNala can help
CloudNala runs framework selection reviews that start from your workloads, not from a league table. We classify each candidate by the responsibility it takes, verify its current status and defaults against first-party documentation, test the approval and resume path in a short spike, and give your architecture board scenario-by-scenario recommendations with dated evidence and an exit path for each.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Agent Platform Review or write to us at consult@cloudnala.co.za