Why Agent Frameworks Cannot Win

In July 2023, I wrote this about LangChain:

My original LangChain post from July 16, 2023.

I had found LangChain useful for getting a prototype running, but every attempt to make the prototype behave exactly as I wanted required fighting abstractions I had not chosen. The framework encoded a particular way to build with language models at a time when nobody, including the framework authors, knew what the durable patterns would be.

Three years later, the strongest confirmation comes from LangChain itself.

What happened to LangChain

LangChain did not fail as a project or a company. As I write this, its Python repository has more than 143,000 GitHub stars. The company raised $125 million at a $1.25 billion valuation in October 2025, and its commercial platform processes a large and growing volume of production agent traces.

The original abstraction did not survive intact, though.

In his three-year retrospective, founder Harrison Chase describes the early library as a collection of integrations and high-level templates for RAG, extraction, and question answering. He also describes what happened when people tried to take those templates into production: the interfaces that made LangChain easy to start with got in the way when developers needed control.

LangGraph was built in response. It moved down the stack and gave developers explicit control over prompts, state, branching, streaming, human approval, and durable execution. LangChain later summarized the lesson even more directly: high-level abstractions helped people get started, while lower-level flexibility handled production requirements.

Then LangChain 1.0 substantially narrowed the original library. Its own history of the project says that all of the old chains and agents were replaced with one agent abstraction built on LangGraph. The previous APIs moved into a package named langchain-classic.

The commercial product also moved toward less opinionated ground. LangSmith provides tracing, evaluation, and deployment, and it works whether an application uses LangChain or another framework. Those are useful capabilities precisely because they do not need to decide how an agent should think.

The company adapted well by retiring much of its original conceptual layer and investing in runtime infrastructure around the model. This is good product strategy, and it also supports the concern I had in 2023. The high-level framework was excellent at packaging the current set of ideas, but the ideas changed too quickly to remain a foundation.

Frameworks work when the thing underneath them is stable

A conventional framework compresses a large amount of settled knowledge. A web framework can assume that an HTTP request has a method, headers, and a body. A database library can assume that transactions and indexes will continue to exist. The framework may evolve, but the concepts underneath it move slowly enough for useful abstractions to harden.

An agent framework sits on a different kind of boundary. It tries to standardize both a changing interface and a changing set of capabilities.

In 2023, frameworks had to implement tool use with prompts, parse model output, manage conversation history, assemble retrieval pipelines, and invent agent loops. Model providers have since absorbed much of that work into their APIs. OpenAI’s Responses API now includes hosted tools, multi-turn state, and remote MCP support. Its Agents SDK intentionally advertises very few abstractions around the loop. Anthropic gives similar advice in its guide to building effective agents: start with direct model APIs, because frameworks can hide prompts and responses and make debugging harder.

The same change happens with model capability. A workflow that needed several carefully arranged calls can collapse into one call when a better model arrives. A retry or routing strategy that helped one generation of models can make the next generation slower or less accurate. An abstraction intended to preserve a best practice can quietly preserve an obsolete workaround.

This leaves a generic framework with three choices:

• It can wait for provider features to settle, which makes it lag behind the APIs it wraps.
• It can expose only the features providers share, which produces the lowest common denominator.
• It can add provider-specific options and raw escape hatches, which asks developers to understand both the framework and the provider underneath it.

All three can be reasonable engineering decisions. None produces the stable, universal layer that the word framework implies.

Vercel’s AI SDK is running into the same pressure

In January 2026, I made the same argument about Vercel’s AI SDK:

My AI SDK post from January 3, 2026.

Vercel built AI SDK and made it successful by marketing its library to developers who do not yet know what the abstraction will cost them. It appears throughout Vercel’s templates, documentation, and examples as the obvious way to add AI to a TypeScript application. The SDK’s global provider defaults to Vercel AI Gateway, and the easiest path offers automatic authentication and Vercel dashboard observability when the application is deployed on Vercel. By the time developers discover which provider-specific capabilities they gave up, their prompts, messages, streaming code, and UI are already expressed in AI SDK’s types. The library can run elsewhere and can call providers directly, but its defaults steadily pull an application into the rest of Vercel’s stack. Its adoption is evidence of Vercel’s marketing and distribution, not the quality of the abstraction.

Its evolution shows the cost of trying to normalize this layer. AI SDK 5 completely redesigned the streaming architecture, changed the UI message model, and required a separate migration path for persisted messages. AI SDK 6 introduced a reusable Agent abstraction in December 2025. Six months later, AI SDK 7 expanded into an agent platform with durable execution, sandboxes, harness adapters, observability, realtime sessions, and a migration skill that developers can give to their coding agent.

Prompt caching is a good example of what the normalization takes away. With Anthropic, cache boundaries affect prompt structure, latency, and cost. AI SDK cannot represent that behavior through its common interface. Its own documentation tells developers to attach providerOptions.anthropic.cacheControl to individual messages or content blocks, then read Anthropic-specific cache statistics from providerMetadata.anthropic. The UIMessage type used by its UI hooks does not support these provider options, so messages have to be converted before the options can be applied.

