The Case Against Building Your Own Agent Framework, and the 3 Tests For It

Anthropic retired 9 Claude model IDs in the 12 months to August 2026. The Model Context Protocol replaced its stateful core with a stateless one in July. Every one of those changes lands on whoever owns the agent framework, and if you built your own, that is you. Building one is sometimes correct. It is correct far less often than it feels at the whiteboard.

The short answer

Most teams should not build their own agent framework. The provider SDKs now ship the agent loop, tool dispatch, sessions, permissions and MCP support that a custom layer would reproduce. Build your own only when the loop itself is the product, a hard constraint blocks every SDK, or your volume already pays for a maintainer.

What "building your own agent framework" actually means

The phrase covers two very different decisions, and teams conflate them constantly. One is writing a thin function that calls a model API. The other is owning an agent loop.

The first is not a framework. It is 40 lines of code and it is usually the right answer. The second is a piece of infrastructure with a lifecycle, and it is what this post argues against.

The six layers you would be taking on

An agent framework is not one thing. It is a stack of six responsibilities, each of which fails differently in production.

Model transport sits at the bottom: authentication, streaming, retries, rate limit backoff, and the handling of partial responses. Above it sits tool definition and dispatch, which converts your functions into schemas the model can call and routes the results back. Then comes conversation state, including the compaction strategy that decides what gets dropped when a session outgrows the context window.

The top three layers are the ones people underestimate. Permission gating decides which tool calls run without a human. Observability turns a run into something you can read afterwards. Evaluation tells you whether a prompt change made the system better or worse, and that is a separate build again, described in the case for building an evaluation suite before you need one.

Where the line actually sits

Here is the test I use. If you can delete your orchestration code and swap in a provider SDK over a weekend, you have a wrapper. If that migration is a quarter of work, you have a framework, and you own it.

Most teams cross that line without a decision meeting. It happens through accretion: a retry helper, then a tool registry, then a state store, then a custom transport. Nobody ever proposed building a framework. One exists anyway.

The provider SDKs already ship most of that list

The build case was stronger in 2024, when the vendor offerings were thin. That is no longer the situation, and the argument has not caught up with the tooling.

What the Claude Agent SDK documents today

Anthropic's Agent SDK overview describes the library as giving you "the same tools, agent loop, and context management that power Claude Code." Its capability table lists built-in tools, hooks at lifecycle points, subagents for focused subtasks, MCP connectivity, per-tool permissions, sessions you can resume or fork, and plugins.

Read that list against the six layers above. Five of the six are covered by something the vendor maintains, tests and versions.

What the OpenAI Agents SDK documents today

OpenAI describes its SDK as having "a very small set of primitives": agents, handoffs and guardrails. Around those sit sessions as "a persistent memory layer for maintaining working context", tracing for debugging and monitoring runs, built-in MCP server tool calling, human-in-the-loop mechanisms, and function tools with automatic schema generation.

The two SDKs are not identical, and that difference is the interesting part. Neither covers every row on its own.

Your maintenance calendar is written by someone else

The seductive part of a custom framework is that the first version works. It is small, it fits your mental model, and it does exactly what you need. The bill arrives later, and it arrives on a schedule you do not set.

Nine model IDs retired in twelve months

Anthropic's model deprecations page is the clearest public record of that cadence. Between 28 October 2025 and 5 August 2026 it shows 9 model IDs moved to retired across 6 separate dates. Requests to a retired model fail outright.

The company commits to "at least 60 days' notice before model retirement for publicly released models." That is a reasonable policy and it is also the shape of your calendar. Six times a year, something you pinned stops existing.

Parameters get deprecated too, not only models

Model names are the easy case, because a string swap is cheap. The harder breaks are structural.

Anthropic's own documentation records that temperature, top_p and top_k now return a 400 error when set to a non-default value on Claude Opus 4.7 and later. The Python SDK from v1.0 removes those parameters entirely, so passing them raises a TypeError rather than failing at the API. A custom framework that exposes a generic sampling config to its callers has to absorb that difference across every provider it supports.

None of this is unreasonable behaviour by the vendor. It is the ongoing cost of the abstraction you chose to own, and it never appears in the original build estimate.

What that upkeep costs in the only unit that matters

Frameworks are paid for in engineer time. The US Bureau of Labor Statistics puts the median annual wage for software developers at $133,080 as of May 2024, wage only, before employer taxes and benefits.

Assume one engineer spends a fifth of the year keeping a custom framework current. That is roughly $26,600 of wage cost a year, plus whatever else that person would have shipped. The one-fifth figure is my assumption and not a measured number, so treat the arithmetic as a way to frame the question rather than as evidence. The point survives any input you prefer: the cost is recurring, and the build estimate treated it as zero.

The standard moved under everyone in July 2026

The strongest recent argument against owning this layer is not about models at all. It is about the protocol underneath the tools.

The MCP specification revision dated 28 July 2026 did something unusual for a widely adopted standard. It replaced the stateful, bidirectional protocol with a stateless request and response architecture. Handshake and session requirements were eliminated. Method and tool names moved into HTTP headers, so gateways can route without parsing JSON. Dynamic client registration was deprecated in favour of client ID metadata documents.

