All glossary terms
A Agent engineering Architecture

Agent frameworks

An agent framework is the library you build an agent with. A framework can only govern agents that import it. That single property explains why framework choice matters less than teams expect, and why it never solves the estate-level problem.

Definition

An agent framework is a code library providing the scaffolding for building AI agents: how steps are defined, how state moves between them, how tools are called, and how control passes from one agent to another. It is something you import into your application rather than a system you deploy into, and that distinction determines what it can and cannot govern.

What is an agent framework?

An agent framework is the library you use to build an agent. It supplies the loop that calls the model, runs tool requests, tracks state, and hands control between agents. What it doesn't supply is any place for that agent to be governed once it's running.

The value is easiest to see by picturing what you'd have to build without one. You'd need to write code that:

  • Calls the AI model
  • Reads whatever tool requests it sends back
  • Runs those tools
  • Feeds the results back to the model
  • Decides whether to keep going or stop
  • Handles it when something goes wrong

Then you'd have to write all this again for your next agent, slightly differently each time.

A framework hands you that entire process, plus ready-made ways to handle everything around it: setting up tools, tracking the agent's state, passing control between agents, and streaming output back to the user. It saves real, repetitive work, but it's only about a third of what an agent needs to run in production.

Import into, or deploy into. This is the distinction to hold onto for the rest of the page. A framework is a dependency inside your process; it sees what your code passes to it and nothing else. A platform is something your agents run inside; it sees every agent regardless of how each one was written. Both are useful, they are not substitutes, and confusing them is the single most common source of disappointment in agent programmes.

What are the main types of agent framework?

Frameworks divide by how they coordinate: graph-based with explicit state, role-based with implicit coordination, handoff-based, hierarchical, and provider SDKs tied to one model vendor. The coordination style matters more than the feature list, because it is the part you cannot change later.

Feature comparisons date within weeks. Coordination style is architectural and durable, so it is the better basis for a decision.

Five coordination styles shown as small diagrams. Graph-based shows nodes connected by conditional edges with explicit state. Role-based shows named roles coordinating implicitly. Handoff-based shows control passing explicitly between two agents. Hierarchical shows a parent agent above child agents in a tree. Provider SDK shows a single agent bound tightly to one model vendor. Each carries a note on what it is best and worst at.
Agent frameworks by coordination style, with named examples and the trade-off each makes, as at August 2026
Framework Coordination style Best at Trade-off
LangGraph Graph: nodes and conditional edges, explicit state Stateful production workflows, durable checkpointing, human-in-the-loop interrupts Steeper learning curve; you model the graph yourself
CrewAI Role-based: named roles coordinating implicitly Getting a multi-agent prototype working quickly Less routing control at scale; lighter checkpointing
Microsoft Graph, in the Microsoft Agent Framework .NET and Azure-native estates; unified AutoGen and Semantic Kernel lineage Strongest inside the Microsoft stack, less outside it
Google ADK Hierarchical agent tree, plus graph workflows in 2.0 Google Cloud and Gemini estates; Python, Go and TypeScript all first-class Newest of the group, so less production history
OpenAI SDK Handoff-based, deliberately minimal Low-friction agents on OpenAI models, with sandboxing and sub-agents Tied to one provider; state is ephemeral by default
Claude SDK Tool-use chain with sub-agents Claude-based agents, native streaming, extended reasoning Tied to one provider
AutoGen Conversational group chat Historically, research on agents conversing In maintenance mode as of 2026; not a choice for new work

Others worth knowing without needing a row: Pydantic AI for type-safe agents, Strands Agents in the AWS ecosystem, LlamaIndex Workflows where retrieval is central, Mastra and the Vercel AI SDK for TypeScript, Agno and Smolagents at the lightweight end. The list is long and getting longer, which is itself an argument for not treating the choice as decisive.

What changed in the framework landscape in 2026?

Three things, and together they invalidate most comparisons written before this year. AutoGen moved to maintenance mode, Microsoft merged AutoGen and Semantic Kernel into one framework that reached general availability, and every major framework converged on MCP as the standard way to connect tools.

