Microsoft Agent Framework is the direct successor to AutoGen and Semantic Kernel. The same teams built it, and it has reached a production 1.0 release for .NET and Python, with stable APIs and a commitment to long-term support. AutoGen is now archived, Microsoft no longer ships bug fixes or security fixes for it, and it recommends Agent Framework for new projects. Choosing between Microsoft Agent Framework, LangGraph, CrewAI and the OpenAI Agents SDK depends less on feature lists than on three things: the shape of your control flow, how many agents really need to coordinate, and how much orchestration you are willing to own yourself.

Microsoft Agent Framework as the successor to AutoGen and Semantic Kernel

The framework combines AutoGen’s simple agent abstractions with Semantic Kernel’s enterprise features (session-based state management, type safety, middleware and telemetry) and adds graph-based workflows for explicit multi-agent orchestration. Microsoft’s documentation groups it into four areas. Agents use LLMs, tools and MCP servers. A batteries-included Harness Agent handles long multi-step tasks. Workflows connect agents and functions through explicit execution paths. Integrations cover model providers, tools, middleware and evaluation services.

There are two orchestration modes. Agent orchestration is LLM-driven and open-ended. Workflow orchestration is driven by business logic and is deterministic. That split matters because, as LangChain puts it, most agentic systems in production combine workflows and agents. The 1.0 release lists the following as stable: the core agent abstraction; connectors for Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini and Ollama; and the sequential, concurrent, handoff, group chat and Magentic-One orchestration patterns, all with checkpointing, human-in-the-loop approval and pause/resume. MCP support lets agents discover and call external tools. When 1.0 was announced, full A2A 1.0 support was still listed as coming soon.

The n-ix comparison, citing InfoQ, reports that AutoGen moved into maintenance mode in October 2025 and Agent Framework 1.0 reached general availability in April 2026. The sources do not fully agree on AutoGen’s status. Microsoft’s launch post said Semantic Kernel and AutoGen would remain supported, with most investment moving to the new framework, and one comparison article even reports an AutoGen 1.0 GA in February 2026. We give the AutoGen repository’s own archive notice the most weight, because it is the primary source and it says plainly that no fixes are coming.

Microsoft provides migration assistants that analyse existing Semantic Kernel or AutoGen code and generate step-by-step plans, and it says most single-agent AutoGen migrations need only light refactoring. The Agent Spec paper reaches a different conclusion: AutoGen workflows are tied to AutoGen’s architecture, so moving them to another framework typically entails substantial rewriting. Both can be true at once. Microsoft’s claim covers single-agent moves within its own lineage, while the Agent Spec paper speaks of moves to another framework.

How the frameworks differ once they run in production

Read the table as a description of design intent, not a ranking.

Framework	Control model	State and recovery	Tracing	Typical fit
Microsoft Agent Framework	Graph-based workflows plus LLM-driven agent orchestration	Checkpointing, pause/resume	OpenTelemetry GenAI	Multi-provider systems that need enterprise connectors and open protocols.
LangGraph	Stateful directed graphs with explicit control flow	Checkpointers, node-level interrupts	LangSmith	Deterministic execution and auditability.
CrewAI	Role-based agents with goals and backstories, run sequentially or hierarchically	Crew memory	OpenTelemetry export, own dashboard in the enterprise tier	Work that splits naturally into specialist roles.
OpenAI Agents SDK	Minimal abstractions built on agents, handoffs and guardrails; no built-in parallel execution	Simple function-based state	Built-in tracing and visualisation	Single agents with one or two tools on OpenAI models.

One finding cuts across the table. One comparison frames the LangGraph–CrewAI trade-off as predictability against delivery speed, and another rates LangGraph’s learning curve the steepest. If you are comparing finished agent products rather than frameworks to build on, our practitioner’s guide to what each AI agent does well covers that separately.

What the benchmarks say about latency and token spend

The largest public benchmark in the dossier, from AIMultiple, ran LangChain, LangGraph, AutoGen and CrewAI through 2,000 runs: five tasks, 100 runs per framework per task. All four used the same model (openai/gpt-5.2) at temperature 0.1, with identical tools and prompts, each set up in its native structure. Microsoft Agent Framework was not one of the four.

