The 12 Best AI Agent Orchestration Frameworks for Developers (2026)

Code-first frameworks compared on what breaks in production: what happens when your agent has to wait.

We built the same three-step approval workflow in nine of these, killed the process while it was waiting for a human, and recorded what came back. Every framework held its state. Not one of them woke back up on its own.

The differences underneath that result are where teams get hurt.

What is AI agent orchestration?

Orchestration is the layer that decides what runs next, holds state between steps, and survives the gap between them. It differs from workflow automation in one way: automation assumes the path is known up front, orchestration assumes it's decided in motion.

The word currently means five different things, which is why searching for it is miserable. It gets used for conversational routing (which agent handles this customer turn), agent frameworks (the SDKs below), no-code automation (n8n, Zapier), durable execution engines (Temporal, Restate), and parallel coding-agent runners (Claude Squad, Vibe Kanban). Five different products for five different problems.

This piece covers code-first agent frameworks, plus a short section on the runtime layer they hand off to. No-code tools, data pipeline orchestrators, and coding-agent runners are out of scope.

How we evaluated

One axis: how much orchestration you get out of the box, as a framework. Four components.

1. Is suspend/resume a first-class primitive or an escape hatch?
2. Is human-in-the-loop ergonomic or hand-rolled?
3. Does paused state survive a restart?
4. Does anything wake it back up?

Every framework on this list fails number four. That's a category boundary, and it's the setup for the runtime section at the end.

The test. An expense approval workflow: act on a request, suspend waiting for sign-off, complete on approval. Built in each framework the way its own documentation says to, then the process is hard-killed mid-wait and a fresh one tries to recover. We measured whether the state survived, whether a new process could find the waiting workflow without already knowing its ID, whether completed work re-executed, and whether anything resumed unprompted.

Model calls are stubbed. This is an infrastructure test, so stubbing removes model variability from a question about state persistence, and it means anyone can reproduce the results for free. Code, raw results, and pinned versions: github.com/agentmail-to/agent-suspend-test.

Nine tools tested. The other three entries are documentation-based and labelled as such.

At a glance

¹ Via listWorkflowRuns() filtered on suspended. listActiveWorkflowRuns() returns nothing for suspended runs. ² We verified session persistence, not a full suspended invocation. See the entry. ³ list_sessions(app_name, user_id), so you must already know the app and user.

1. Mastra: best orchestration out of the box

What it is: a TypeScript framework bundling agents, graph workflows, memory, RAG, evals, tracing and a local studio into one system, from the team behind Gatsby.

Who it's for: TypeScript teams who want to go from prototype to deployed product without assembling five libraries.

How it pauses: suspend() inside a step, resume() from anywhere later. It's a primitive rather than an escape hatch. The step declares a suspendSchema and a resumeSchema, so the pause is typed at both ends. Network-level approvals arrived in January 2026 with approveNetworkToolCall() and declineNetworkToolCall().

What happened on restart: state survived cleanly in LibSQL, resumed correctly, and step one did not re-execute. Discoverability exists but hides. listWorkflowRuns() surfaces the suspended run with status: 'suspended', while the more obvious listActiveWorkflowRuns() returns nothing at all. Build a recovery sweeper on the obvious method and it will silently find nothing.

Limitations: it saves your state, it doesn't supervise it. Nothing detects failure or wakes the workflow for you. Two API drifts cost us time before any original code: LibSQLStore now requires an id that most docs examples omit (Error: LibSQLStore: id must be provided and cannot be empty), and createRunAsync() is createRun() as of core 1.57. The framework moves faster than its documentation. And it's TypeScript only, deliberately.

Pricing: Apache 2.0. Mastra Cloud has a free tier, $250/team/month for Teams, custom enterprise. SOC 2 Type II since October 2025.

2. LangGraph: most production-proven

What it is: LangChain's low-level orchestration runtime. Your agent is a graph with checkpointed state.

Who it's for: Python teams whose workflow is genuinely a state machine, and anyone who wants the deepest production track record in the category.

How it pauses: interrupt() plus a checkpointer. It waits indefinitely; there's no wall clock on an interrupt. Resume with Command(resume=value) on the same thread ID.

What happened on restart: survived, resumed, no re-execution. Best discoverability of anything we tested that isn't a server. checkpointer.list(None) enumerates waiting threads, so building a sweeper for stuck approvals is straightforward.

One correction. It is widely repeated that durability="exit" cannot recover from a crash. We tested all three modes (sync, async, exit) and all three survived the kill and resumed identically. The warning holds for a crash inside a node, but interrupt() ends the invocation, which triggers the exit checkpoint. If you're using interrupts for human-in-the-loop, the default isn't the footgun it's described as.

Limitations: the learning curve is real. State schemas, nodes, conditional edges: a simple tool-calling agent takes noticeably more code than anywhere else here. Large state objects bloat checkpoints. And the managed platform doesn't run on Vercel or Cloudflare Workers by design, which matters if you're serverless.

