Everyone Built Their AI Agents on Frameworks. Now They Are All Rebuilding From Scratch.

In 2024, if you were building an AI agent, you picked a framework.

The decision felt important. LangChain had momentum and ecosystem. LlamaIndex had better retrieval primitives. AutoGen promised multi-agent orchestration out of the box. Dozens of smaller contenders made compelling cases for their specific approach.

Teams evaluated, debated, prototyped, and chose.

Then they built. Fast. The frameworks made it possible to go from idea to working demo in days. The demos were impressive. The funding rounds followed. The production deployments followed the funding.

Now, eighteen months later, something is happening that nobody is writing press releases about.

The rebuilds are starting.

What the GitHub activity actually shows

You will not read about this in official announcements. Companies do not issue press releases saying “we spent eight months building on a framework that turned out to be wrong for us.”

But it is visible if you know where to look.

The questions appearing in developer communities right now are not “how do I build an agent with LangChain.” They are “how do I migrate off LangChain without breaking production.” They are “what does a framework-free agent architecture actually look like.” They are “we are hitting performance walls and the abstraction is preventing us from fixing them.”

The teams asking these questions are not small. They are teams that shipped real products, acquired real users, and are now facing the specific tax that every abstraction eventually collects: the moment where the framework’s opinions stop serving you and start constraining you.

That moment has arrived for a significant portion of the AI agent ecosystem, roughly simultaneously, because a significant portion of the AI agent ecosystem was built in the same eighteen month window on the same handful of frameworks.

The demo-to-production cliff

Every AI agent framework is excellent at one thing: getting to a demo quickly.

The chains are pre-built. The prompts are templated. The memory systems are wired up. The tool integrations exist. You assemble the components, run it, and something impressive happens.

The demo works.

Production is different from a demo in every way that matters.

In production, the failure modes are real. A component in the chain fails. The framework handles it in a way you did not choose and cannot easily change. You need to understand what happened. The abstraction that made the demo fast makes the debugging slow.

In production, the costs are real. Every layer of abstraction adds latency and token overhead. The framework is making API calls you did not explicitly request. The chain is including context you did not intend to include. The bill arrives and the line items do not map to anything in your mental model of the system.

In production, the scale is real. The framework’s default concurrency model does not match your traffic pattern. The caching assumptions are wrong for your use case. The retry logic conflicts with your upstream rate limits. The framework was not designed for your specific production constraints because it was designed for everyone, which means it was optimised for no one in particular.

The demo-to-production cliff is not unique to AI frameworks. Every layer of abstraction has it. The AI frameworks have it more severely because the underlying technology, the models, the APIs, the pricing, the capabilities, changed faster than the frameworks could track.

The abstraction that ate your observability

Here is the specific failure that is driving most of the rebuilds.

When something goes wrong in a framework-based agent, the error appears at the framework layer. Not at the model layer. Not at the tool layer. At the framework abstraction that sits between you and the actual thing that failed.

The stack trace shows framework internals. The logs show framework events. The debugging experience is learning how the framework works well enough to understand what it was doing when it failed, rather than understanding what your agent was doing when it failed.

These are not the same problem.

An engineer debugging a custom-built agent is debugging their own code. They made the decisions. They know why things are where they are. The failure is in their system and they can reason about it directly.

An engineer debugging a framework-based agent is debugging the framework’s interpretation of their intentions. They did not decide where the retry logic lives. They did not decide how context gets assembled. They did not decide the order in which components execute. The framework decided all of that, and now they are reverse-engineering those decisions at the worst possible moment.

The observability that teams built for traditional software, logging, tracing, metrics, all assumes you know what your system is doing. Framework-based agents break this assumption. The system is doing what the framework decided to do, which may or may not be what you intended.

The cost that compounds

Teams that built on frameworks in 2024 made a specific calculation.

Build time was cheap. Iteration speed mattered. The framework gave them speed and the speed was worth the cost.

This calculation was correct at the time.

It is less correct now. The cost that the calculation missed is not visible at launch. It accumulates.

Every engineer who joins the team and has to learn the framework before they can contribute. Every debugging session that takes three hours instead of thirty minutes because the abstraction hides the relevant information. Every optimisation that cannot be made because the framework does not expose the necessary control surface. Every production incident that takes longer to resolve because the team is reasoning about the framework’s behavior rather than their own code.

These costs are not dramatic. They do not show up in any single sprint. They are the overhead that runs quietly in the background of every engineering decision, every debugging session, every new feature, and every incident.

After eighteen months, the overhead is not background noise anymore.

It is the loudest thing in the room.

What the teams rebuilding are actually building

The teams that have decided to move away from frameworks are not building the same thing without the framework.

They are building something different in kind.

They are building systems where every decision is explicit. Where the context assembly is code they wrote. Where the retry logic is code they understand. Where the tool orchestration follows rules they can read and modify and reason about.

They are building systems that are observable in the same way their other production systems are observable. Where a log line means something specific that they chose. Where a metric tracks something they decided to measure.

They are building systems that are boring in the best sense. Not impressive in a demo. Understandable in an incident.

The code is more verbose. The initial build takes longer. The demo is less magical because there is no framework doing things in the background that look like magic until they break.

But the production behavior is predictable. The debugging is fast. The costs are attributable. The optimisations are possible because the control surface is fully exposed.

This is the same trade-off that engineering has always made between frameworks and custom builds. AI agents are not exempt from it. They just hit it faster, more visibly, and more expensively than most technologies, because the underlying capabilities were moving so fast that the frameworks could not keep up.

The frameworks are not going away

This is not an argument that frameworks are bad.

LangChain and its peers served a real purpose. They let a generation of developers explore what AI agents could do without needing to understand every layer of the stack. That exploration produced real learning. Some of it produced real products.

The frameworks will continue to exist and improve. For teams at the early exploration stage, for internal tools with low stakes, for proof of concepts, for teams that genuinely cannot staff the engineering investment that a custom build requires, frameworks remain the right call.

The argument is narrower than “frameworks are bad.”

The argument is that frameworks have a specific half-life in production AI systems. They accelerate the early phase and constrain the mature phase. The transition between those phases is arriving now for the cohort of teams that built in 2024.

The teams that understand this transition is coming can plan for it. They can build with frameworks where appropriate and design the escape hatches that make migration possible before it becomes urgent.

The teams that do not understand it will do what the current rebuild wave is doing: discover it under production pressure, rebuild under production pressure, and pay the cost of doing both at the same time.

The quiet advantage

The teams that built without frameworks from the start occupy an interesting position right now.

They were slower in 2024. Their demos were less impressive. They could not match the iteration speed of teams using pre-built abstractions.

In 2026, they are debugging production incidents in thirty minutes while their competitors spend three hours. They are making optimisations that are not possible inside a framework. They are onboarding new engineers faster because the codebase reflects decisions the team actually made.

They are not ahead because frameworks were a mistake.

They are ahead because they paid the cost of understanding upfront rather than deferring it to production.

That trade is always available.

It just rarely feels like the right one until the bill from the deferral arrives.

The bill is arriving now.