LangChain Alternatives Ranked by Upgrade Liability

The best LangChain alternatives on upgrade liability, measured on 31 July 2026, are Pydantic AI, Haystack and Microsoft Agent Framework. LangChain itself now publishes one of the strongest stability policies in the field, so the churn argument against it is out of date.

That last sentence is the finding, and it inverts the reason most teams go looking for LangChain alternatives in the first place. We set out to rank frameworks by documented API breakage between minor versions, expecting the incumbent to score worst. The published record says otherwise: since LangChain 1.0 shipped on 17 October 2025, its release policy commits that "Breaking changes to the public API will only occur in major version releases," and no 2.0 has appeared in the nine months since. Meanwhile two of the most-recommended alternatives are still on 0.x version numbers, and one of them tells you in its own documentation that minor releases are where the breaking changes go.

The problem is real even when the villain is wrong. On 23 November 2025 a developer using Google's Agent Development Kit filed issue #3681 after moving from ADK 1.17 to 1.19: a database column the framework now expected did not exist, and sessions stopped opening. Their expectation, written plainly in the bug report, was "That I could safely upgrade a minor version without breaking changes." Neither of the two releases between those versions carries a BREAKING CHANGES section in the project's own changelog.

The short answer: Rank agent frameworks by what they publish about upgrades: a version policy, a breaking-change record, a per-major migration guide, a support window for the previous major, and a stated cadence for majors. A framework you must rewrite against every few quarters is a standing cost, and on that test Pydantic AI and LangChain lead while LlamaIndex and the OpenAI Agents SDK carry the most exposure.

Last updated: July 31, 2026.

Why upgrade liability is the dimension roundups skip

Upgrade liability is the recurring engineering cost a framework imposes on you after you ship: how often a version bump forces code changes, how much warning you get, and how long the version you are on keeps receiving fixes. Roundups compare features, pricing and star counts, and none of those changes after you commit. The upgrade bill arrives every quarter for as long as the system lives, and it is the only line in a framework comparison that compounds.

The academic literature has caught up with what practitioners have been saying since 2023. A systematic literature review of 97 primary studies across five ecosystems, published on arXiv in May 2026 by Juntao Chen, Tingting Bi, Yanlin Wang and Patanamon Thongtanunam, names three open challenges in this space. One of them is "the failure of semantic versioning as a trust mechanism." That is the whole problem in seven words. A version number is a promise, and the review's finding is that across ecosystems the promise is not reliably kept, which means a buyer cannot read 1.4.0 → 1.5.0 and infer safety. You have to read what the project says it will do, and then check whether it did.

That is a different exercise from the one most comparison articles run. Every input is a public artefact with a date on it: a policy page, a changelog entry, a migration guide, a release tag. This article is that exercise, run on eight frameworks on one day so the numbers are comparable.

Two things this article deliberately does not do. It does not rank frameworks on tracing or evaluation tooling. Our earlier analysis of AI observability and audit trails covers that ground, and the answer there does not depend on which orchestration library you picked. And it does not re-run the multi-agent orchestration comparison; our head-to-head on what CrewAI and AutoGen each let you enforce covers those two, including what happened when one of them entered maintenance mode.

At a glance: eight frameworks, measured on one day

Every figure in this table was read from the Python Package Index release history and each project's public repository on 31 July 2026. "Minor lines" counts distinct X.Y version lines that received at least one release in the trailing twelve months, a proxy for how often the project opens a new feature line, which is the channel where breaking changes travel under both semantic versioning and the 0.x convention.

Read that table twice, because the obvious reading is wrong. Pydantic AI has by far the highest release cadence on the list, at 179 releases and 134 distinct minor lines in a year, which is roughly one new minor line every three days. On a naive "churn" metric it looks like the least stable project here. It is, on the evidence, the most conservative one, because its Version Policy states: "We will not intentionally make breaking changes in minor releases." Cadence and churn are different quantities. High cadence with a kept promise is a feature; low cadence with an unwritten policy is not safety, it is silence.