Pricing: MIT. LangSmith from $39/seat/month; deployment priced per node executed.

3. Pydantic AI: best architecture

What it is: an agent framework from the Pydantic team, built on the premise that the framework should stay thin and durability should be someone else's job.

Who it's for: Python teams who want typed agents and want to choose their own durability story.

How it pauses: the cleanest API of the twelve. A tool raises ApprovalRequired, the run returns DeferredToolRequests instead of text, and you resume by passing DeferredToolResults with ToolApproved(). Nothing else to configure.

What happened on restart: the state survived only because we serialised the message history ourselves, 1,170 bytes to a file we named. There is no registry of pending approvals, so a fresh process finds waiting work only if you built the index. That's the design, not an oversight.

Why it's ranked here anyway: it's the existence proof for the architecture the rest of the category is converging on. Four durable backends (Temporal, DBOS, Prefect, Restate) co-maintained with each vendor and built only on the public interface. Wrap an agent in DBOSAgent and run() becomes a Postgres-checkpointed workflow. Thin framework plus swappable runtime beats a framework shipping its own half-durable checkpointer.

Limitations: velocity as instability. V1 burned through 104 point releases in nine months and the team openly shortened its breaking-change window from six months to three. Bare, it gives you the least machinery here.

Pricing: MIT. Logfire is the commercial layer.

4. Microsoft Agent Framework: best for .NET and Azure

What it is: the GA merger of AutoGen and Semantic Kernel, reaching 1.0 in early April 2026 for both .NET and Python.

How it pauses: RequestPort, which sits in the workflow graph like an executor but halts orchestration and waits for an external response. Pending requests are written into the checkpoint and re-emitted as RequestInfoEvent objects after a restart, one of the few designs that treats "the process died while waiting" as a first-class case rather than an accident.

With the Durable Task extension, agents unload from memory during long waits without losing context, and recovery spans infrastructure updates and crashes.

Limitations: Azure gravity is real, and the base framework without the durable extension has the same checkpoint gap as everyone else. Note that the April 1.0 covers the core framework. Agent Harness and Foundry Hosted Agents only reached GA around August 2026.

Not tested: the durable extension needs Azure or the Durable Task emulator, which we couldn't stand up cleanly. Behaviour above is from Microsoft's documentation.

Pricing: open source; monetised through Azure consumption.

5. Dapr Agents: the one that completes the loop

What it is: an agent framework built directly on Dapr Workflows, GA March 2026, developed in collaboration with NVIDIA.

Why it's here: it's the only framework on this list where the runtime owns the workflow lifecycle. Dapr's docs put it plainly: agents are "backed by Dapr's workflow engine, which persists every agent interaction with LLMs and tools into a durable state store that can recover and continue execution even after the agent restarts." Every await is a checkpoint backed by a durable reminder, so a crash of the process, of Dapr, or of the whole cluster reactivates the workflow automatically.

The catch: you're running Dapr. That's a sidecar, a control plane, and an operational commitment with nothing to do with agents. For teams already on it this is close to free. For everyone else it's the most expensive answer on the page.

Not tested: requires a sidecar we couldn't run in our environment.

6. Google ADK: best language coverage

What it is: Google's code-first framework, GA for Python since May 2026 and Go since June. Python, Java, Go, TypeScript, and a Kotlin beta give it the broadest spread here.

How it pauses: long-running function tools pause the invocation; you opt into resumability with ResumabilityConfig(is_resumable=True).

What we verified: session state persisted in SQLite across a process boundary, and list_sessions(app_name, user_id) enumerates it, as long as you already know the app and user. We did not drive a full invocation to the suspend point and resume it, so treat the resumption behaviour below as documented rather than measured. Two things to know regardless. First, is_resumable defaults to False. Second, the default InMemorySessionService cannot survive a process kill, so whatever you learn about resumption in development doesn't transfer to production until you swap it.

Their own source is refreshingly blunt. ADK's ResumabilityConfig docstring states: "we only guarantee an at-least-once behavior once resumed" and "any temporary / in-memory state will be lost upon resumption." Tool calls must be idempotent. That's more candour than most frameworks put in their marketing, let alone their code.

Friction: getting the database session service running took three undocumented steps. sqlalchemy isn't installed by google-adk[db], LiteLLM needs [extensions], and the service needs an async driver (sqlite+aiosqlite://). Miss that last one and you get ValueError: Failed to create database engine, which never mentions async drivers.

Limitations: the managed path is GCP-only, and Google's platform churn (Vertex AI folded into the Gemini Enterprise Agent Platform) belongs in your risk calculation.

7. Vercel AI SDK: best for agents inside a web product

What it is: the dominant TypeScript AI library, several multiples of LangChain's JS package by downloads.