The revision also introduced a twelve-month minimum window for future breaking changes, which is a sign of a standard maturing rather than one thrashing. The maintainers report close to half a billion SDK downloads a month, with four tier-one SDKs updated alongside the spec.

Now ask the operational question. If you wrote your own MCP client, that rewrite is your sprint. If you use a vendor SDK, it is a version bump, done by people whose full-time job is tracking the protocol. What the standard did and did not settle is covered in the piece on MCP as an interoperability standard, and the risk of pulling in third-party servers is in the analysis of MCP server supply chain exposure.

Every row is drawn from the vendor's or maintainer's own published notes. This is ten months, not a decade, and it excludes anything the other model providers changed in the same window.

Where this argument is weakest

A post arguing against custom infrastructure has an obvious bias, so here is the strongest version of the other side.

Anthropic's own guidance cuts both ways

The most cited piece of framework scepticism was published by a model provider. Anthropic's Building effective agents, from December 2024, recommends that "developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code." It warns that frameworks "often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug". The same page adds that "incorrect assumptions about what's under the hood are a common source of customer error."

Read carefully, that is an argument against abstraction, not against third-party abstraction. Your homegrown framework obscures prompts exactly as effectively as somebody else's. The guidance points at direct API calls, which is a third option most build-versus-buy debates skip entirely.

LangChain 1.0 weakened the churn argument

The best reason to distrust open-source agent frameworks used to be version instability. That reason is thinner than it was. LangChain and LangGraph reached 1.0 on 22 October 2025 with an explicit commitment to "no breaking changes until 2.0", against a reported 90 million monthly downloads.

The published release policy backs it up. Breaking changes are reserved for major versions, deprecated LangChain features keep working "throughout the entire 1.x release series", and LangGraph spaces major releases 6 to 12 months apart. If you rejected these tools in 2024 on stability grounds, that rejection is now out of date and worth revisiting.

Portability is the real cost of the SDK route, and it is not free. Committing to a vendor SDK means the switching cost of changing model provider sits inside your application rather than behind an interface you control. Teams that genuinely route across providers, for pricing or for redundancy, are paying for something real. Whether they get it depends on how far the providers' terms and behaviour actually diverge, which is examined in the comparison of what the model providers commit to in writing.

Three tests that justify building your own

A slogan is useless here. What follows is a rule you can apply in a meeting, and it fails a custom framework unless all three clear.

Test one: is the loop itself the product? Ask whether a customer would notice if you swapped the orchestration layer overnight. If you sell control over planning, routing or tool arbitration, the loop is your differentiation and outsourcing it is strange. If your customer buys an outcome and never sees the loop, you are maintaining plumbing.

Test two: can you name the constraint and the line that fails it? "We need more control" is not a constraint. An air-gapped runtime, a language with no maintained SDK, or an audit format a regulator specified are constraints. If nobody can point at the specific documented behaviour that blocks you, the requirement is a preference.

Test three: does your volume already pay for a maintainer? A framework needs a named owner, not a founding author. If a 60-day model retirement notice is a scheduled task on somebody's board, you can carry this. If the answer is that whoever wrote it will look at it, you have built an orphan.

The final row is the part that gets argued with. Requiring all three is deliberate, because two out of three is how most orphaned internal platforms were approved.

What production teams actually struggle with

The framework debate absorbs a disproportionate share of engineering attention. The survey evidence suggests it is not where the difficulty lives.

LangChain's State of Agent Engineering collected 1,340 responses between 18 November and 2 December 2025. Among them, 57.3% had agents in production and a further 30.4% were developing with concrete deployment plans. The top blocker was quality at 33%, ahead of latency at 20%. Security led only among organisations above 2,000 staff, at 24.9%.

The observability numbers say something sharper. 89% of respondents had implemented observability, rising to 94% among teams in production, but only 52.4% ran offline evaluations and 37.3% ran online ones. Teams are watching their agents closely and grading them loosely. That gap, not the choice of orchestration library, is what separates a demo from a system, and it is the same gap described in the production readiness tests a pilot has to pass.

There is a related trap on the other side of the decision. Buying does not mean buying anything with the word agent on it. Gartner's June 2025 forecast holds that more than 40% of agentic AI projects will be cancelled by the end of 2027. It names escalating costs, unclear business value and inadequate risk controls, with senior director analyst Anushree Verma describing most current projects as early stage experiments driven by hype.

Frequently asked questions

Where to start this week

Two things, and the first one takes an hour.

Open your agent code and count how many of the six layers you own outright: transport, tool dispatch, state and compaction, permissions, observability, evaluation. Then open your chosen provider's SDK capability page and mark which of those it already documents. Most teams discover they are maintaining four layers to get one they actually needed.

Second, put the deprecation pages of every model provider you use on a calendar reminder, once a quarter. Nine retirements in ten months from one vendor is the baseline you are planning around, and the teams that get surprised are the ones who never wrote the date down. If you are still choosing between building on top and buying outright, the same arithmetic applied to a narrower case sits in the build-versus-buy breakdown for coding agents.

Related reading