LlamaIndex sits at the other end of that illusion: only 29 releases across 2 minor lines in twelve months, the calmest-looking row in the table, and the highest exposure on this list, because under a 0.x scheme those two minor bumps are precisely the releases that are permitted to break you, and the project has published no statement anywhere about what a minor bump is permitted to do.

The Upgrade Liability Test: five documents

Here is the test, named so it travels. Ask five questions of any framework you are considering, and answer each one by finding a public document rather than by asking a vendor.

1. Is there a written version policy? A page that states what will and will not change in a minor release. Not a README adjective — a policy.
2. Is there a breaking-change record? A place where every breaking change is listed, per version, with what to do about it.
3. Is there a migration guide for each major? Written before you need it, with before-and-after code.
4. Is there a support window for the previous major? A duration, in months or years, during which the version you are on still receives security fixes.
5. Is there a stated cadence for majors? Any commitment at all about how often the ground moves.

Score each question and you have a number between zero and five that predicts your maintenance load better than any feature matrix. Two frameworks here score four or five. Three score below two. That gap is worth more to a two-year roadmap than any difference in retrieval quality or agent ergonomics.

The test has one deliberate bias, and it is worth naming: it rewards projects that write things down. A framework can be genuinely stable and score badly because nobody has published the policy. Semantic Kernel is exactly that case. But from a buyer's seat, an undocumented practice is not a commitment. It is a habit that can change without anyone telling you, and habit is not something you can put in a risk register.

How we measured this, and what the numbers cannot tell you

Release counts, first-release dates and version lines come from each package's public release history on the Python Package Index, read on 31 July 2026, excluding alpha, beta and release-candidate builds. Policy findings come from each project's own documentation site or repository, fetched the same day.

We have not migrated a production codebase between any two of these frameworks, and this article contains no first-hand migration timings. That is the honest limit of the method: what is measured here is the published contract and the observable release record, not the lived difficulty of a port. Those two things correlate, but not perfectly. A project with a thin policy and a small, well-factored API surface can be easier to upgrade than a project with an excellent policy and an enormous one.

One measurement caveat belongs here rather than in the limits section at the end. Counting X.Y lines is a proxy: it tells you how often a project opens a door through which a breaking change is permitted to walk, not how often one did. Where a project publishes an explicit breaking-change record, and Google ADK and the OpenAI Agents SDK both do, we counted the actual entries instead, and those counts appear in the relevant sections. And where a project ships Python and .NET on separate version tracks, the figures above are the Python package.

LangChain: the incumbent, re-scored

Best for: teams that want the largest integration surface in the ecosystem and can now get it with a published stability contract attached.

What the policy says. Since 1.0, LangChain's release policy is explicit on all five test questions. On minor releases: "Minor releases contain new features and improvements but do not include breaking changes." On deprecations: "deprecated features will continue to work throughout the entire 1.x release series." On the support window, it designates 1.0 as a long-term-support release with the status "ACTIVE until the release of 2.0," and states that after 2.0 arrives, "1.0 will enter MAINTENANCE mode for at least 1 year." It even carries a date for the old line: LangChain 0.3 is in maintenance mode, with a support period listed as "Until December 2026."

The breaking-change record. This is where the framework's reputation was earned, and it is worth being precise about the dates rather than repeating a vibe. langchain 0.1.0 landed on 6 January 2024. langchain-core 0.2.0 followed on 17 May 2024, and 0.3.0 on 13 September 2024. Under the 0.x convention each of those was a breaking line. Three breaking lines in roughly twenty-one months is the record teams remember, and it is why the complaint persists. Then 1.0.0 shipped on 17 October 2025, and in the nine months since, langchain-core has released seven minor lines, 1.0 through 1.5 plus the tail of 0.3, and no major.

The migration guide. The LangChain v1 migration guide is the most concrete artefact of its kind on this list. It documents the namespace reduction, names the langchain-classic package that legacy chains, retrievers, the indexing API and the hub module now live in, and provides a change-by-change table for moving from create_react_agent to create_agent, including the renamed system_prompt parameter and the replacement of pre-model and post-model hooks by middleware.

Licence and cost. MIT, free. The commercial products in the LangChain ecosystem are separate purchases and do not gate the framework.