The per-task figures are more useful than the summary, which contradicts itself. It names LangGraph the fastest framework, then says AutoGen leads on latency. The per-task results show:

• Framework overhead on trivial work. Asked to make a single tool call, CrewAI used nearly three times LangChain’s tokens and took almost three times as long. The authors call this overhead structural: it shows up whatever the task complexity.
• Parallel against sequential tool calls. On a four-tool, multi-step analysis task, AutoGen’s median was 47 seconds against LangChain’s 86 seconds, which the authors attribute to parallel versus sequential tool execution. That gap is 39 seconds, or about 45% off LangChain’s time (39 ÷ 86).
• State that never forgets. On the same task, LangGraph’s accumulated state made completed steps look pending. Runs ranged from 6 to 16 tool calls, and latency ended up 23 seconds above AutoGen at a comparable token count.
• Variance. CrewAI produced the highest variance in the whole benchmark. Some runs were clean 5-call sequences, and one run took 35 tool calls.

Two other measurements also report latency and token gaps between frameworks. The Agent Spec paper ran one specification across AutoGen, CrewAI, LangGraph and WayFlow on three benchmarks. On its ReAct test, CrewAI had the highest F1 score but responded between 55% and 140% slower, depending on the model. AutoGen did better on complex reasoning in τ2-Bench, again with higher latency. One repository ran the same “Company Research Agent” workflow through five multi-agent frameworks. All of them scored 9.0 or higher with an LLM judge, and the gaps showed up in speed (6x) and token efficiency (4x). We give that repository less weight than the two studies above.

On the unstructured-data task, AIMultiple ties efficiency directly to each framework’s inner loop: parallel tool calls, accumulating state, self-questioning monologue or linear execution. We would rerun a representative task from our own workload before treating any of these gaps as a property of the framework.

Token multipliers outweigh framework overhead

In Anthropic’s account of its multi-agent research system, agents typically used about 4x the tokens of chat interactions, and multi-agent systems about 15x. Anthropic’s later guidance puts multi-agent implementations at 3 to 10 times the tokens of single-agent approaches for the same task, because of duplicated context, coordination messages and handoff summaries. One comparison estimates that a crew of four CrewAI agents uses 3 to 5 times the tokens of a single agent working through the task sequentially. Both CrewAI core and LangGraph are MIT-licensed, so self-hosted, the direct cost is the model API bill. Our reading of these figures is that a single agent on an efficient framework usually costs less than a multi-agent design on any framework.

How do multi-agent orchestration patterns affect the framework decision when a single use case requires several coordinating agents?

Settle whether you need several agents, and in which pattern, before you compare frameworks. Then pick the framework that models that pattern natively. Anthropic names three situations where multiple agents consistently beat one: context pollution degrades performance, tasks can run in parallel, or specialisation improves tool selection. Outside those situations, coordination costs usually exceed the benefit. Its advice on decomposition is to divide work by the context it needs, not by the kind of work. Sequential phases of the same feature, tightly coupled components and work that shares state should stay in one agent.

Once the pattern is fixed, match it to a framework that models it:

• Handoffs between specialists. The OpenAI Agents SDK handles handoffs well but has no built-in parallel execution.
• Role-based teams. CrewAI runs sequential and hierarchical flows out of the box, but complex branching needs workarounds.
• Graph-shaped coordination with branches and loops. LangGraph can model each agent as a node or group with its own logic, memory and role.
• A mix of patterns in one system. Microsoft Agent Framework 1.0 ships sequential, concurrent, handoff, group chat and Magentic-One orchestration as stable patterns.
• Independent subtasks. On the AIMultiple benchmark’s four-tool analysis task, running independent steps in parallel (AutoGen) finished far faster than running them sequentially (LangChain).

One option is mixing frameworks, for example LangGraph for routing with CrewAI crews embedded as nodes. One comparison notes that some teams do this, but that the integration overhead is rarely worth it unless the use cases are clearly distinct.

