Before you rewrite anything, answer one question: when your agent dies at step 6, does it resume at step 6 or at step 1? If the answer is step 1, you do not have a LangChain problem. You have a durable-state problem, and every framework on your shortlist will fail at it the same way — because none of them is a durable execution engine. Teams rewrite, ship, get paged at 3am for the identical failure, and conclude that frameworks are cursed.
So: add DBOS — a library that checkpoints into the Postgres you already run — or Temporal underneath what you have today. That is a week of work, not a quarter. If the pain persists after that, it was genuinely the abstraction, and then the shortest honest exit is Pydantic AI: typed, thin, and refreshingly unwilling to pretend it owns durability. If you are a product team on one provider with a loop you now understand cold, delete the framework entirely — that is a real answer, not a stunt.
Everything below is normalised to one workload, because each vendor quotes the metric that flatters it: a 9-step back-office agent, 40,000 runs a month, roughly three minutes of wall clock per run, two tool calls that move money, one human approval gate, and a hard requirement that a run interrupted at step 6 resumes at step 6.
| Pydantic AI | LangGraph (stay) | OpenAI Agents SDK | LlamaIndex Workflows | Google ADK | No framework | |
|---|---|---|---|---|---|---|
| Version (17 Aug 2026) | 2.31.0, 15 Aug | 1.2.11, 11 Aug | 0.21.1, 16 Aug | 0.14.23, 24 Jun | 2.7.0, 13 Aug | SDK, 14 Aug |
| Durability story | Delegated: Temporal, DBOS, Prefect, Restate, Airflow | Own checkpointer, super-step boundaries | None built in | Checkpoint context, resume after restart | Graph runtime | Whatever you wire |
| Migration shape from LangChain | Rewrite the loop, keep tools | Idiom change, keep vendor | Rewrite the loop | Rewrite around events | Rewrite + replatform | Delete, then write ~300 lines |
| Observability floor | Logfire free 10M records | LangSmith $0 for 1 seat | Bundled tracing | Bring your own | Cloud Trace | OpenTelemetry |
| Observability at team scale | $49/mo, 5 seats | $39/seat/mo + LCU/LSU | Bring your own | Bring your own | Cloud billing | Bring your own |
| Self-host the tooling | Enterprise only | Enterprise only | n/a | n/a | n/a | Yours already |
| Licence | MIT | MIT | MIT | MIT | Apache 2.0 | n/a |
| Best when | You want types and someone else's durability | State machine is the product | Smallest primitive set | Workload is document-shaped | You live on Vertex | One provider, stable loop |
The Failure Mode You Hit Is Rarely the One You Name
The complaint that shows up in every post-mortem is "too much abstraction." It is real, and the most credible endorsement of it comes from a model vendor with every incentive to say the opposite. Anthropic's own agent-building guidance tells developers to "start by using LLM APIs directly: many patterns can be implemented in a few lines of code," and warns that frameworks "often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug." That is the framework tax stated plainly by a company that sells the thing underneath the framework.
The practitioner record says the same. The canonical LangChain critique — an engineering team explaining why they removed it after more than a year in production — hit 480 points and 297 comments on Hacker News in June 2024, and the recurring theme was not performance. It was that customising a small behaviour meant reading framework source, and that stack traces went through layers of machinery nobody on the team owned.
But look at what those same threads say people replaced it with: direct API calls, an explicit control loop, and a few hundred lines. A different full-fat framework barely appears in that record as an escape route — where one is mentioned at all, it is by someone who started there rather than someone who fled to it. That is the tell. The abstraction complaint is a complaint about ownership, and swapping vendors does not change who owns the loop.
Now separate that from the failure that actually pages you. A 9-step agent that dies at step 6 and restarts at step 1 has re-run two money-moving tool calls. That is not an abstraction problem, it is a state problem, and it is invisible in a prototype because prototypes never crash mid-run at 40,000 runs a month. It is also the failure most likely to be misfiled as "LangChain is bad", because it surfaces at exactly the moment you outgrow the prototype.
Fix Durability First, Because It Costs Less Than a Rewrite
Durable execution means a run survives the death of the process executing it and resumes from its last checkpoint rather than from the beginning. The important part for a buyer: it is a property of your runtime, not of your agent library, so you can add it without touching your framework choice.
DBOS is the cheap version and the one to try first. It is a Python library — 2.29.0 as of 30 July 2026 — that describes itself as "ultra-lightweight durable execution" with "lightweight durable workflows built on top of Postgres," and it states the requirement bluntly: "DBOS is entirely contained in this open-source library, there's no additional infrastructure for you to configure or manage." If you already run Postgres, your marginal infrastructure cost is a schema. You annotate the functions that must survive a crash. That is the whole adoption story.
Temporal is the version you buy when durability is a platform commitment rather than one service's problem. Temporal Cloud starts with $1,000 in credits, then Essentials from $100 a month for 1M Actions and Business from $500 a month for 2.5M Actions, with overage at $50 per million tapering to $25 per million at volume, plus active storage at $0.042 per GB-hour and retained storage at $0.00105 per GB-hour, all as published on 17 August 2026. Our normalised workload — 40,000 runs a month with nine steps and two tool calls — lands in Actions territory that a $100 tier covers with room, so the real cost is the operational one: you now run a Temporal cluster or pay someone to.
The trade is honest and worth stating before you commit. Durable execution imposes determinism. Pydantic AI's Temporal integration docs spell out what that means in practice — model requests, tool calls and MCP communication get "offloaded to Temporal activities due to their I/O requirements," everything crossing that boundary "needs to be serializable," Temporal "limits their size to 2MB by default," and workflow code "generally cannot include any kind of I/O, over the network, disk, etc." If your agent passes around large binary blobs or fat dependency objects, you will restructure them. Find that in a spike, not in your migration.
Pydantic AI Is the Shortest Honest Exit
If you have done the durability work and still want out, Pydantic AI is the recommendation, and the reason is what it refuses to build. Version 2.31.0 shipped 15 August 2026 describing itself as "a typed, extensible agent loop with every model a string swap away," supporting "OpenAI, Anthropic, Google, Bedrock, Azure AI Foundry, Groq, Mistral, xAI, Ollama, and dozens more." Crucially, it ships durability as integrations — Temporal, DBOS, Prefect, Restate and Airflow — rather than as a proprietary checkpointer. You keep the durable engine you already chose, and the agent library adapts to it.
The second reason is types. Your existing LangChain code almost certainly already depends on Pydantic — it is the validation layer underneath most of this ecosystem — so the tool signatures and structured outputs you have written are the part of the migration that mostly survives. What you rewrite is the loop, which is the part you wanted to own anyway.
Be clear about the commercial floor. The framework is MIT. The observability you will actually run is Logfire: a genuinely usable free Personal tier at 10M records a month with 30-day retention, Team at $49 a month for 10M records with $2 per million overage, Growth at $249 a month for up to 90-day retention, and self-hosting on Enterprise only — checked 17 August 2026. Compare that with LangSmith on the same date: $0 for a single Developer seat with 5,000 base traces, $39 per seat per month on Plus for 10,000, metered compute at $1.50 per LCU and storage at $1.00 per LSU, and self-hosting restricted to Enterprise. Both gate self-hosting behind a sales call. Logfire's difference is that a five-person team costs $49 flat rather than $39 each, and its overage is one legible number instead of two synthetic units. If your finance team has ever asked what an LCU is, you already know why that matters — a point we made at length in our Datadog vs Arize vs LangSmith comparison.
The Case for No Framework Is Stronger Than It Sounds
Delete it. For a genuinely large class of teams this is the correct answer, and it has become more correct every quarter because the model vendors absorbed the abstractions that justified a framework in the first place.
Look at what now ships in the box. The OpenAI Agents SDK — 0.21.1 on 16 August 2026 — is explicitly designed with "enough features to be worth using, but few enough primitives to make it quick to learn," offering agents, handoffs, guardrails, sessions and bundled tracing while supporting "100+ other LLMs." The Claude Agent SDK, 0.2.139 on 14 August 2026, ships a tool loop, hooks to intercept behaviour, and custom tools as in-process MCP servers. Tool calling, structured output, retries, streaming and conversation state are provider features now. A framework that wraps them is charging you an abstraction fee for a problem that got solved beneath it.
What you write yourself is a while loop, a tool dispatch dict, a retry policy and a logger. Practitioners in that Hacker News thread put the replacement at a few hundred lines against thousands — treat the exact figure as anecdote, but the order of magnitude matches what teams report consistently. The honest counter-argument is that those few hundred lines are now yours to maintain forever, including every new protocol and every provider quirk. That is a real cost. It is just a smaller and far more legible one than maintaining a fork of someone else's opinions, and it is the same trade we walked through in the build-to-buy spectrum.
No framework is the wrong answer if you are running multi-agent handoffs, swapping providers monthly, or staffing this with engineers who are new to the domain. Those are exactly the cases where someone else's opinions are worth paying for.
Do Not Escape Abstraction by Adding More of It
Here is the loser, and it is a genuinely tempting mistake: do not migrate up the LangChain stack.
On 6 August 2026, LangChain published its own three-layer map — LangGraph as the runtime, which "offers the most control and the least abstraction," LangChain as the framework in the middle, and Deep Agents as the harness, which "offers the inverse." The post concedes the architecture in one line: "Deep Agents is actually just the core LangChain agent plus a bunch of middleware." If your team's stated grievance is that framework abstraction hid the prompts and made debugging archaeology, the fix cannot be the layer above the one that hid them. It is a fine product for a team starting fresh and wanting batteries included. It is precisely wrong for a team that arrived here by fighting abstraction.
The same caution applies to the sideways move. LlamaIndex Workflows is a clean event-driven model — typed events, @step handlers, an inferred and validated graph, plus documented checkpointing and human-in-the-loop — but the package's own description centres on being a data framework for document agents, parsing, extraction and indexing, and LlamaCloud's pricing is metered in parsing credits at 1,000 credits per $1.25, with $50 and $500 monthly tiers. That is a product optimised for document-shaped work. If your agent's hard problem is a nine-step approval chain rather than a PDF, you are adopting a retrieval stack to solve an orchestration problem. Pick it when documents are the job, not because it is not LangChain.
Google ADK at 2.7.0 on 13 August 2026 is real and describes itself as "model-agnostic, deployment-agnostic," but it is "optimized for Gemini," and choosing it while your identity, network and billing live in AWS buys you a second cloud's operational surface to win an argument about decorators.
The Steel-Man for Staying, Which Is Better Than You Want It to Be
LangChain is not a failing project, and pretending otherwise would make this page useless. The GitHub repository carries 144,400 stars against 329 open issues, langchain 1.3.15 shipped 11 August 2026, and when 1.0 went generally available on 22 October 2025 the company committed to "no breaking changes until 2.0" while citing 90M monthly downloads and production use at Rippling, Uber, LinkedIn, Klarna, JP Morgan, Blackrock and Cisco. LangGraph 1.2.11, also 11 August 2026, is a serious low-level runtime for "long-running, stateful agents" with durable execution, human-in-the-loop and persistence, and we recommended it on its merits in our LangGraph vs CrewAI vs AutoGen comparison. If the state machine genuinely is your product and you already pay for LangSmith, staying is defensible and cheap.
The vendor is also unusually candid about its own boundary. LangChain's own alternatives page, published 6 June 2026, concedes that LangChain "stops at the framework layer" and that if your agent is "a simple prompt wrapper with no tool use or memory," then "a basic logging library is a stronger match for the job." Take the concession at face value and apply it to yourself.
What undercuts staying is that there is no such thing as standing still here. The v1 migration guide requires teams using legacy chains, retrievers, the indexing API or the hub module to install langchain-classic; create_agent replaces langgraph.prebuilt.create_react_agent; prompt became system_prompt; hooks became middleware; Python 3.9 support was dropped. And the compatibility package is on a visibly slower track — langchain-classic's last release was 1.0.8 on 10 June 2026, two months behind the main package's August cadence, positioned for "legacy chains" and "deprecated functionality" with the explicit note that "in most cases, you should be using the main langchain package." Your v0.x codebase is already mid-migration. The only open question is where it lands.
What the Migration Actually Costs
Scope it in three buckets, because the estimate people get wrong is always the middle one.
The loop is small. Prompt assembly, the tool-call cycle, retries and the exit condition are a few hundred lines in any of these targets. A capable engineer moves a nine-step agent in one to two weeks. This is the part teams estimate correctly and then quote as the whole project.
The tools and evals are the real bill. Every tool wrapper, every structured output schema, every integration your framework was quietly supplying — vector store adapters, document loaders, memory backends — is now either a dependency you pick deliberately or code you own. Budget two to four weeks and expect to discover at least one integration nobody knew was load-bearing. If you do not have an eval suite, you cannot verify the migration at all, and building one is the actual prerequisite. The 88% of agent pilots that never reach production die on production readiness rather than on model choice — governance, integration and data plumbing — and a migration you cannot verify is the same category of problem.
Observability is a re-instrumentation, not a config change. Traces, spans and cost attribution are framework-specific. Moving off LangSmith means re-instrumenting, and if you have historical traces you rely on for regression comparison, you lose the comparison. Plan a period of dual-running. Our agent monitoring guide covers what to keep.
Run the old and new paths in parallel against the same eval set before you cut over. A migration you cannot A/B is a rewrite you are hoping about.
The Decision, in Four Questions
- Does an interrupted run resume where it stopped? If no, stop reading and add DBOS or Temporal. Nothing else on this page matters yet. This week.
- Do you have an eval suite that would catch a regression? If no, build it before you migrate anything. You cannot verify a rewrite without one. This month.
- How many providers will you run in twelve months? One means no framework is viable. Three or more means keep a thin abstraction — Pydantic AI or the OpenAI Agents SDK — and do not hand-roll it.
- Who is on call for this at 3am? If it is the team that wrote it, own the loop. If it is a rotation that inherited it, buy the framework and the vendor's support with it.
What changes the answer: a hard multi-cloud or sovereignty requirement pushes you toward self-hosted tooling, which on both LangSmith and Logfire means an Enterprise contract and a very different conversation. A document-heavy workload pushes toward LlamaIndex. And a team that cannot staff an on-call rotation for its own agent loop should not be deleting frameworks, whatever this page says.
The Bottom Line
Every technology cycle produces a moment when the thing that made the prototype fast becomes the thing making production slow, and the industry mistakes it for a vendor problem. It happened with ORMs, it happened with the front-end framework churn of the 2010s, and it is happening now. The teams that came out of those cycles well did not pick a better framework. They worked out which part of the system they had to own, owned it, and bought the rest.
Your agent loop is that part. Durability is not — buy it. Observability is not — buy it. But the sequence matters more than the shortlist, and almost everyone runs it backwards: they rewrite first, discover the crash-resume problem second, and pay for both.
Fix the thing that wakes you up. Then decide whether you still want the rewrite — you may find you don't.
Continue Reading
- LangGraph vs CrewAI vs AutoGen: One of Them Is Retired
- Datadog vs Arize vs LangSmith: Buy on the Billing Unit
- Best AI Agent Monitoring: Langfuse, Then a Real Kill Switch
- The Build-to-Buy Spectrum: 5 Tiers for Enterprise AI Agents
- Why 88% of AI Agent Pilots Never Reach Production
- MCP vs LangChain vs OpenAI Functions: Which for Enterprise?
- What Is an Agent Harness? The $1B Claude Code Architecture
- Pinecone vs Weaviate vs pgvector: Stay on Postgres