Bottom line. On the published contract, LangChain is now a low-liability choice, and a team that left in 2024 over churn is arguing with a version of the project that no longer exists. The one thing missing from the policy is a cadence commitment for majors: LangGraph's half of the same policy page says the team expects "to space out major releases by at least 6-12 months," but the LangChain half sets no equivalent interval. So you know 1.0 will be supported for a year after 2.0 arrives; you do not know when 2.0 arrives.

Pydantic AI: the only one with a dated support window

Best for: teams that want typed, testable agent code and the clearest upgrade contract published by anyone in this market.

What the policy says. The Version Policy is the strongest document surveyed here, and it is short enough to read in a coffee break. On minors: "We will not intentionally make breaking changes in minor releases." On deprecations: "Functionality marked as deprecated in a release is not removed until the next major version," and the page adds that the next major will not arrive sooner than three months after V2.0. On the previous major, it commits to continuing to provide "security fixes for V1 for at least 6 months after V2" reaches stable release. That is questions one, four and five answered with numbers, which no other project on this list does.

It also does something unusually honest: it enumerates what will not count as a breaking change, including adding new message parts, stream events or optional fields on existing types, and changing OpenTelemetry span attributes. If you consume message streams defensively, as the policy instructs, you know exactly which surface can move under you.

The breaking-change record. V1 shipped 5 September 2025. V2.0 shipped 23 June 2026, nine and a half months later, through the seven public betas the Upgrade Guide lists as v2.0.0b1 to v2.0.0b7. The Upgrade Guide opens by describing what that gap was for: "In September 2025, Pydantic AI reached V1 and committed to API stability: no changes that break your code until V2." The same paragraph describes V2 as collecting the breaking and behavior changes that the stability guarantee had held back. That is the mechanism working as designed. Breaking changes accumulated behind a wall, then released together, on a schedule, with a guide.

The one caveat. 179 releases and 134 minor lines in twelve months is a real operational load even when none of them breaks you. Every one is a dependency-update pull request, a rebuild, and a re-run of your test suite. Teams with slow CI or a heavyweight change-approval process will feel that cadence as friction even though it is not, on the published policy, risk. The policy also carves out beta features, whose "API and behaviors may not be stable" while in that phase, so the guarantee applies to the stable surface, not the whole library.

Licence and cost. MIT, free. Pydantic's commercial observability product is a separate purchase.

Bottom line. Highest score on the Upgrade Liability Test. If a written, dated upgrade contract is what you are shopping for, this is the answer, and the nine-and-a-half-month V1-to-V2 interval is the only real data point anyone on this list has published about how long a major generation lasts.

Haystack: one major in twenty-eight months, and a 1,135-line receipt

Best for: retrieval-heavy and pipeline-shaped applications where you want components you can reason about, and a team that documents a migration properly when it happens.

What the policy says. We could not find a published version or deprecation policy page for Haystack on its documentation site or in its repository as of 31 July 2026. That is a real gap, and it costs the project two of the five test questions.

The breaking-change record. The haystack-ai package's 2.0.0 shipped on 11 March 2024. Version 3.0.0 shipped on 20 July 2026. That is one major in twenty-eight months, the longest stable generation of any framework here that has actually shipped a second major. Sixteen minor lines received releases in the trailing twelve months, but under semantic versioning those are additive.

The migration guide. This is where Haystack redeems its missing policy page. The 2.x-to-3.x migration guide sets expectations before it lists a single change. "Haystack 3.x is an evolution of Haystack 2.x, not a rewrite: components, pipelines, and the Agent work as before." Then it does the work: legacy generators removed with before-and-after code, ToolInvoker folded into the Agent component, renamed parameters listed in a table, and components that moved into separate integration packages named individually. The full record lives in a MIGRATION.md in the repository that runs to 1,135 lines and carries 15 named breaking-change sections. That is the most detailed per-major migration document surveyed here.

Project-health finding. The same guide contains a disclosure a buyer needs: the haystack-experimental package "is no longer installed automatically. The package is now archived and unmaintained: 0.19.0.post1 is its final release." The repository confirms it: deepset-ai/haystack-experimental is marked archived. Most of its contents graduated into the core package, so for most teams this is a housekeeping item rather than a loss, but if you built on an experimental component you now own it.