Multi-agent designs also have failure modes of their own. The MAST study derived 14 failure modes in three categories (system design issues, inter-agent misalignment and task verification) from 150 traces, then annotated over 1,600 traces across seven popular frameworks. The authors note that multi-agent systems often show minimal gains on popular benchmarks. Anthropic reports that small changes to a lead agent can change subagent behaviour unpredictably. No framework removes these problems, so whichever one you choose has to make inter-agent messages and verification steps visible.

How do open-source frameworks compare with managed options like Google ADK on observability and error recovery?

Google’s stack is the hybrid case: a managed, enterprise-grade runtime (Agent Engine) and a central governance plane combined with the open-source, model-agnostic Agent Development Kit, aiming at enterprise security and observability while staying interoperable through A2A. The same paper notes that the hybrid approach can be more complex than a fully integrated platform.

On the open-source side, OpenTelemetry and OpenInference provide shared standards for agent traces. OpenTelemetry’s GenAI conventions define operations such as invoke_agent, invoke_workflow, execute_tool and plan. Auto-instrumentors for LangGraph, AutoGen, CrewAI, Agno and the OpenAI Agents SDK set the OpenInference trace attributes without extra work. Microsoft Agent Framework turns instrumentation on by default and leaves sensitive-data capture off, but it installs no exporter, so you still have to wire one up. It also propagates trace context to MCP servers, so one trace can follow a call across the agent-to-tool boundary. Agent observability records what happened during a run. Evaluations apply defined criteria to that record to judge whether the run was acceptable. How to monitor live agents over time, and which platform to run it on, is a separate problem, covered in our guide to choosing an MLOps platform for agentic and generative workloads.

LangGraph’s checkpointing persists state between sessions, while AutoGen handles memory manually and has no built-in persistence layer. Microsoft Agent Framework’s checkpointing and hydration cover the same need. Anthropic describes why this matters: restarting a long-running agent from the beginning is expensive, so it built systems that resume from where the error occurred, combined with retry logic and regular checkpoints. Retries are not automatically safe, though. In the AIMultiple benchmark, CrewAI’s “Failed to parse” loop pushed the model to revise a parameter it had originally got right, which produced a wrong churn rate. A framework’s retry behaviour is part of its correctness, not only its resilience.

Lock-in is the cost that never shows on the invoice

Agent frameworks differ in their abstractions, data-flow semantics and tool integrations, which makes workflows hard to share or move between them. One governance paper frames the strategic choice as three archetypes. OpenAI’s AgentKit is an integrated platform that trades potential ecosystem lock-in for developer speed. Microsoft Agent Framework is an open ecosystem built on standards such as A2A and MCP, at the cost of greater inherent complexity. Google’s stack is a hybrid of the two. In our reading, open protocols reduce lock-in only at the integration boundary. They do nothing for the orchestration code written against a framework’s own classes, and that code is what gets rewritten in a migration.

We treat framework lock-in as a portability problem. Portability work is most valuable when scoped against a measurable trigger, such as a deployment-target constraint or a lock-in cost. AutoGen’s archive notice gives its users exactly that kind of trigger. Teams deploying agents onto constrained hardware face a different set of limits, covered in our piece on agent framework selection for edge-constrained inference targets.

When building your own orchestration layer beats adopting a framework

Anthropic makes the case for building with simple, composable patterns over frameworks. Frameworks simplify LLM calls, tool parsing and chaining, but they add abstraction layers that hide the underlying prompts and responses, make debugging harder and invite complexity a simpler setup would not need. Its advice is to start with LLM APIs directly. If you do use a framework, understand the code underneath it, and reduce abstraction layers as you move to production. LangChain, itself a framework vendor, partly agrees. If you do not need persistence, human-in-the-loop or LLM-specific observability, or you want to build them yourself, you may not need a framework, although human-on-the-loop and observability are the harder parts to build from scratch.

