When to Use an Agent Framework vs Build It Yourself (LangGraph, CrewAI, and More)

You picked a framework a year ago, for good reasons. Plenty of examples, a name your new hires recognized, a conference talk that made the decision feel settled. Then somebody on the team opens the repository one morning to check which version you are on, and the first thing on the page is a line that was not there before: the project is in maintenance mode, it will not get new features, and it is community managed from now on. No email arrived. No support window was published and no date was given. You found out from a README, because a README was where it was.

That scene is a composite, assembled rather than reported. The line inside it is a quotation: “AutoGen is now in maintenance mode” is what the AutoGen README said when I read it in September 2026.

The honest answer to “framework or build it yourself” is not “always” and it is not “never.” It is this: build the raw loop yourself until you hit a specific, nameable pain, then adopt a framework to solve that pain, and not before. A framework adopted on principle, or out of fear that hand-rolled code looks unserious, trades code you understand for abstractions you do not. A framework adopted to solve a real coordination, state, or scale problem you have already felt is one of the best decisions you can make.

And to be clear about the point of building it yourself: the raw loop is not a detour you throw away once you adopt a framework. It is where you isolate the assets you actually own, your tools, your prompts, your decision logic, so that reaching for a framework later is plugging that core into it rather than marrying your logic to it. Build first to understand and to own, not to avoid frameworks forever.

This post gives you the decision as a diagram, the concrete signals that tell you which side of the line you are standing on, and then a shortlist: who steers each framework, what it has done the last time it broke something, and how much of your code would move if you left. It is the capstone of the build-from-scratch cluster: if you have not yet built an agent from scratch in Python, wired up tool calling from first principles, or given your agent memory, read those first. This is the post where the abstractions those pieces deliberately avoided start to mean something. The framework chapter of Understanding Agentic AI Systems walks the same decision with a single running example.

The decision in one diagram

The whole rule fits on one page. You start from a working raw loop, you ask one question, and the answer routes you.

The trap is answering “yes” to the question before you have actually felt the pain. “We might need multi-agent coordination later” is not a pain. “Our three agents keep clobbering each other’s state and we have spent two days debugging it” is. Build until the pain is concrete, then name it, then adopt the smallest thing that solves the named pain.

What you are actually choosing between

Before the signals, it helps to know the terrain. “Framework” is not one thing. There are four kinds of choice in front of you, and they are not mutually exclusive.

• Raw loop. You own the control flow. Model call, tool dispatch, append result, repeat. Maximum clarity, maximum responsibility.
• Graph / state-machine frameworks. You describe the agent as nodes and edges with explicit, durable state. Strong when control flow is complex and a run must survive a crash.
• Role-based orchestration. You describe a team of agents with roles that hand work between each other. Strong when the natural decomposition is several specialists, not one loop.
• Managed cloud runtimes. You write the agent in some SDK and let a cloud platform handle autoscaling, persistence, identity, and observability. This is a deployment choice that increasingly sits underneath any of the above.

Here is the map of the names worth knowing in 2026, and what each is genuinely good at. The map tells you what each one is for. The second half of this piece tells you what you are signing up for when you pick one.

The map already looks different from a year ago, and that is the most important thing it teaches. Microsoft now ships a single Agent Framework built by unifying Semantic Kernel and AutoGen. AG2 is an Apache-2.0 fork of AutoGen maintained by volunteers. Swarm, which OpenAI’s own repository calls experimental and educational, has been replaced by the Agents SDK. The names on this map keep moving. How you find out when one of them moves is the subject of the rest of this piece.

When a framework earns its cost

These are the nameable pains. When you hit one of them for real, the framework stops being overhead and starts paying for itself.

• Durable, resumable state. Your agent runs for minutes or hours, and a crash, deploy, or timeout in the middle should not start it over from zero. Hand-rolling checkpointing, serialization, and resume-from-step is real systems work.
• Multi-agent handoffs. The work genuinely decomposes into specialists that pass results to each other: a planner, a researcher, a writer, a reviewer. Coordinating that by hand means inventing a message protocol, turn-taking, and shared state.
• Parallel fan-out and join. Ten tool calls or ten sub-agents at once, then merge the results. Doing that safely in a raw loop means managing concurrency, partial failure, and aggregation yourself.
• Human checkpoints. A run needs to pause, surface a decision to a person, and resume with their input, sometimes hours later. That needs durable state plus an interrupt-and-resume mechanism, and building it from scratch is a project of its own.
• Tracing at scale. Once you are running thousands of agent invocations a day, “read the logs” stops working. You need spans, replay, token accounting, and per-step latency across many runs.
• Team velocity. Five engineers hand-rolling five slightly different loops is its own cost. A framework gives a shared mental model, shared docs, and a hiring pool that already knows the abstractions. This one is real, and it is also the one most often used to justify a framework before any of the others are true. Be honest about whether it is the actual reason.

