Insight · September 16, 2026
Choose the frame
you can leave.
An agent framework decides how much control you keep. Pick it for the parts you cannot add later, and for the exit when you outgrow it.
01 · The shift
The choice used to be cheap. Now it is a bet.
A year ago the framework you picked barely mattered. Every demo was a single agent calling a few tools, and you could rewrite it in an afternoon. The framework was a convenience, not a commitment.
That is over. As teams move from demos to production, the agent spends real money, touches real systems, and runs long enough to fail and recover. The framework now decides how the agent holds state, how a person steps in, and what you can see when it goes wrong. Rewriting it stops being an afternoon. It becomes a quarter.
02 · The problem
Most teams choose on the wrong axis.
The usual selection process is a feature table. Which framework has the most integrations, the biggest community, the cleanest hello world. So teams pick the one that is loudest that week, ship a prototype in days, and feel good about the speed.
Then the prototype meets production. The agent takes an action nobody wanted and there is no place a person could have stopped it. A run fails halfway and starts over from zero because nothing was saved. An answer is wrong and there is no trace to explain why. None of that showed up in the feature table, because the feature table measured the demo, not the job.
A framework is not a set of features. It is a set of decisions someone already made about how your agent thinks, holds state, and hands off. You are not buying capability. You are buying their opinion of control.
The one line to keep
“A framework is not a decision about features. It is a decision about how much control you hand away.”
03 · The landscape right now
Five names carry most of the weight.
01
LangGraph
A low level orchestration framework for long running, stateful agents. Its own words on the repository call it that. The draw is durable execution, checkpointing, and human oversight you can step into at any point. Teams like Klarna, Replit, and Elastic are listed among its production users.
02
CrewAI
A standalone Python framework with its own primitives, not a layer on LangChain. Role based crews for autonomous collaboration, event driven flows for precise control. The fastest way to stand up a multi agent prototype that reads like a team.
03
OpenAI Agents SDK
A lightweight set of primitives: agents, handoffs, guardrails, sessions, tracing. Released in March 2025 as the production successor to the experimental Swarm. Provider agnostic despite the name, with support for the OpenAI APIs and 100 plus other models.
04
Google ADK
A code first Python toolkit for building, evaluating, and deploying agents. The natural fit for teams already inside Google Cloud, Vertex AI, and Gemini, where the integration overhead other frameworks carry mostly disappears.
05
Microsoft Agent Framework
The unification of AutoGen and Semantic Kernel into one production framework across .NET, Python, and Go. It entered public preview on October 1, 2025. Both predecessors moved to maintenance mode, so a team on Azure now has one path forward instead of two.
This list is a snapshot, not a ranking. Any of the five can hold a production system. The differences that matter are not in the headline. They are in the four traits below.
04 · What actually matters
Four traits separate a demo from a system.
Observability. You cannot run an agent in production you cannot see. Traces, spans, and token accounting have to be first class, so that when a run misbehaves you can read what it did rather than guess. LangGraph leans on LangSmith for this. Others build it in or lean on open tracing. Either way, if you have to add visibility after the first incident, you added it too late.
Human handoff. Real work needs a place to pause for a person before the agent spends money, sends a message, or changes a record. The good frameworks treat this as a core primitive, not a workaround. If pausing for approval feels bolted on, the framework was built for the demo.
State and recovery. A production agent runs long enough to fail. It needs to save its place and resume from where it stopped, not start over. This is the difference between a system that survives a crash and one that loses an hour of work to it.
Cost. A framework that routes with a model call on every step spends more than one that follows explicit paths. Over a million runs that gap is a budget line, not a rounding error. Measure the cost of the framework itself, not just the model behind it.
05 · A test you can run before you commit
Four questions, asked out loud, before the first line.
The feature table cannot answer these. Only the shape of the job can. Write the answers down before you write any code, and the framework usually picks itself.
1. How many agents, really? One agent with tools is not a multi agent problem. Reach for the heavier framework only when the work is genuinely more than one worker. 2. Where does a person have to say yes? Name the exact points where the agent must pause for approval. If the framework makes those awkward, stop. 3. What happens when it dies mid run? If the answer is start over, you need state and checkpointing, not a prompt in a loop. 4. How do we leave? Before you commit, write down how portable the prompts, the tools, and the traces are the day you outgrow it.
A selection test · answer these before the feature table
06 · When to skip the framework
Sometimes the right framework is none.
A framework earns its cost when you have several agents, long running state, real handoffs, and a team that has to maintain all of it. Below that line, a framework can hide the very control you need.
For a single agent that calls a few tools and finishes in one pass, the plain model SDK plus a small loop of your own is often clearer, cheaper, and easier to debug. You can see every step because you wrote every step. No abstraction sits between you and the behavior when something breaks.
The mistake is reaching for the heaviest framework on day one because the roadmap says multi agent someday. Build for the job in front of you. Frameworks are easy to adopt when the shape of the work finally demands one, and painful to unwind when it never did.
07 · The exit test
Pick the one you can walk away from.
The landscape moves fast. The Microsoft Agent Framework folded AutoGen and Semantic Kernel into one path and sent both predecessors to maintenance mode. The OpenAI Agents SDK grew out of an experiment that OpenAI itself had labeled educational. What is current this year may be legacy the next.
That is the case for the exit test. The parts of your system that should outlive any framework are the prompts that hold your intent, the tools your agent can call, and the traces that record what happened. Open standards help here. When tools speak a shared protocol, moving them costs less. When your prompts live in your own files rather than buried in framework classes, they travel with you.
So choose for two horizons at once. The framework that fits the job today, and the one you can leave with your work intact tomorrow. A framework you cannot exit is not a tool. It is a landlord.
Closing
You are not choosing a library. You are choosing what you can change later.
Write the four questions on one page. Answer them for the job in front of you, not the roadmap. The framework that fits the answers, shows you what it does, and lets you leave is the right one. The loudest one rarely is.
Framework descriptions drawn from the official LangGraph, CrewAI, OpenAI Agents SDK, Google ADK, and Microsoft Agent Framework repositories · release and lineage facts confirmed against those projects, September 2026
Share this perspective
More insights
Adjacent perspectives.
Bttr. Field Brief
The brief Bttr. writes for senior buyers.
Monthly. One signal worth your time on Brand Operating Systems, AI search visibility, and the infrastructure buildout. No filler.