Count the agent frameworks announced in the last twelve months. LangGraph, CrewAI, AutoGen, Agno, LlamaIndex Workflows, Vercel AI SDK Agents, Pydantic AI, Semantic Kernel Agents, Amazon Bedrock Agents. Half of those had a breaking release in the same quarter. Three of them shipped, quietly deprecated, and shipped again under a new module path.
A framework is a bet — that the shape of your product is the shape everyone else is building. For most production AI work, that bet is wrong.
What frameworks actually give you
- A retry loop. Two lines around a try/catch.
- Tool routing. A switch statement over a name field.
- Token counting. Already in the SDK response.
- A planner pattern. Fifty lines of code you'll read once and never touch.
None of that is worthless. It's just not worth the framework's price of admission, which is a version-pinning treadmill and a set of abstractions written by someone who had never seen your product.
Our default: direct SDK, typed inputs, markdown outputs
Every MUCRIV agent — including the ones running our own company (see the Council) — is one function with the same shape: read inputs, call the model, write a file. Prompt bodies live in versioned markdown so a diff is a code review. Tool wiring is a hand-rolled dispatch table because there are five tools, not fifty.
When a framework upgrades its planner abstraction, our code doesn't move. When Anthropic ships a new SDK feature — prompt caching, extended thinking, tool_choice — we get it the same day the SDK does, not the same quarter the framework decides to expose it.
When a framework is the right answer
Two cases, in our experience:
- You are building an agent framework product. Then you need the ecosystem gravity, and picking one to extend is faster than inventing your own vocabulary.
- You have twenty-plus agents, dozens of tools, and multiple engineers rotating through the code. A shared abstraction pays for itself in onboarding cost.
If neither is you, the tax is real and the return isn't. Ship without.
What to read instead
The provider docs, in order of usefulness: the model's own tool-use guide, the SDK's streaming and structured-output pages, the pricing page. That's it. Everything else — orchestration patterns, memory strategies, RAG plumbing — is a decision your product should make from its own constraints, not inherit from a repo star count.