A correction. Release coverage widely reports that v7 shipped a durable WorkflowAgent. We checked the published package: in ai@7.0.55 there is no WorkflowAgent export. What exists is ToolLoopAgent, whose entire prototype is generate and stream, with no pause, resume, or persistence, plus Experimental_Agent and message-level tool approvals (lastAssistantMessageIsCompleteWithApprovalResponses, and a family of approval errors).

So: tool approvals in a UI message flow, yes. Framework-level suspend and resume, no. Durability comes from the host, not the SDK.

Who it's for: teams whose agent is a feature inside a Next.js app. The UI hooks plus the tool loop are the path of least resistance, and it was the smoothest install we did at 15 packages, 53 MB, zero errors. If the agent is the product and it needs to wait days, you'll be adding a runtime.

Pricing: free; Vercel monetises the surrounding platform.

8. LlamaIndex Workflows: best for retrieval-heavy agents

Event-driven workflow abstraction with checkpointing, strongest when your agent's problem is mostly a document problem. If the hard part is what the agent knows rather than how long it waits, this is the right shape. Not tested; assessment from documentation.

9. OpenAI Agents SDK: thinnest layer, fastest start

What it is: a deliberately minimal Python and TypeScript framework covering agents, handoffs, guardrails, sessions, and tracing.

How it pauses, and a correction we owe them. Our first pass enumerated the module's exports, found only MCP approval types, and concluded there was no suspend primitive. That was wrong, and it's a good argument for testing rather than skimming. Declare a tool with @function_tool(needs_approval=True) and the run interrupts; result.to_state() gives you a RunState; another process rehydrates it with RunState.from_json(agent, ...), calls state.approve(...), and resumes with Runner.run(agent, state). It works, and it survived our kill.

Two sharp edges. to_json() returns a dict, not a string, and from_json() expects a dict too. Assume otherwise and you get TypeError: data must be str, not dict writing, AttributeError: 'str' object has no attribute 'get' reading. Also note Sessions are conversation history, not workflow position. They're a different feature solving a different problem, and conflating them is easy.

The April 2026 update added, in OpenAI's words, "built-in snapshotting and rehydration" so that "losing a sandbox container does not mean losing the run." Read that precisely: it protects against sandbox loss, not arbitrary process death.

Limitations: no registry of pending states, so discoverability is yours to build. Tracing, hosted tools, and the sandbox harness all live on OpenAI's platform.

Pricing: MIT plus API usage.

10. CrewAI: best multi-agent prototyping, with a warning

What it is: role-based multi-agent orchestration. The fastest path from idea to a working crew, with the largest community in the category.

CrewAI has two human-input mechanisms and they behave completely differently. The difference is the reason for the warning in the heading.

Flow.ask() uses ConsoleProvider by default, which reads stdin. On a server with no TTY, it hits EOF, returns None, and the flow continues. Our expense approval completed with Expense EXP-4417 None. Confirmation sent. No approval, no error, no pause. An approval gate that approves itself is worse than no approval gate, because it looks like one in your code review.

The real durable pause is @human_feedback(provider=...) with a provider that raises HumanFeedbackPending. That works correctly: state persisted to SQLite, survived the kill, resumed via Flow.from_pending(id).resume(feedback=...), no re-execution. But it's opt-in, and the default is the dangerous one.

Second finding: resuming costs an LLM call. @human_feedback uses a model to classify the human's free-text reply into your emit routes. Our resume printed ❌ LLM Error: OpenAI API call failed: OPENAI_API_KEY is required before falling through. Your approval path now has a network dependency, a per-approval cost, and a failure mode unrelated to the approval itself.

Third: no discoverability. SQLiteFlowPersistence has no list or enumerate method. Lose the flow ID and the run is unreachable.

Pricing: MIT; cloud from a free tier.

11. Strands Agents: best for AWS-native teams

AWS's model-driven framework: delegate planning to the model rather than encoding it in a graph. Reasonable if you're deep in AWS. Same checkpoint-not-durability gap as the others, and Diagrid published a specific critique of Strands and Microsoft Agent Framework on exactly this point. Not tested; assessment from documentation.

Skip these: AutoGen and AG2

Not ranked, because the honest recommendation is "start somewhere else," and ranking something you're telling people not to use is listicle logic.

AutoGen earned its place in history. Half the multi-agent patterns in every framework above trace back to it. But the name now points at three things. microsoft/autogen is in maintenance mode; the README says so at the top: "AutoGen is now in maintenance mode. It will not receive new features or enhancements and is community managed going forward." Last release was September 2025. Microsoft Agent Framework is the real successor (entry 4). AG2 is the community fork by AutoGen's original creators, active but with roughly 4.3k stars against the original's frozen 58k.

Most competing roundups still list AutoGen as a live recommendation with none of this. It's a useful test of whether a comparison you're reading is current.