The third change is the one with the largest practical consequence, and it gets the least attention.

  • Consolidation. AutoGen is maintenance-only, and Microsoft unified it with Semantic Kernel into the Microsoft Agent Framework, which reached general availability in April 2026. Any comparison recommending AutoGen for new multi-agent work is out of date, and teams running it in production face a decision between a frozen feature set and a migration.
  • Convergence on graphs. Google's ADK reached 2.0 with graph-based workflows alongside its hierarchical model and first-class Python, Go, and TypeScript support. Graph-based coordination with explicit state has become the default shape for production work, largely because it maps onto what regulated environments need: auditability, deterministic control, and defined approval points.
  • MCP became the tool layer. Every major framework adopted the Model Context Protocol for tool integration during 2025 and 2026. Tool integrations written once are now portable across frameworks without rewriting, which materially reduces the cost of choosing wrong. See agent interoperability.

The MCP point deserves emphasis because it changes where the risk sits. Tool integrations used to be the expensive, framework-specific asset, and the fear of rewriting them was the main reason framework choice felt irreversible. That fear is now largely obsolete, and the lock-in has moved somewhere else, which the section on choosing covers.

This section describes the position as at August 2026 and will age faster than anything else on this page. Check the dates on any framework comparison you read, including this one.

What can an agent framework not do?

A framework can only see and constrain agents that import it. Everything about your estate that spans frameworks, teams, or platforms is outside its reach, which means framework-level state, tracing, and guardrails cover the fraction of your agents built with that framework and nothing else.

This is the structural limitation, and it is not a criticism of any framework. A library cannot enforce a policy on code that never called it. The problem is that the limitation is invisible while you have one framework and one team, and becomes the dominant fact as soon as you have two.

A boundary diagram. Inside the framework's reach sit the agent loop, tool calls, state within a run, and framework-level tracing, all for agents that imported the framework. Outside the boundary sit agents built with other frameworks, agents embedded in purchased software, agents on cloud platforms, the estate-wide registry, cross-agent policy, cost attribution, and the audit record. A caption reads that a library cannot enforce a policy on code that never called it.

Read it in terms of what happens on the second framework. A team picks one, builds well, and gets state management, tracing, and some guardrails from the library. A second team picks a different one, for reasons that are usually sensible and stack-driven. At that moment:

  • The inventory splits. Neither framework knows about the other's agents, so nothing can answer how many agents the organization runs. See agent registry.
  • Tracing stops being comparable. Two telemetry schemas means two dashboards and no end-to-end view of a process that crosses both.
  • Guardrails apply unevenly. A policy implemented in one framework's middleware does not exist in the other, so the same rule is enforced for some agents and not others, which is worse than not having it, because it is believed.
  • Cost cannot be attributed consistently. Each framework reports what it can see, and nothing sums them per agent or per owner.

Add agents that arrived inside purchased software and agents created on a cloud platform's own agent builder, neither of which imports any framework, and the coverage gap widens further. This is the reason framework-level governance is a stage rather than a destination, and it is the same argument as agent sprawl arriving from a different direction.

How should you choose an agent framework?

Your existing stack decides more of it than merit does. Beyond that, choose on the state model and the telemetry format, because MCP made tool integrations portable and those two are now the parts you cannot migrate cheaply.

Two honest observations about the selection exercise before the criteria.

  • The stack usually decides. On Azure and .NET you will end up with the Microsoft framework; on Google Cloud with ADK; committed to one model provider, with that provider's SDK. Fighting that generally costs more than it saves, so the genuinely open choice is narrower than the number of options suggests.
  • Reliability does not come from here. Teams switching frameworks to fix an unreliable agent are usually solving the wrong problem. Reliability comes from evaluation, guardrails, context management, and the quality of the underlying data. A framework change moves the code and leaves all four untouched.