Practitioner accounts point the same way. HumanLayer describes teams that reach a 70-80% quality bar on a framework and then find that going further means reverse-engineering the framework’s prompts and flow. Its argument is that adding small, modular agent concepts to an existing product beats a greenfield rewrite. Octomind removed LangChain once its agents needed sub-agents and tool availability that changed with business logic, because the framework offered no way to observe an agent’s state from outside. The 12-factor agent design principles apply “configuration over code” to agents.

Our reading is that the decision turns on which hard parts you would otherwise rebuild. Build a thin layer when the system is mostly deterministic code with a few LLM steps, when you need exact control over each step’s context, or when hard budgets must be enforced outside the model. A token limit or latency budget cannot be requested politely from an agent. It has to be terminated or rerouted deterministically. Adopt a framework when you need durable execution, interrupt-and-resume approvals and several orchestration patterns, because reimplementing those well costs more than understanding someone else’s version.

Who can help us choose the framework, or build the orchestration layer?

TechnoLynx builds agentic AI systems into products for teams facing this decision. That covers checking whether the use case needs multiple agents or a framework at all, matching the framework to the control flow, and then building or hardening the orchestration, state handling and tracing around it.

This kind of agentic AI engagement does not suit everyone. A team with a single OpenAI-native agent calling one or two tools may be well served by the vendor SDK and its own engineers. Teams that want managed deployment and tracing without running them can buy the paid hosted layers, such as LangGraph Platform or CrewAI Enterprise. If what you need is a no-code agent product, not an engineered system, a consultancy is the wrong purchase.

Which production-readiness criteria separate a demo framework from a real one?

A framework is ready for production when it handles the failure cases, not just the happy path. Before committing, check the following:

1. Durable state. The framework can checkpoint and resume a run mid-flight, not only restart it.
2. Approval at any step. Execution can pause at an arbitrary node for human approval, with state modified and then resumed.
3. Inspectable context. You can see and control exactly what reaches the model at each step, which LangChain itself calls the hard part of building reliable agents.
4. Standard telemetry. Spans follow the OpenTelemetry GenAI conventions, and capture of prompts and tool arguments is kept to development and testing.
5. Externally enforced budgets. Token, cost and latency limits are enforced by deterministic checks outside the model.
6. Maintenance status. APIs are stable and the project is actively maintained, which AutoGen is no longer.
7. Safe deploys of in-flight agents. Updates can roll out without breaking agents mid-run, as Anthropic’s rainbow deployments do by running old and new versions side by side.
8. Parallel tool execution. Independent steps run concurrently where the workload allows it.
9. An exit path. You know what a move to another framework would cost to rewrite.

A decision guide by situation

Your situation	Lean towards	Reason
New multi-agent system on a Microsoft stack, in .NET or Python, with enterprise connectors	Microsoft Agent Framework 1.0	Stable orchestration patterns and connectors for Microsoft and third-party services.
Existing AutoGen code in production	Migrate to Microsoft Agent Framework	AutoGen is archived; Microsoft supplies migration assistants, but multi-agent code needs real rework.
Branching workflow with retries, approvals and audit needs	LangGraph	Explicit state graph with checkpointing and human-in-the-loop primitives.
Work divides into specialist roles and speed to first version matters	CrewAI	Suits specialist roles and quick prototyping, at a measured token and latency overhead on simple tasks.
One agent, one or two tools, OpenAI models	OpenAI Agents SDK	Tool use, memory and tracing without the framework abstraction tax.
Managed runtime and governance plane in Google’s Gemini Enterprise stack	Google ADK with Agent Engine	Managed runtime with an open-source SDK.
Mostly deterministic product code with a few LLM steps	A thin layer you own	Fewer abstraction layers to debug in production.

Whatever you pick, the cheapest insurance against the next archived dependency is to keep prompts, tool definitions and state schemas in plain code and data that you own, not inside framework classes. The Agent Spec authors propose a framework-independent declarative format for agents. They describe their declarative format as doing for agents what ONNX does for ML models, and they have run the same specification on LangGraph, CrewAI, AutoGen and WayFlow. Whether it, or the A2A and MCP protocols, ends up making framework choice cheap to reverse is the open question for anyone committing to a stack now.