Licence and cost. Apache 2.0, free. deepset's commercial platform is a separate product.

Bottom line. The best actual track record on this list, undermined by the absence of a written promise. If you are choosing on evidence rather than on paperwork, Haystack has the evidence. If your procurement process needs a policy document to point at, it does not have one.

Microsoft Agent Framework: a successor that is itself a migration

Best for: .NET-heavy organisations, and Semantic Kernel or AutoGen teams who now have somewhere specific to go.

What the policy says. No published version policy page was found. The Semantic Kernel repository's README describes Microsoft Agent Framework as the enterprise-ready "successor to Semantic Kernel" and states that it "is now available at version 1.0 as a production-ready release: stable APIs, and a commitment to long-term support." That is an assertion of a support commitment without a window attached: no duration, no end date, no definition of what long-term means. It scores as asserted, not published.

The breaking-change record. agent-framework 1.0.0 shipped on 2 April 2026. Twenty releases across fourteen minor lines have followed in under four months. There is not yet enough history to judge whether the stability claim holds, which is itself the finding: a four-month-old 1.0 has no track record, and a promise with no elapsed time behind it is a forecast.

The migration guides. Microsoft publishes a migration guide hub with routes from Semantic Kernel, from AutoGen and from the A2A SDK v1. Publishing three inbound migration paths before the framework is six months old is unusual and genuinely useful. It also tells you something: this framework's job includes absorbing two existing communities, and consolidation is how Microsoft is managing its own agent-framework churn rather than how it is avoiding it.

Licence and cost. MIT, free.

Bottom line. The strategically safe Microsoft choice and the one with the least evidence. If you are already on Semantic Kernel or AutoGen, the migration guide from your current framework exists and the destination is where Microsoft is investing. If you are choosing fresh and you need a track record, come back in a year.

Semantic Kernel: the most stable version number on this list

Best for: teams already running it in production who need to plan an exit rather than a rewrite.

What the policy says. The public Semantic Kernel support page is a routing page to documentation, the repository and community office hours; it carries a last-updated date of 6 March 2025 and does not state a version or deprecation policy. No policy page was found elsewhere.

The breaking-change record. This is the best raw stability record here. semantic-kernel 1.0.0 shipped on 21 May 2024. The latest is 1.44.0, released 7 July 2026, twenty-six months into a single major line, ten minor lines in the trailing year, no 2.0. On version numbers alone, Semantic Kernel is the calmest project surveyed.

And it is being succeeded anyway. The repository README opens with a notice that "Semantic Kernel is now Microsoft Agent Framework" and links a Semantic Kernel migration guide. Releases continue, and Python 1.44.0 landed in July 2026, so this is not an archived project, and nothing we found announces an end-of-support date. But the maintainer has named a successor, and that is the entire point of this article: a stable version number is not a stable roadmap. Twenty-six months without a breaking change is worth nothing to a team that has to move anyway, and every rung of the Upgrade Liability Test can be passed by a project whose vendor has already decided where the future is.

Licence and cost. MIT, free.

Bottom line. Do not start here in 2026. If you are already here, you are not in trouble, because the code still works and still ships releases — but the migration guide to Agent Framework is the document to read, and the planning is better done on your schedule than on someone else's announcement.

Google ADK: the changelog is honest and the record is uncomfortable

Best for: teams committed to Google Cloud and Vertex, who want first-party deployment paths and can absorb the upgrade tempo.

What the policy says. No standalone version policy page was found. What ADK has instead is a machine-generated changelog that marks breaking changes explicitly, which is better practice than most projects here and is why the project is ranked above the two 0.x entries despite its record.

The breaking-change record, counted. Reading every version section in the ADK changelog on 31 July 2026: of 59 documented releases, eight carry a BREAKING CHANGES section. Four of those eight are pre-1.0 releases and a fifth is the 1.0.0 major itself, which is where breaking changes belong. The other three are what matter, and all three landed in minor releases: 1.23.0 (22 January 2026), 1.24.0 (4 February 2026) and 2.6.0 (29 July 2026). The 1.24.0 entry changes what the credential manager accepts. The 2.6.0 entry, published two days before this article was written, namespaces file artifacts by app. For contrast, that 1.0.0 entry carried nine breaking items, including "All methods in services are now async, including session service, artifact service and memory service" and a redesigned memory schema.