With that established, three criteria are worth real scrutiny.

  1. The state model, because it is the actual lock-in

    How does the framework represent and persist state between steps, and can a run be resumed, inspected, or replayed? Durable checkpointing is the difference between an agent that survives a restart mid-task and one that starts again. It is also the hardest thing to migrate, because your state format is not portable in the way your tool integrations now are.

  2. The telemetry format, because it decides your future options

    What does the framework emit, and does it follow standard conventions for generative AI telemetry or its own schema? Proprietary telemetry ties your evaluation and observability choices to that framework long after you have stopped caring about its API. Insist on portable traces. See AgentOps.

  3. How much control it gives you over routing

    Role-based abstractions are faster to start and give you less say in what happens next, which is why teams commonly prototype with one and reimplement in a graph-based framework for production. If your process has compliance-relevant ordering or approval points, choose explicit control from the outset rather than discovering you need it.

Two things are deliberately left out of these criteria: benchmark scores and popularity. Benchmark scores don't matter here because the framework isn't the part that ‘thinks’, the model is. The framework just moves information around. Stars and integrations don't matter either, since they only show how popular a framework is right now, not whether it's the right fit, and that popularity has flipped twice in eighteen months.

What is the difference between a framework, an SDK, and a platform?

A framework is a library you import, an SDK is a provider-specific library, a platform is a system you deploy into, and an orchestrator is a function that lives inside either of them. The distinction that matters commercially is import versus deploy, because it decides what can be governed centrally.

These four terms are used loosely, including by vendors describing their own products, which makes evaluation harder than it needs to be.

Framework compared with SDK, platform, orchestrator, and runtime, by what each is and what it can see
Term What it is What it can see Who owns operations
Framework A library you import into your own application Only agents that imported it Your engineering team, entirely
SDK A library tied to one model or cloud provider Only agents using that provider Your team, with provider defaults
Platform A system your agents run inside Every agent it hosts or discovers Shared with the platform
Orchestrator The component deciding what runs next Whatever it coordinates Depends where it lives
Runtime Where the agent process actually executes Execution, not intent Platform engineering

The practical reading is that most large programmes run both a framework and a platform, and should. A framework gives depth: fine-grained control over how a particular agent behaves. A platform gives breadth: one inventory, one policy set, one audit record across agents somebody else's team wrote in somebody else's framework. Asking which you need is the wrong question, and asking which layer a given capability belongs in is the right one. For the coordination question specifically, see AI orchestration.

Frequently asked questions about agent frameworks

If your question is not here, our team will answer it directly.


Talk to a Specialist →
What is an agent framework?

It saves you from writing the plumbing. Build an agent without one and you write your own loop: call the model, parse the tool requests it returns, execute them, feed the results back, decide whether to continue, and handle failures at every step. A framework provides that loop plus conventions for defining tools, structuring state, handing off between agents, and streaming output. Useful work nobody should repeat, and roughly the first third of what a production agent needs.

Which agent framework should I use?

Your existing stack decides more of this than merit does. On Azure and .NET you will end up with the Microsoft Agent Framework; on Google Cloud with ADK; committed to one model provider, with that provider's SDK. Where the choice is genuinely open, LangGraph is the common default for stateful production work because of explicit state and durable checkpointing, and CrewAI is the fastest route to a working multi-agent prototype. As of 2026, AutoGen is in maintenance mode and not a choice for new work.

What is the difference between LangGraph and CrewAI?

Coordination style and how much control you get. LangGraph models an agent as a directed graph with explicit state, conditional edges, and durable checkpointing, which suits production workflows needing auditability, deterministic routing, and human approval points. CrewAI models agents as named roles that coordinate implicitly, which is considerably faster to start and gives less say in what happens next. The common pattern is prototyping in CrewAI and reimplementing in LangGraph when the workflow outgrows role-based simplicity.

Is AutoGen still maintained?

It moved to maintenance mode in 2026, and Microsoft merged its lineage with Semantic Kernel into the Microsoft Agent Framework, which reached general availability in April 2026. For new work AutoGen is not a candidate. If you have it in production you face a choice between living with a frozen feature set and planning a migration, and the closest architectural fit is generally a graph-based framework, or a role-based one if your agents already follow role patterns.