A good abstraction gives callers a smaller, stable interface and lets them forget the internals. This one requires the caller to understand Anthropic’s caching semantics, AI SDK’s message model, and how AI SDK translates one into the other. The application is now coupled to both layers instead of one. Switching providers does not make the caching logic portable; it makes the logic meaningless.

The escape hatch keeps the library usable, but it defeats the purpose of the abstraction. When an abstraction has to expose configuration for the internals it claims to hide, it has failed to establish a real boundary. The developer pays the cost of learning the framework and still has to learn every provider underneath it.

If choosing among many models is the product, that translation layer may earn its complexity. For most products, provider-specific capabilities matter more than theoretical portability. A thin adapter around the native provider SDK preserves those capabilities, avoids the extra dependency, and remains easier to replace because the application owns the boundary.

Production pushes from the other direction

Provider APIs squeeze frameworks from below by absorbing their common features. Production requirements squeeze them from above.

Agent demos look similar. Give a model instructions and tools, keep calling it until it stops, then show the result. This common shape makes a generic abstraction feel natural.

Production systems diverge around everything the demo leaves out. They have different permission boundaries, latency budgets, retry rules, approval steps, data retention policies, failure costs, audit requirements, and definitions of success. The important behavior moves into the details.

A customer support agent may need to prove that a refund was actually recorded before telling a customer it succeeded. A coding agent needs filesystem isolation, command approval, test evidence, and a way to recover from a process crash. A research agent needs source quality rules and an evaluation system that can distinguish a well-supported answer from a plausible one. These requirements cannot be inferred from a generic Agent class.

When a framework hides these details, teams eventually fight it. When it exposes all of them, it becomes a runtime and a collection of utilities. The lower layer is less exciting, but it is also more durable because state persistence, tracing, queues, permissions, and sandboxing have concrete contracts.

OpenClaw shows why agent opinions do not generalize

OpenClaw is the clearest current example of how large the appetite has become. The project was created in late 2025 and has accumulated more than 385,000 GitHub stars in under a year. People clearly want a personal agent that can live in their messaging apps, remember context, use their computer, and keep working after they close the chat.

There is nothing wrong with OpenClaw making hard choices for that product. Its Gateway connects to messaging apps and remote devices while owning sessions, queues, authentication, pairing, persistence, and delivery. Its runtime owns the model loop too. Those opinions are part of what makes OpenClaw usable as OpenClaw.

The mistake would be treating those product decisions as a general agent abstraction. Agent development is still a wild west. Models, provider APIs, memory strategies, tool protocols, permission boundaries, deployment patterns, and human approval flows are all changing at once. Nobody has found one architecture that works equally well for a personal assistant, customer-support agent, coding agent, and research agent.

OpenClaw’s choices can be right for OpenClaw and painful when inherited by another product. Adopting its channel model, session model, memory, permissions, plugin system, and deployment shape means building inside someone else’s assumptions. As soon as the product needs something different, the abstraction becomes work that has to be undone.

Its security documentation shows how specific these choices become. Plugins run as trusted code. A paired node can allow remote command execution. Multiple users with access to one tool-enabled agent share its delegated authority. Every agent product needs answers to these questions, but it cannot safely inherit the same answers.

OpenClaw is useful as a product and as a toy for exploring what personal agents might become. Its popularity proves that people want the outcome. It does not prove that its internal architecture, or any current agent architecture, can serve as a durable framework for everyone else.

The primitives work. The wiring does not generalize

Some parts of agent software are already well understood. Stream tokens as the model generates them instead of waiting for the entire response. Define tool inputs and outputs with schemas. Store messages and application state outside the model. Record traces. Require approval before dangerous actions. Run code in a sandbox.

None of these choices tells us how to build an agent. We still have to decide what enters the context, when the model runs again, which tools it can see, what requires approval, how work resumes after a failure, and when the loop stops.

A coding agent, personal assistant, customer-support agent, and research agent can use the same primitives and connect them in completely different ways. That wiring depends on the product, its users, its risks, and the models and providers it uses.

This is the part frameworks are trying to generalize too early. They give us someone else’s way of connecting the pieces. It feels convenient while our product matches their assumptions. When it stops matching, we have to understand and undo their architecture before we can build our own.

Streaming is a useful primitive. A universal streaming abstraction over every provider is a different claim. Tracing is a useful primitive. A framework deciding the agent loop is a different claim. OpenClaw’s wiring can be right for OpenClaw without being right for another agent.

How I build with agents now

I start with the provider’s API and keep the loop small. Tools remain ordinary functions with schemas I own. Prompts and message history stay visible. Application state is stored in a format that does not depend on a framework’s internal message classes.

Supporting libraries should have narrow jobs. A stream renderer can render a stream. A tracing client can record a trace. Neither should own my prompts, messages, application state, or agent loop.

Frameworks are still good at getting a prototype running. That was true of LangChain in 2023 and it is true of agent frameworks now. The risk begins when the convenience of the prototype quietly becomes the architecture of the production system.

The appetite for useful AI products will keep pulling new frameworks into popularity. Most will look better than they are because demand is so much larger than the available supply. Some of the companies will adapt and win, but they will do it by moving down into infrastructure or up into a specific product. The generic, opinionated layer in the middle has nowhere stable to stand.