The other half of the decision matters as much, because the default in 2026 is to over-adopt.

If your agent is a single perceive-decide-act-observe cycle over three or four tools, a framework adds indirection you will fight every time you debug. If you are still learning your own failure modes, the most valuable thing you have is being able to read every line of why the agent did what it did, and frameworks move that logic behind abstractions. If you are fighting for milliseconds, a thin loop you can profile beats a general-purpose framework you cannot. And the more your business logic is written in a framework rather than called by one, the more expensive it is to leave.

That last one is what the rest of this piece is about.

What you are actually signing up for

The AutoGen line at the top of this post is real, so here is what happened around it. The shape of it is more interesting than the headline.

On 3 April 2026 Microsoft released Agent Framework 1.0 for .NET and Python. The announcement is about as committed as these things get: “This is the production-ready release: stable APIs, and a commitment to long-term support.” It describes the work as an effort to unify “the enterprise-ready foundations of Semantic Kernel with the innovative orchestrations of AutoGen into a single, open-source SDK”. It ships migration assistants that, in Microsoft’s words, “analyze your existing code and generate step-by-step migration plans”. When I read that announcement in full in September 2026, it did not say that either predecessor was deprecated, and it gave no sunset date for either one.

The hard language is somewhere else entirely. The AutoGen README says: “AutoGen is now in maintenance mode. It will not receive new features or enhancements and is community managed going forward.” Semantic Kernel’s README says something with a different temperature: “Semantic Kernel is now Microsoft Agent Framework! Microsoft Agent Framework (MAF) is the enterprise-ready successor to Semantic Kernel.” Successor framing on one, maintenance mode on the other. Two projects, one unification, two different statements about what you are now holding, and both of those statements live in a README rather than in a support policy.

Then there is the fork. AG2 is an Apache-2.0 fork of AutoGen, and its README says it “is currently maintained by a dynamic group of volunteers from several organizations”.

This is the part I keep coming back to. AG2 exists so that people could keep working on the thing they already had. Then AG2 shipped its own 1.0, and that release moved the original autogen.* namespace, ConversableAgent and GroupChat, the names your code actually imports, out into a separate repository called ag2-classic with its own documentation site. That repository is still there and is not archived, though its last push when I checked was 8 July 2026. The fork that existed so nobody would have to migrate shipped one.

I do not read that as anyone’s failure of judgment. A project that never reorganizes its namespace is a project that has stopped. The point is narrower than blame. The status change, the successor label and the namespace split all reached me the same way, by reading a repository, and none of the three carried an end date for the thing it was replacing. You found out from a README, from a version number, or from a migration guide.

What to look for

If you are about to pick one, these are the things I would check before the feature list. Most of them take a few minutes in the repository.

Who steers it, and who pays for that. A single company, a hyperscaler, a foundation, or a group of volunteers all behave differently when priorities shift. None of those is disqualifying on its own, and the answer is harder to find than you would expect.

The license. Look at what the license actually is, and separately at whether a commercial product sits next to the open-source one. Open core is a normal arrangement and usually a healthy one, but it tells you which parts are most likely to get attention.

The migration record. What did the project do the last time it broke something? A major version that arrived after public betas, with an upgrade guide, is a different experience from one that lands finished.

How a breaking change reaches you. Does the repository say anywhere, in advance, what may change in a minor release? If it does not, then your answer to “how will we find out” is “a colleague notices”.

How thin the layer is. Can you still see your own loop through it? If you cannot follow one request from the model call to the tool dispatch and back, you have bought something you will not be able to debug on a bad day.

How much of your code is shaped like the framework. Not how much of it uses the framework. How much of it only makes sense inside the framework. That is your exit cost, and it is the only item on this list you control.

The shortlist

The map above split these two ways, independent frameworks and hyperscaler platforms. Here they are cut a different way, grouped by who decides what happens next, because that turned out to be the thing worth grouping on. The last group is the exception: there the version number does the grouping, and both of its projects would otherwise sit in the first group. Every version number and date below was read on the project’s own repository, release metadata, package index, or engineering blog in September 2026, so all of it is checkable and all of it will age.