That is the mechanism the assigned hypothesis predicted, found in the wrong project. And it is corroborated by the problem card this article opened with: the developer who moved from 1.17 to 1.19 and lost session access to a database column that did not exist. Neither 1.18.0 nor 1.19.0 carries a BREAKING CHANGES section, so a team reading the changelog carefully before upgrading would still have been surprised. Schema migrations are the class of breakage a changelog convention aimed at API signatures does not catch.

Two version lines at once. ADK 2.0.0 shipped on 19 May 2026, and the 1.x line did not stop: 1.37.0 was published on 30 July 2026, the same day as 2.6.0. Running a maintained previous major in parallel is a genuine kindness to production teams and is the closest thing to a support window ADK offers. It is not written down as a policy, so you cannot plan on it.

Licence and cost. Apache 2.0, free. The Google Cloud services you deploy onto are not.

Bottom line. ADK's changelog discipline is above average and its upgrade record is below it. Choose it for the Google Cloud integration, not for a quiet life, and read the changelog before every bump rather than after.

OpenAI Agents SDK: minor releases are the breaking channel

Best for: teams building directly against OpenAI's models who want a small, current SDK and are willing to pin.

What the policy says. This is the most candid document in the survey, and what it says is not reassuring. The SDK's release process page states: "The project follows a slightly modified version of semantic versioning using the form 0.Y.Z. The leading 0 indicates the SDK is still evolving rapidly." It then defines the channel precisely: "We will increase minor versions Y for breaking changes to any public interfaces that are not marked as beta." And it gives advice: "If you don't want breaking changes, we recommend pinning to 0.0.x versions in your project."

Read that last sentence as a buyer. The current release is 0.19.1. Taking the project's own advice would leave you nineteen minor lines behind the version everyone else is running, on a model-facing SDK whose entire value is tracking a fast-moving API.

The breaking-change record, counted. The same page carries a per-minor changelog. Of the nineteen documented minor releases, eight state that the release introduces no breaking or visible breaking change; the other eleven describe a change that can require migration work: a changed default model, refusals surfaced as a new exception type, a dropped Python version, a major dependency version no longer supported, a changed handoff history format. Eighty-seven releases across eighteen minor lines shipped in the trailing twelve months.

The migration guide. There is no separate per-major migration guide, because there has been no major. The release page is the migration guide, and for the changes it covers it is specific and includes code. That is more than several higher-scoring projects offer for a given release.

Licence and cost. MIT, free. The model calls are not.

Bottom line. Highest documented breaking-change frequency on this list, and the highest transparency about it. That combination is defensible for a team that reads release notes before every bump and treats the SDK as a thin, replaceable layer. It is a poor fit for a system that will be maintained by a rotating team over three years.

LlamaIndex: three years and still on 0.x

Best for: retrieval and indexing work where the breadth of connectors and readers is the reason you are here, on a team that pins hard and upgrades deliberately.

What the policy says. No version or deprecation policy page was found on the LlamaIndex documentation site as of 31 July 2026. What exists instead is a Deprecated Terms page, a useful list of renamed and retired constructs with pointers to replacements, including ServiceContext deprecated in favour of Settings, QueryPipeline deprecated in favour of Workflows, and a roster of agent classes deprecated in favour of AgentWorkflow. It is a glossary of what happened, not a statement of what will happen.

The breaking-change record. llama-index-core has never released a 1.0. Its first release under that package name was 0.9.41 on 2 February 2024, and the current release is 0.14.23, published 24 June 2026. Under the 0.x convention the minor position carries the breaking changes, which puts every one of 0.10, 0.11, 0.12, 0.13 and 0.14 in that role. Two of those lines opened in the last twelve months: 0.13.0 on 30 July 2025 and 0.14.0 on 8 September 2025.

