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.

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.

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.

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.

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.

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.

Written by · September 16, 2026

Donny Smith · ECD, Founder, Bttr.

Over the past 15 years, he has led creative teams and contributed to products used by millions of people worldwide, working with companies including Apple, Opendoor, JP Morgan, GE Aerospace, Pepsi, and Alterra Mountain Company.

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.

8 min read

How to Evaluate a RAG System

Evaluating a RAG system means scoring its two stages on their own, because a retrieval augmented generation answer is only as good as the passages behind it, and a wrong answer has two possible causes a single number cannot tell apart. Retrieval is measured before the model writes anything. The LlamaIndex evaluation guide scores a retriever with hit rate, the share of questions where the right passage lands in the top results, and mean reciprocal rank, which rewards ranking it high. Generation is measured given what was retrieved. Ragas, the open evaluation toolkit now maintained by VibrantLabs, splits the answer into claims and scores faithfulness as the share the retrieved context supports, then scores answer relevance by generating questions from the answer and comparing them to the real one. Read as two pairs, the four metrics locate the fault: high recall with low faithfulness is a generation problem, low recall with high faithfulness is a retrieval one. Anthropic showed the payoff in September 2024, cutting a retrieval failure rate measured by recall at 20 from 5.7 percent to 1.9 percent by adding context, keyword search, and reranking. And it is not a one time check. Models drift, documents go stale, so the teams that trust their systems run these scores on live traffic the way they run unit tests.

8 min read

What Is a Reasoning Model

A reasoning model is a large language model trained to work through a problem in steps before it answers, rather than reply in one pass. It spends extra computation at the moment you ask, called test-time compute, to write out a chain of thought and check its own work. Anthropic describes its extended thinking as letting the very same model give itself more time and effort rather than switching to a separate model, and reported that Claude 3.7 Sonnet reached 84.8% on the hard GPQA science set, with a 96.5% physics subscore, using parallel sampling at a 64K token thinking budget. The habit is trained, mostly by reward. DeepSeek showed in January 2025 that its R1 Zero model learned to reason purely through reinforcement learning with no supervised fine-tuning first, developing self checking and long chains of thought on its own, and shipped DeepSeek R1 under the MIT license at performance comparable to OpenAI o1. The cost is real, so the newest models add a dial. Claude Opus 4.5 hit its best score on SWE-bench Verified using 76% fewer output tokens at a medium effort. The skill is matching how hard the model thinks to how hard the task is.

8 min read

What Is Fine-Tuning

Fine-tuning is training a pre-trained model further on your own labeled examples so a behavior is set into its weights. It changes how a model acts, its tone, its format, its grip on a narrow task, rather than what facts it knows. Google frames the move as taking a general-purpose model and adapting it to your domain on a curated dataset of your own examples. The gains are measurable. When Anthropic opened fine-tuning for Claude 3 Haiku in Amazon Bedrock, a team fine-tuned it to moderate comments and lifted classification accuracy from 81.5% to 99.6% while cutting tokens per query by 85%. Lighter methods such as LoRA keep the base model frozen and train a small set of new weights beside it. The order that saves money is a plain prompt first, retrieval when the model lacks facts, fine-tuning only when it lacks the right behavior. A fact that changes is a retrieval problem. A behavior that drifts is a training problem.

View all insights →

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.

Build for production, not the demo

Choose the frame
you can leave.

The choice used to be cheap. Now it is a bet.

Most teams choose on the wrong axis.