In the day I spent reading these nine projects, Google shipped ADK 2.9.1 later the same day I had written 2.9.0 down as the current release, the address Google’s documentation publishes for the Agent Engine overview turned out to be titled something else, and the Strands repository I had been quoting from, strands-agents/sdk-python, was renamed to strands-agents/harness-sdk. None of that changes which framework you should pick. It changes how long any answer to that question stays good.

On one axis, that is what the last twelve months looked like.

I am not ranking these against each other. Ranking Pydantic AI against Google ADK is a category error: they are answering different questions for different teams. What each entry says is what a buyer can find out before committing.

The ones a single company steers

Pydantic AI. MIT, maintained by Pydantic. It reached 1.0.0 on 5 September 2025 and 2.0.0 on 23 June 2026. The V2 release note opens with the sentence you want to see: “After seven betas, Pydantic AI V2 is now stable.” V2 “leans into a harness-first design with capabilities as a core primitive”, and there is an upgrade guide covering “the recommended path from V1”. Seven betas is what makes a breaking major release fair to the people living with it.

LangGraph. MIT, maintained by LangChain, which sells commercial products alongside it. 1.0.0 landed on 17 October 2025, and on 11 August 2026 the project was at 1.2.11: still the same major version, minors ticking along. That is a quiet record, and quiet is worth something. If you want the longer argument about where LangGraph’s abstractions hold and where they do not, I wrote it up for voice agents, where the timing constraints make the seams visible.

CrewAI. MIT, maintained by crewAIInc, a company. Worth correcting an old impression: the README describes CrewAI as “a standalone Python framework with its own primitives for agents, tasks, crews, flows, tools, and orchestration”, so the common description of it as a thing built on top of LangChain is not what the project says about itself. There is a commercial layer, stated plainly in the README: “CrewAI AMP Suite adds managed deployment, observability, governance, security, and enterprise support.” On PyPI the framework reached 1.0.0 on 20 October 2025 and was at 1.15.21 on 9 September 2026. One thing to watch when you are reading about it: the 0.102.0 you may see quoted is the CLI tool, not the framework.

The trade in this group is easy to state. Each of these three is steered by a company that also sells something alongside the open-source project: LangSmith beside LangGraph, the AMP Suite beside CrewAI, Logfire beside Pydantic AI. That gives a company a concrete reason to keep the free thing working and also tells you which parts will get the attention. All three have crossed 1.0, which is at least a statement of intent about breaking changes. What you are accepting is that one company’s priorities are one company’s priorities, and you will read about the change in the same release notes as everyone else.

The hyperscaler SDKs

Strands Agents. Apache-2.0, with Python and TypeScript SDKs. Strands does something I would like to see more of: the repository carries a written compatibility policy, at team/COMPATIBILITY.md, that states in advance which changes are not considered breaking under semantic versioning, with rationale and code examples. One example from it: converting a public mutable field into a property with validation or side effects “is not considered a breaking change” and may ship in a minor or patch release. Agree with that or not, you now know it before you write the code that depends on it. The same directory holds a DECISIONS.md that records design decisions with dates and reasons, so you can read why a thing is the way it is. Of everything I read for this piece, that policy is the most directly useful thing a buyer could find.

The governance question is a different matter. I went looking for who holds final authority over the Strands roadmap: a GOVERNANCE.md in that same directory (there is none), the tenets and decisions files, the repository root, and the strands-agents GitHub organization profile, which has no company, blog, or description set. I did not find an answer. The NOTICE file reads “Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.”, and the SDK defaults to the Amazon Bedrock model provider while offering first-class support for Anthropic, OpenAI, and Gemini as well. Copyright tells you who holds it. A default tells you what the SDK reaches for first. Who decides what ships is a third question, and I would rather record that I came back empty than guess at it.

Google ADK. Apache-2.0. Version 2.0.0 landed on 19 May 2026. The interesting part is what happened to the old line: 1.x kept getting releases after 2.0 arrived, through v1.39.1 on 27 August 2026. That is the closest thing in this roster to an answer to “how long do I have”, and it is worth being careful about what kind of answer it is. I looked on google.github.io, on the adk-python repository, and on cloud.google.com for a published end-of-life or support policy for ADK 1.x, and did not find one. A 1.x-to-2.0 migration guide does exist, which is a different thing from a support policy. So what Google did across those months is observed behavior, and observed behavior can change without anyone going back on anything they said. The latest release is 2.9.1, from 15 September 2026, and that is what a fresh install resolves to.

One more thing, about finding your way around Google’s side of this. The address Google’s own documentation publishes for the Agent Engine overview served me a page titled Gemini Enterprise Agent Platform when I opened it on 15 September 2026. What it describes is a fully managed runtime, with guides for ADK, LangChain, LangGraph, AG2, LlamaIndex and custom agents, so it is not ADK-only. The title and the date are what I can give you. I am not going to read a rename into a page title.