The migration guide. This is where the section turns, and it turns less far than the version scheme suggests. The GitHub release entries for v0.13.0 and v0.14.0 do carry notes, and those notes mark breaking items explicitly: 0.13.0 removed the deprecated agent classes and the QueryPipeline, and changed what index.as_chat_engine() returns by default; 0.14.0 bumped the workflows dependency to 2.0, removing the deprecated checkpointer and sub-workflow features. That is a real breaking-change record and it earns the point. What we could not find is the layer above it: no dedicated migration guide for either version, no before-and-after code, and no statement anywhere of what a minor bump is permitted to do. The reader is handed a list of removals and left to work out the path.

A note on the calm-looking numbers. Twenty-nine releases across two minor lines makes LlamaIndex the quietest row in the at-a-glance table. Do not read that as stability. It is a 0.x project with no published policy and a modular layout in which dozens of integration packages each carry their own version, so the upgrade surface is larger than the core release count suggests.

Licence and cost. MIT, free. LlamaCloud is a separate commercial product.

Bottom line. Highest upgrade liability of the eight on the published evidence, which is a statement about the documentation above the release notes rather than about code quality. LlamaIndex remains one of the strongest retrieval libraries available. If you choose it, choose it knowing you are underwriting the upgrade risk yourself: pin exactly, budget review time for every minor bump, and keep an integration test that exercises your retrieval path end to end.

The ranking, and how each framework earned its place

Five questions, five points, scored on documents that existed on 31 July 2026.

The scores and the ranks deliberately disagree in three places, and each disagreement is part of the argument.

The OpenAI Agents SDK scores 2.5 and ranks seventh. Its documents are good, and its documented behaviour is that breaking changes ship in minor releases roughly every six weeks. A high score for candour does not lower the bill.

Semantic Kernel scores 0.5 and ranks fifth. Twenty-six months without a breaking change is worth something real to a team running it today. What it is not worth is a new project, because the maintainer has named a successor.

LlamaIndex scores 1 and still ranks last. It earns its point honestly: the release notes for its breaking lines mark the breaking items as breaking. What it has above that point is nothing at all, on a version scheme that has never made a stability commitment in the first place.

The general rule the ranking encodes: weight the record over the paperwork when the two disagree, and weight the roadmap over both. A framework can keep every promise in its policy and still cost you a rewrite because the vendor moved the whole product line. That risk is invisible to every version number and every changelog, and it is why the fifth question, whether anyone is saying anything about the future, matters more than its single point suggests.

Choose one: a decision tree you can run in an afternoon

Choose Pydantic AI if your team writes typed Python, you want the upgrade contract in writing with dates in it, and your CI can absorb a fast dependency cadence without complaining. It is the only framework here that has published both a support window and a floor on how soon the next major can arrive.

Choose LangChain if you need the widest integration surface and you want a long-term-support commitment attached to it. The 2024 churn complaints describe a project that has since published a semantic-versioning policy, an LTS designation and a maintenance date for the old line. Re-read the policy before you inherit someone else's opinion of it.

Choose Haystack if your workload is retrieval and pipelines, you value a genuinely detailed migration document over a policy page, and you can live with a project that has earned trust by behaviour rather than by publishing a promise. One major in twenty-eight months is the strongest record here.

Choose Microsoft Agent Framework if you are a .NET shop, or you are already on Semantic Kernel or AutoGen and want the maintainer-sanctioned destination. Accept that you are buying a strategy rather than a track record.

Choose Google ADK if your deployment target is Vertex or Agent Engine and the first-party integration is worth an upgrade tempo that has put breaking changes into three minor releases. Pin, read the changelog before every bump, and test your session storage explicitly.

Choose the OpenAI Agents SDK if you are building thin and close to OpenAI's models, your team reads release notes as a matter of course, and the orchestration layer is small enough that a rewrite is a week rather than a quarter.

Choose LlamaIndex if retrieval breadth is the product requirement and you are prepared to own the upgrade risk yourself with hard pins and end-to-end tests. Choose it for the connectors, not for the release process.

Choose none of them if your application is one model call and a couple of tools. Two of the frameworks above exist partly because teams discovered that the framework was larger than the problem, and a direct provider SDK behind an interface you own has an upgrade liability you control completely.

When LangChain still wins

