The Vibe Father
Between April and July 2026 the agent framework ecosystem shipped more than in any comparable window since these tools existed — and the most useful consequence for people building things is that the choice finally stopped being arbitrary.
Microsoft merged Semantic Kernel and AutoGen into Microsoft Agent Framework 1.0. Anthropic added hierarchical subagent spawning to the Claude Agent SDK. CrewAI 1.14 introduced pluggable memory, knowledge and RAG backends. Pydantic AI V2 and LlamaIndex Workflows 1.0 both went stable within the same 48 hours in late June.
Here is what actually changed, how to choose, and the architectural advice that matters more than the choice. Companion piece the MCP 2026-07-28 spec, which affects all of them.
What shipped
| Framework | What changed | Signal |
|---|---|---|
| Microsoft Agent Framework 1.0 | Semantic Kernel and AutoGen merged | Consolidation — two ecosystems became one |
| Claude Agent SDK | Hierarchical subagent spawning | Delegation as a first-class primitive |
| CrewAI 1.14 | Pluggable memory / knowledge / RAG backends | Maturing — swap infrastructure, keep the model |
| Pydantic AI V2 | Stable release | Type-safety-first agents grew up |
| LlamaIndex Workflows 1.0 | Stable release | Retrieval-heavy orchestration settled |
The Microsoft merge is the most strategically interesting. Semantic Kernel and AutoGen solved overlapping problems with different philosophies, and maintaining both split the community. Merging them is an admission that the experimentation phase is over — which is generally what happens right before a category becomes boring and useful.
Two stable 1.0/V2 releases inside 48 hours is not coincidence either. Frameworks stabilise when the underlying primitives stop moving, and the primitives stopped moving because MCP won the tool-calling argument.
MCP changed the framework question
The most important thing to understand about choosing a framework in 2026 is that the decision matters less than it used to, because the expensive part has been standardised.
Production agents are increasingly not written against proprietary tool-calling interfaces. They are written against MCP. That means your tools — the genuinely valuable, hard-won integration work — are portable across frameworks in a way they simply were not two years ago.
| Before MCP consolidation | Now | |
|---|---|---|
| Tool integrations | Rewritten per framework | Written once, reused |
| Switching cost | High — tools were the work | Moderate — orchestration only |
| Framework lock-in | Real | Much weaker |
| What to optimise for | Ecosystem size | Fit with your language and ops |
The practical implication, stop agonising. Pick the framework that fits your language, your team and your deployment story, and accept that switching later costs you orchestration code rather than your entire tool layer.
Choosing by shape of work
| If you are building | Look at | Because |
|---|---|---|
| A coding agent on Claude models | Claude Agent SDK | Hierarchical subagents, closest to the model's behaviour |
| Enterprise.NET or Azure-centric systems | Microsoft Agent Framework | One consolidated stack, enterprise integration |
| Retrieval-heavy pipelines | LlamaIndex Workflows | Retrieval is the core competency |
| Type-safe Python services | Pydantic AI | Validation and typing as first-class |
| Role-based multi-agent crews | CrewAI | Pluggable backends, role abstractions |
| Complex branching state machines | LangGraph | Explicit graph control flow |
| Something simple | No framework | A loop and an MCP client is often enough |
That last row is not a joke. A large share of production agents are a while-loop, a model call, a tool dispatcher and a stopping condition. If that describes your use case, a framework adds concepts to learn and a dependency to upgrade in exchange for very little.
Reach for a framework when you need something it genuinely provides, durable execution across restarts, complex branching, multi-agent coordination, or built-in observability you would otherwise build.
Hierarchical subagents, and when they help
The Claude Agent SDK's hierarchical subagent spawning reflects a broader shift, delegation is becoming a primitive rather than something you hand-roll.
The pattern is a parent agent decomposing a task and spawning children with narrower scope, each with its own context. For coding work the appeal is obvious — a parent plans a migration, children each handle a module, and no single context has to hold the entire repository.
| Subagents help when | Subagents hurt when |
|---|---|
| Work decomposes cleanly | Subtasks are tightly coupled |
| Each part needs different context | Everything needs the same context anyway |
| Parts can run in parallel | Order matters throughout |
| Context would otherwise overflow | The task fits comfortably in one window |
| Failures should be isolated | You need one coherent transaction |
The cost is real and under-discussed, every subagent is a fresh context that must be briefed, and briefing costs tokens. Decomposing a task that fits in a single context makes it slower and more expensive with no quality gain. Use hierarchy when the work is genuinely separable, not because the framework offers it.
Observability is the other reason to adopt
When an agent produces a wrong answer, the answer itself tells you almost nothing. What you need is the sequence, which tools were called, with what arguments, what came back, and where the reasoning turned. Reconstructing that from application logs after the fact is miserable.
Frameworks that ship step-level tracing give you that for free, and it compounds with every additional step in a run. A single-call agent barely needs it, a twelve-step agent with three subagents is effectively undebuggable without it. If you are weighing frameworks and cannot decide, trace quality is a better tiebreaker than feature count.
The architecture advice that outlives the framework
Whatever you pick, these determine whether your agent works in production.
- A verifiable definition of done. A failing test the agent must make pass beats three paragraphs of description. Persistent models will work indefinitely against a vague goal.
- A token ceiling per task. The only hard stop on a self-retrying loop.
- A wall-clock timeout. A persistent model will use every second you give it.
- Bounded file and tool scope. Agents sprawl beyond the ticket unless told not to.
- Summarised tool output. Raw logs entering context are the quietest budget leak in agent stacks.
- Human gates on destructive actions. Deploys, migrations, deletions.
- Trace-level observability. When an agent goes wrong you need the sequence, not the final answer.
Item seven is where frameworks earn their keep. Rolling your own tracing across a multi-step agent is more work than it looks, and debugging a failed run without it is close to impossible.
Durable execution is the feature worth paying for
If there is one capability that justifies adopting a framework rather than writing a loop, it is durable execution — the ability for an agent run to survive a process restart and resume rather than starting over.
| Without durability | With durability |
|---|---|
| Deploy kills in-flight runs | Runs resume after restart |
| A crash loses an hour of work | Work resumes from the last checkpoint |
| Long tasks are risky | Long tasks are routine |
| Retries restart from zero | Retries resume from the failure |
This matters more as tasks get longer. A thirty-second agent run that dies is an annoyance, a forty-minute migration that dies at minute thirty-five and restarts from zero is a genuine cost, in tokens and in wall-clock. Once your agents routinely run longer than your deploy cadence, durability stops being a nice-to-have.
It pairs naturally with the MCP Tasks extension, a protocol-level primitive for long-running work plus framework-level durable execution is what makes genuinely long agent runs operationally sane rather than something you babysit.
Build or adopt?
A short decision aid, because this is the question behind the framework comparison.
| Need | Build it | Adopt a framework |
|---|---|---|
| Model call plus tool dispatch | ✓ — an afternoon | Overkill |
| Retry with backoff | ✓ | Overkill |
| Structured output validation | ✓ or a small library | Reasonable |
| Durable execution across restarts | Expensive to get right | ✓ |
| Distributed tracing across steps | Expensive to get right | ✓ |
| Complex branching state machines | Becomes a framework eventually | ✓ |
| Multi-agent coordination | Genuinely hard | ✓ |
| Human-in-the-loop approval gates | Straightforward | Either |
| Evaluation and replay tooling | Time-consuming | ✓ |
The honest pattern is that teams who build first and adopt later usually end up happier than teams who adopt first. Building the simple version teaches you what you actually need, so when you do reach for a framework you can evaluate it against real requirements instead of a feature list.
The multi-agent question
Multi-agent systems are the most over-applied pattern in this space. The pitch — specialised agents collaborating like a team — is appealing and frequently produces something slower, more expensive and harder to debug than one well-prompted agent with good tools.
| Reason given | Usually valid? |
|---|---|
| Context would overflow otherwise | Yes — the strongest reason |
| Genuinely parallel independent work | Yes |
| Different tasks need different tools or permissions | Yes |
| Isolating failure blast radius | Yes |
| "Specialists produce better output" | Rarely — usually prompt quality in disguise |
| "It mirrors how human teams work" | No — an analogy, not an argument |
Start with one agent. Add a second when you can name the specific constraint forcing it. Every additional agent is another context to brief, another failure mode, and another thing to trace.
Watch the MCP revision when you choose
One timing note that cuts across every option here. The 2026-07-28 MCP specification removes protocol-level sessions and makes the transport stateless, and frameworks are shipping support against the beta SDKs at different speeds.
If you are choosing a framework this month, check where your candidate stands on that revision. A framework that has already adapted saves you a migration you would otherwise inherit, one that has not is a schedule risk rather than a disqualification, given the twelve-month deprecation guarantee. Either way it is a question worth asking before you commit, not after.
Common questions
Which AI agent framework should I use in 2026?
Whichever fits your language and deployment story. Because tools are increasingly written against MCP rather than proprietary interfaces, switching costs are much lower than they were, so this is no longer a decision worth agonising over.
Do I need a framework at all?
Often not. A loop, a model call, an MCP client and a stopping condition covers many production agents. Add a framework when you need durable execution, complex branching, multi-agent coordination or built-in tracing.
What changed with Microsoft Agent Framework 1.0?
Semantic Kernel and AutoGen merged into a single stack, consolidating two overlapping ecosystems.
Are multi-agent systems worth it?
Only when a specific constraint forces it — context limits, genuine parallelism, differing tool permissions, or failure isolation. "Specialists are better" is usually prompt quality in disguise.
What are hierarchical subagents good for?
Decomposing work that genuinely separates, where each part needs different context. They cost tokens to brief, so decomposing something that fits in one context makes it worse.
How hard is it to switch frameworks now?
Much easier than it was. Because tools are increasingly written against MCP rather than a framework's proprietary interface, switching costs you orchestration code rather than your entire integration layer — which is where the real work always was.
What is durable execution and do I need it?
The ability for a run to survive a process restart and resume rather than starting over. You need it once your agent runs routinely last longer than your deploy cadence, because otherwise every deployment silently destroys in-flight work.
Should I build my own agent loop first?
Often yes. Building the simple version — model call, tool dispatch, stopping condition — teaches you which requirements you actually have, so you can evaluate frameworks against real needs rather than a feature list. Teams that build first and adopt later tend to be happier than the reverse.
Does the MCP spec change affect my framework choice?
Not the choice, but it does affect the timing. Frameworks are shipping support against the beta SDKs, so check where your candidate stands on the 2026-07-28 revision before committing to a migration schedule.
Sources and further reading
- Morph, agent framework comparison and Claude Agent SDK reference
- MCP 2026-07-28 release candidate
- Alice Labs, agent frameworks compared
- The controlled harness
- What the MCP spec change means
The quiet story across all of this is convergence. Two years ago every framework invented its own tool-calling format, its own memory abstraction and its own orchestration vocabulary, and choosing wrong was expensive. Today the tool layer is standardising on MCP, the frameworks are merging rather than multiplying, and the differences that remain are mostly about language and operational fit. That is what a maturing category looks like — and it means the interesting engineering has moved up a level, from wiring tools together to deciding what the agent should be allowed to do. That is a better problem to have. Deciding scope, permissions and stopping conditions is genuinely hard work with real consequences, whereas rewriting a tool integration for the third framework in two years never was. If your team is still spending its time on the latter, the consolidation described here is your permission to stop.