Microsoft Agent Framework. Covered above, plus two things that belong here. Microsoft hit release candidate in February 2026 and, in its own words, “locked the feature surface and invited the community to put it through its paces” before 1.0 in April, which is a reasonable way to do it. And the framework ships first-party service connectors for Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama. The framework is Microsoft’s; the model choice reaches well outside Microsoft. The model provider is an obvious place to look for lock-in, and on this one it sits somewhere else.

Hyperscaler backing buys you the assumption that somebody is funded to keep working on it, and Strands and ADK are both Apache-2.0, so what has already been published stays available under those terms. Governance and a dated support window are separate questions, and they came back thin. Microsoft states a commitment to long-term support and attaches no dates to it. For Strands and for ADK 1.x I went looking and came back with nothing.

The volunteer fork

AG2. Apache-2.0, maintained by volunteers from several organizations, plus the namespace split described above. Volunteer maintenance cuts both ways: the people doing it are there because they want the project to exist, and they are doing it alongside whatever else they do. The Apache license means what has already shipped stays available under those terms. The ag2-classic split is what change looks like here, and it arrived the way most of this piece arrived: in a repository, on somebody else’s timing.

The ones that never published a 1.0

LlamaIndex is at v0.14.24, from 19 August 2026, MIT licensed. The OpenAI Agents SDK is at v0.22.2, from 9 September 2026, MIT licensed. Both are still on a 0.x version, and the semantic versioning specification is blunt about what that means: “Major version zero (0.y.z) is for initial development. Anything MAY change at any time.”

Now the honest counter, because that sentence on its own would be unfair. Plenty of 0.x software is stable in practice, and a version number is a poor verdict on quality. What the number does is decline to commit, and how much that matters depends on what else the project has told you, which is a separate thing to go and check. For LlamaIndex I checked the version and the license and looked no further, so the 0.x there is a question I would ask rather than an answer I have. For the Agents SDK I did check, and that is the next paragraph.

It is the sharpest single detail I found. OpenAI’s Swarm repository, titled “Swarm (experimental, educational)”, says Swarm “is now replaced by the OpenAI Agents SDK, which is a production-ready evolution of Swarm”, and recommends “migrating to the Agents SDK for all production use cases”. That SDK was at v0.22.2 on 9 September 2026, and when I read its README in September 2026 I found no stability, production-readiness, or support statement in it. The prose calls it production-ready. The version number declines to say so.

Here is the whole roster in one place, including what I went looking for and did not find.

What each project told me before I committed, read on its own repository, release metadata, package index, or engineering blog on 15 September 2026

Framework	License	Who steers it	Version I read	How the last major landed	What I looked for and did not find
Pydantic AI	MIT	Pydantic. PyPI maintainers dmontagu and samuelcolvin. Logfire is a commercial layer alongside it.	2.43.0, 12 Sep 2026	2.0.0 on 23 Jun 2026, after seven public betas, with an upgrade guide for the path from V1.	Not searched. I read the release notes and the upgrade guide.
LangGraph	MIT	LangChain, the PyPI maintainer of record. Commercial products sit alongside it.	1.2.11, 11 Aug 2026	1.0.0 on 17 Oct 2025. I did not read the release notes for that major.	Not searched. I read the PyPI release history.
CrewAI	MIT	crewAIInc, a company. The CrewAI AMP Suite is a commercial layer alongside it.	1.15.21, 9 Sep 2026	1.0.0 on 20 Oct 2025. I did not read the release notes for that major.	Not searched. I read the README and PyPI.
Strands Agents	Apache-2.0	The NOTICE file reads "Copyright Amazon.com, Inc. or its affiliates." Roadmap authority: see the last column.	1.55.1, 9 Sep 2026	I did not read the release history. What the repository publishes instead is team/COMPATIBILITY.md, which states in advance which changes are not considered breaking under semantic versioning.	Who holds final authority over the roadmap. Searched team/GOVERNANCE.md (404), TENETS.md, DECISIONS.md, the repository root, and the strands-agents organization profile.
Google ADK	Apache-2.0	Google. The repository is google/adk-python.	2.9.1, 15 Sep 2026	2.0.0 on 19 May 2026. The 1.x line kept shipping after it, through v1.39.1 on 27 Aug 2026.	A published end-of-life or support policy for 1.x. Searched google.github.io, the adk-python repository, and cloud.google.com. A migration guide does exist, which is a different thing.
Microsoft Agent Framework	MIT	Microsoft. The 1.0 announcement is on Microsoft's own engineering blog.	Python 1.18.0, 10 Sep 2026; .NET 1.21.0, 11 Sep 2026. It versions the two separately.	A release candidate in February 2026 with the feature surface locked, then 1.0 on 3 Apr 2026 with migration assistants for existing Semantic Kernel or AutoGen code.	A sunset date for Semantic Kernel or AutoGen. I read the 1.0 announcement in full and found neither in it.
AG2	Apache-2.0	"a dynamic group of volunteers from several organizations", per the README. Administrators Chi Wang and Qingyun Wu.	1.x, since the v1.0 in the next column.	v1.0 moved the autogen.* namespace, ConversableAgent and GroupChat, into a separate ag2-classic repository with its own docs site.	Not searched. I read the README.
LlamaIndex	MIT	The repository is run-llama/llama_index. I did not look past that.	0.14.24, 19 Aug 2026	No 1.0 in the release history I read. Still on 0.x.	Not searched. I read the version and the license and looked no further.
OpenAI Agents SDK	MIT	The repository is openai/openai-agents-python.	0.22.2, 9 Sep 2026	No 1.0 in the release history I read. Swarm's README says Swarm is replaced by this SDK, "a production-ready evolution of Swarm".	A stability, production-readiness, or support statement. I read the README and found none in it.