What breaks in production

Four failure modes, regardless of which framework you pick.

The wait that never resumes. n8n isn't on this list, but its Wait node is the clearest illustration of the class. It fails in at least five silent ways: EXECUTIONS_TIMEOUT kills the wait; pruning deletes the waiting execution (14-day default, so a 21-day reminder is gone before it fires); in queue mode waiting executions resume on the main instance, so a deploy at the wrong moment orphans them; the resume webhook is never called; and a past-dated "wait until" collapses to zero. It doesn't fail with a red error, it fails by quietly never resuming. Because it never finishes, it never triggers your error handling either.

The approval nobody notices. A workflow can sit waiting on a human for days without anyone finding out, because a suspended run looks identical to a healthy one until someone asks why the customer never heard back. The fixes are unglamorous. A timer at the handoff with a defined expiry action, explicit approval states rather than a boolean, and idempotent signal handlers, because people double-click submit.

Orphaned children. Temporal's ParentClosePolicy defaults to ABANDON. The user cancels, the orchestrator dies, and child agents keep making model calls and burning credits for hours after everyone went home.

The durable wrapper around a non-durable agent. Wrapping a framework's entire native loop inside one activity of a workflow engine bypasses durability completely. Fail at iteration 47 and you restart at iteration 1, because the engine's guarantees stop at the activity boundary.

When you outgrow all of these

Every framework above stops at the same place: state survives, nothing resumes it.

We tested that boundary directly. In Temporal, the same workflow waits on a Signal. We killed the worker entirely, leaving no process running the workflow at all, and the workflow stayed RUNNING on the server, remained discoverable through list_workflows(), and completed the moment a new worker appeared. Nobody had to notice a run was stuck, because nothing was stuck.

That's a category difference. In a framework, the workflow lives in your process. In a durable runtime, the server owns the workflow and your worker is disposable.

The names you'll meet: Temporal (the standard, with Signals and durable timers and zero compute while waiting, which raised $300M at a $5B valuation in February 2026 on exactly this thesis, naming OpenAI, Replit and Lovable as users), Restate (the cleanest primitive in the category, where awakeables are durable promises resolvable over plain HTTP), Trigger.dev (waitpoint tokens hand you a callback URL and the task checkpoints at zero cost), Inngest (step.waitForEvent() with timeouts; watch the billing unit, since every step counts as an execution), and DBOS (durable execution as a library on Postgres, no new infrastructure).

The framing that clarified this for us comes from Diagrid's Yaron Schneider. Diagrid sells managed Dapr and the argument favours their product, so weigh it accordingly: "Checkpointing says: 'I saved your state. You take it from here.' Durable execution says: 'Your agent workflows will run to completion. Period.'" The counterargument is real too. Most agent workflows never need distributed durability, and Temporal's determinism requirements actively fight LLM non-determinism, since replay assumes your code reaches the same decisions each time and models don't cooperate.

Our read: most production agents end up running framework code inside a workflow engine. Pydantic AI's four pluggable backends are that pattern, formalised.

The question nobody's answering

Full disclosure before this section: we build email infrastructure for AI agents. That's why we notice this, and you should weigh it accordingly.

Every tool on this page can pause. We read thirteen competing roundups of this category while researching, and not one of them asks the next question: when the workflow is suspended waiting on a human, how does that human find out, and how do they answer?

Every piece assumes the approver is watching a dashboard. That holds for an internal ops tool. It breaks the moment the person who has to approve is a customer, a vendor, a candidate, or a contractor, anyone without a login to your orchestrator. The pause primitives above are all excellent and all silent. awakeable, waitpoint, interrupt, suspend: none of them notify anyone.

That gap is why "the approval nobody notices" is the most common way these systems fail in practice, and it isn't a framework bug. It's a missing layer, and right now every team builds it themselves out of whatever channel they already have.

How to choose

Start with language, not features. TypeScript narrows to Mastra versus Vercel AI SDK, and that resolves on whether you're building an agent product or adding agent features to a web product. Python opens up: LangGraph if the workflow is a state machine, Pydantic AI if you want it thin, ADK if you're on GCP, Microsoft Agent Framework if you're on .NET.

Then three questions.

How long is your longest wait? Under a minute, any of these is fine. Hours, you want durable state and a recovery sweeper. Days, you want a runtime, and you should plan for it now rather than after the first incident.

Can you find what's waiting? This separates the field more than persistence does. Before you commit, write the query that lists every workflow currently suspended. If you can't write it, you have no way to find a stuck approval before a customer does.

Who approves, and can you reach them? If the approver isn't an employee with a dashboard login, the channel is your problem and no framework here solves it.

Test code, raw results, and pinned versions: github.com/agentmail-to/agent-suspend-test. If we configured your framework wrong, open an issue and we'll rerun it.