Do I need an agent framework at all?

For anything beyond a single tool-calling loop, yes, because otherwise you write and maintain that plumbing yourself. For a genuinely simple agent, a direct provider SDK or even a hand-rolled loop can be the better choice, and some teams deliberately keep the loop thin so they own it. The consideration that decides it is usually state: the moment you need a run to survive a restart, be inspected, or be resumed, a framework with durable checkpointing earns its place.

What is the real lock-in with an agent framework?

The state format and the telemetry schema, not the API. Every major framework converged on the Model Context Protocol for tool integration during 2025 and 2026, so tool integrations written once are now portable across frameworks without rewriting. What is not portable is how a framework persists and checkpoints state, and what shape its traces come out in. Choose on those two, insist on standard telemetry conventions, and framework migration becomes an inconvenience rather than a rebuild.

Can an agent framework provide governance?

Only for agents that import it, which is the structural limit. A library cannot enforce a policy on code that never called it. That is invisible while one team uses one framework, and becomes the dominant fact with two: the inventory splits, telemetry stops being comparable, and a guardrail implemented in one framework's middleware simply does not exist in the other. Add agents that arrived inside purchased software or were built on a cloud platform's own agent builder, and framework-level coverage narrows further.

Will switching frameworks make my agent more reliable?

Usually not, and it is a common way to spend three months on the wrong problem. Reliability comes from evaluation, guardrails, context management, and the quality of the underlying data. A framework change moves the code and leaves all four untouched. The exception worth taking seriously is when the framework itself is the constraint, most often because you need explicit routing control or durable state and the abstraction you chose does not offer either.

What is the difference between an agent framework and an agent platform?

Import versus deploy. A framework is a library inside your process; it sees what your code passes to it and nothing else. A platform is a system your agents run inside; it sees every agent it hosts or discovers, regardless of how each was written. So a framework gives depth, meaning fine-grained control over one agent's behaviour, and a platform gives breadth, meaning one inventory, one policy set, and one audit record across the estate. Most large programmes run both, and should.

Does MCP make agent frameworks interchangeable?

It makes the expensive part interchangeable, not the frameworks themselves. Convergence on the Model Context Protocol means a tool integration written once works with any framework that speaks it, which removes what used to be the main reason framework choice felt irreversible. Your agent's control flow, state handling, and telemetry remain framework-specific. The practical effect is that the cost of choosing wrong dropped substantially, which is a reason to decide quickly and start rather than to run a long evaluation.

How many agent frameworks will a large enterprise end up with?

More than one, almost always, and planning for a single standard tends to fail. Different teams sit on different clouds, inherit different provider commitments, and start at different times, so a second framework arrives for reasons that are individually sensible. Treating that as a governance problem rather than a standards problem is the more productive stance: rather than mandating one library, ensure that whatever each team builds lands in one inventory, under one policy set, with portable telemetry.

Are agent frameworks production ready?

The graph-based options are, and maturity varies considerably across the field. Frameworks offering explicit state, durable checkpointing, human-in-the-loop interrupts, and standard telemetry are being used in regulated production environments today. Newer entrants and lighter role-based abstractions are perfectly sound for prototypes and thinner on the operational features production needs. The honest caveat is that the landscape shifted more in the first half of 2026 than in all of 2025, so verify the current state rather than trusting any comparison including this one.

Keep reading

Terms that come up in the same conversation

Browse the full glossary
A

AI orchestration

The coordination question itself, and the three autonomy levels a framework choice quietly commits you to.
A

Agent registry

What holds the agents your second framework knows nothing about.
A

Agent interoperability

Why MCP convergence moved the lock-in, and what the protocols still do not solve.

Depth and breadth
What governs the agents your framework cannot see?

CAMS holds agents in one registry whichever framework built them, auto-discovers agents created on other cloud platforms, and applies one policy set, one promotion path, and one audit record across the estate. Keep the framework your engineers chose. Govern all of it in one place.

Book a demo Explore CAMS