Where being on someone else’s schedule is the right trade

Everything above is an argument for knowing what you are holding. None of it is an argument against holding anything.

There is a large set of problems where being on someone else’s schedule is plainly the right call. Autoscaling, session and memory persistence, identity and auth, observability, long-running execution: the managed runtimes are mostly selling you the runtime rather than the agent, and most teams should not be building any of that. If your alternative to a managed runtime is three engineers writing a checkpointing layer, take the runtime and put those engineers on the agent. The realistic question is usually two questions stacked: which framework or raw loop do I write the agent in, and which managed runtime, if any, do I deploy it on.

The migration support is real too, and it deserves saying plainly rather than in passing. Microsoft locked its feature surface at release candidate in February and shipped 1.0 on 3 April, with tooling that reads existing Semantic Kernel or AutoGen code and produces a step-by-step plan. Pydantic AI ran seven betas before V2 and published an upgrade guide for the path from V1. Both of those are projects that said what was coming and then helped people get there.

Cloud gravity is a legitimate input as well. If your data, your identity layer, and your security review already live in one place, that is a real reason and not a lazy one. Just keep the agent itself portable, so the gravity stays a choice.

This piece is making a narrower argument than “frameworks are risky”. The question is what a buyer can find out in advance, and how much of it is findable before you commit rather than after.

If you adopt one, keep the loop legible

The first half of this post told you to treat the framework as a replaceable layer. The second half is the reason. In the roster above: a project moved into maintenance mode by README, a fork split its own namespace out into a second repository, major versions landed and earlier major lines were superseded, and two projects have never shipped a first major release at all. Each of those was findable in advance, by somebody willing to read a repository, its release metadata, a package index or an engineering blog. Where I went looking for an end date on the version being superseded, in Microsoft’s release announcement and on Google’s ADK pages, I did not find one.

So when you do cross the line and adopt something, wrap the loop rather than surrender it.

• Tools stay plain functions. A tool is a function with a schema. It should run, and be testable, with the framework removed. If your tools only make sense inside the framework, you have written business logic somewhere you cannot easily leave.
• Prompts stay version-controlled text. Not strings buried in framework config. They are the most important thing in the system, so treat them as reviewed assets.
• You can still trace a single turn. If you cannot follow one request through perceive, decide, act, and observe, the framework has hidden the one thing you most need when it goes wrong.
• Adopt the smallest piece that solves the named pain. Need durable state? Use the persistence layer. You do not have to buy the whole orchestration philosophy on day one.

Understand the loop well enough to name exactly what a framework would do for you before you reach for it. Then, when a pain is concrete and named, adopt the smallest thing that solves it. Ask who steers the project, what it did the last time it broke something, and where it would tell you if it broke something again. Then write your code so that the answer to the last question matters less than it otherwise would.

Most agents need no framework for a surprisingly long time. The ones that do need it for one or two reasons you can say out loud. And whichever way it goes, the cost of leaving is decided by how much of your code only makes sense inside somebody else’s abstractions. That number is yours. Nobody is going to send you a warning about it, and a year from now some of the paragraphs above will be out of date, which is the argument in a sentence.

If you are making this call on a system that is heading for production, working through it with someone from the outside is part of what I do. Details on agentic AI consulting.