The honest case for staying put is stronger than the roundup format usually allows, so here it is plainly.

The integration surface is not replicable. LangChain's partner-package ecosystem is the largest in this market, and the release policy states that packages maintained by LangChain, such as langchain-openai and langchain-anthropic, "follow semantic versioning and are expected to be stable post 1.0." If your system touches a dozen providers and stores, re-implementing those integrations dwarfs any difference in upgrade policy.

The churn complaint is dated. The most-quoted criticisms come from the 0.x era. Hacker News user sophiabits, writing in a June 2024 comment thread, described exactly the experience that built the reputation: "the rate of change in the library was huge," said of a codebase their team had already left in 2023. That is a real report about a real period. It is not a report about the 1.x policy, which did not exist for another sixteen months.

Migrating has its own liability. Every framework migration is a breaking change you inflict on yourself, with none of the compensating benefit of a version bump. If the alternative you are moving to scores worse on the Upgrade Liability Test than the incumbent you are leaving, and on this ranking that is true for six of the seven alternatives relative to LangChain, the move increases your standing cost rather than reducing it.

The one condition under which leaving is clearly right: you are on 0.3 and doing nothing. That line is in maintenance mode with support listed until December 2026. Staying is a decision with a date on it, and the cheapest available move is to 1.x with the published migration guide, not to a different vendor.

What framework churn costs after the code compiles

There is a second bill, and it is the one this company exists to deal with.

When a framework changes, the code changes — and so does everything the code was doing on your behalf. Which credentials the agent used. Which tools it could reach. Which steps needed a human. What got written into the audit record, and in what shape. A migration that a test suite passes can still quietly change the answer to "what is this agent allowed to touch," because those answers were expressed in framework constructs and the framework constructs moved. Google ADK's 1.24.0 breaking change is a small, concrete example of the genre: the credential manager now accepts a different context object. The credentials still work. The place they are handed over is not the place it was.

The durable fix is to stop expressing control in the framework. If identity, scope, approval and the audit record live in a layer the agent calls rather than in the library the agent is built from, a framework migration becomes a code change instead of a governance change. That is the layer LeapForce builds: one governed endpoint in front of every model, non-human identities with an owner, a scope and an expiry, connectors that IT vets once with action-level scoping, and an audit record that captures what was refused as well as what ran. Our AI Gateway rollout guide is headlined "Observe first. Enforce second. Optimize third.", and its opening phase points one team's traffic at the gateway in observe mode with no rules applied at all, precisely so the enforcement points get established independently of whatever orchestration library is in fashion. This does not make your migration free, and LeapForce does not replace an agent framework: you still write the agent in one of the eight above.

That separation is also what a governance framework asks for. The NIST AI Risk Management Framework's GOVERN 6.1 states that "Policies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third party's intellectual property or other rights." GOVERN 6.2 adds that "Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk." An agent framework is a third-party component, and a maintainer naming a successor is exactly the kind of event a contingency process is for. If you want the identity half of this argument in more depth, our analysis of non-human identity covers owner, scope and expiry for agents specifically.

Where this analysis is weakest

We did not run the migrations. No production codebase was ported between any two of these frameworks for this article, and no migration timings are reported. The Upgrade Liability Test measures published contracts and observable release records. It is a proxy for effort, not a measurement of it.

Absence of a document is not proof of absence. Several findings here are "no policy page was found" after searching each project's documentation site, sitemap and repository on 31 July 2026. A policy might exist somewhere we did not look, or in a forum post, or in a maintainer's head. We have written these as not found rather than as non-existent, and a project that publishes one after this date deserves a re-score.

One day is a snapshot. Every number here has a date on it because every number will change. Two of the eight, Haystack 3.0 and ADK 2.6.0, shipped within eleven days of this article being written. Re-run the test before you commit; the point of the method is that it costs an afternoon.

We did not evaluate capability or the commercial layer. Nothing here says which framework builds better agents, retrieves more relevant documents, or costs less to run, and a framework that scores five on upgrade liability but cannot do what you need is not a candidate. Several of these projects also sit next to paid products from the same vendor, which carry their own pricing, deprecation policies and version histories. None of that is measured here.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.