Agent Framework Churn Is Burning More Time Than It's Saving

I've rebuilt the same core agent loop — plan, call a tool, observe the result, decide whether to continue — in four different frameworks over two years. Each migration was pitched as the one that would finally give us better observability, or cleaner state management, or fewer footguns. Each one did, a little. None of them delivered enough improvement to justify the week of re-plumbing and the week after that of discovering the new framework's own footguns.

The treadmill is the product in this market

Every few months a new framework launches with a genuinely compelling demo and a changelog that makes the previous generation look primitive. Some of that is real progress. A lot of it is a crowded market where differentiation matters more than stability, and framework authors are incentivized to ship visible new abstractions faster than any single team can absorb them.

A framework migration that doesn't change what your agent can actually do for users is a cost with no corresponding revenue.

What finally made us stop

We did the math on the fourth migration honestly, instead of just trusting the pitch. Engineering time spent: roughly three weeks across two people. Measurable improvement in user-facing agent reliability: none we could point to in the eval metrics we were already tracking. The gains were all in developer experience — nicer debugging traces, cleaner code — which matters, but not three-weeks-of-two-engineers' worth of mattering.

• Before migrating, write down the specific production problem the new framework solves — not features, problems.
• If the current framework's core loop (plan, tool-call, observe, decide) already works, the churn is almost never worth it for marginal DX gains.
• Abstract your tool definitions and state management behind your own thin interface, so a future migration touches glue code, not business logic.
• Let frameworks mature for two or three release cycles before adopting — the early adopter tax is paid in your time, not theirs.

We're on our fifth framework pitch this quarter. I've told the team we're not doing it unless someone can name the production problem it solves that our current stack genuinely can't. So far nobody has. That silence is the most useful signal I've gotten out of any framework comparison in two years.