Something Old, Something New, Something Blue: How AI Agent Frameworks Are Fooling You

There’s a wedding tradition with a simple mnemonic: something old, something new, something borrowed, something blue. It’s meant to ground a moment of genuine novelty in continuity — to acknowledge that even the most transformative events in life are built on things that existed before.

The AI agent framework space has taken that idea and inverted it. It’s wrapping things that existed before in the language of novelty, and charging you $0.60 per coordination round for the privilege.

I spent time recently going through five of the most-cited agent frameworks — AutoGen, LangGraph, CrewAI, ByteDance’s DeerFlow, and Anthropic’s published patterns — and mapping each one to the architecture pattern it actually implements. The result is less a comparison of frameworks and more an archaeology dig — because once you see the real pattern underneath, you can stop evaluating frameworks and start evaluating whether the pattern fits your problem.

The Map

Here’s the honest translation:

AutoGen — calls itself multi-agent conversation. It’s the integration database anti-pattern, with LLM calls instead of a shared Oracle schema.

LangGraph — calls itself a graph-based state machine. It’s the Saga pattern.

CrewAI — calls itself role-based agent delegation. It’s pub/sub with the LLM as a runtime topic filter.

DeerFlow — calls itself composable infrastructure. It’s Pipes & Filters + lazy loading + offloaded working memory (state).

Anthropic Patterns — calls them composable primitives. They’re scatter-gather / fan-in/out, pipeline, orchestrator-worker — the Enterprise Integration Patterns book, chapter by chapter.

Every one of these is a legitimate, well-understood pattern. The Saga pattern is a battle-tested solution to distributed transaction coordination. Pipes & Filters is in every serious architecture curriculum. The integration database anti-pattern has a well-documented body of post-mortems. These are known patterns with known trade-offs — studied, documented, and pressure-tested across decades of production systems. The problem isn’t that the frameworks use old patterns. It’s that by hiding the patterns behind new names, they prevent you from accessing everything we already know about when those patterns work, when they break, and what to reach for instead.

Something Old

AutoGen bets on conversation as coordination. Agents talk through a GroupChatManager that broadcasts messages and selects who speaks next. Every agent reads every message. The token math is impressive: four agents, twenty messages per round, five rounds — that’s 200,000 tokens in coordination overhead before any agent does actual work.

This is the integration database anti-pattern. Not a clever metaphor — the structural problem is identical. You have multiple independent services (agents) all reading and writing to a single shared state (the conversation context), with no ownership boundaries, no schema contracts, and coupling that grows with every participant you add. Enterprise architects spent the 2000s untangling systems built exactly this way, where four applications shared a single Oracle schema because it was the fastest path to integration. The solution was explicit service contracts and private data ownership. AutoGen looked at that lesson and said: what if we did it again, but the shared database costs $0.003 per read?

If you recognize the pattern, you already know the failure mode: it works fine with two or three participants and becomes unmaintainable at five. You don’t need to discover this through a failed pilot. You need to read the post-mortems from 2006.

CrewAI bets on role-based delegation. Define each agent’s role, goal, and backstory; let them coordinate. Fastest path to a demo — 30 lines of code.

It’s pub/sub with the LLM as the topic filter. The subscription contract isn’t explicit and static, the way it is in any real messaging system. It’s implicit, evaluated at runtime by parsing natural language role descriptions. Your routing logic lives in a prompt, not code. It can’t be diffed (it could), it can’t be unit tested (in the deterministic way we know and love), and it drifts with model updates without you changing anything.

Their own retrospective on two billion workflows says: start with 100% human review, work your way down to 50%. That’s not a deployment best practice. That’s an admission that non-deterministic routing isn’t production-safe. And a 50% human review target means you haven’t built an autonomous agent — you’ve built an expensive suggestion engine with extra steps. They then bolted on “Flows” — deterministic, event-driven pipelines — which is the field rediscovering point-to-point messaging after discovering that broadcast doesn’t scale. Yay! Chains … oh actually… workflows … ah… deterministic sequencing, you know … like code…

Anyone who’s operated a pub/sub system at scale could have told you this would happen. The pattern predicts the failure. That’s the whole point of recognizing it.

Something Borrowed

LangGraph is often described as a graph-based state machine, but that’s underselling what it actually implements. When you combine directed state transitions, per-node checkpointing, pause/resume/replay capability, and the ability to roll back to a prior state when something fails — that’s the Saga pattern.

The Saga pattern was formalized by Hector Garcia-Molina and Kenneth Salem in 1987 to handle long-running distributed transactions without global locks. Each step in a saga either completes successfully or executes a compensating transaction to undo its effects. LangGraph’s checkpointing is exactly that: each node transition is a saga step, and time-travel debugging is compensating transaction logic with a better marketing name.

The trade-off is the same one the Saga pattern always carried: schema coupling. When your saga steps change, your existing checkpoint state becomes invalid. LangGraph inherits this directly — refactor the graph and your checkpoints break. The control is real. So is the rigidity. Nothing about this is new; it’s just running inside an LLM workflow now. Architectures respond to systemic pressures, not to trend cycles — and this pressure was solved in 1987.

If your problem is long-running, multi-step coordination with failure recovery, the Saga pattern is a strong fit — and LangGraph is a reasonable implementation of it. But you should be choosing it because your problem needs a saga, not because a framework vendor told you graphs are the future.

DeerFlow (ByteDance, February 2026) is the most architecturally honest of the five. It calls itself “composable infrastructure” and largely delivers on that. The three pillars it advertises — progressive skill loading, filesystem-first state, and a middleware pipeline — map cleanly to: lazy loading, externalizing your working set to the memory hierarchy, and Pipes & Filters from the Enterprise Integration Patterns book (Hohpe & Woolf, 2003).

“The Library Card Principle” — index everything, load only what you need — is lazy loading. “Filesystem-first state management” is the observation that disk is cheaper than RAM, and RAM is cheaper than in-flight compute. Every computer architecture curriculum covers this. The 9-module middleware pipeline is a configurable filter chain. None of this is invented here. It is, however, implemented more cleanly than anything else in this space, which matters.

DeerFlow is also the only framework where the pattern mapping actually helps the practitioner. If you know you need a filter chain with lazy loading, and DeerFlow gives you a clean one — use it. The pattern fit is the decision, and the framework is just the implementation.

Something New (Sort Of)

There is one genuinely new constraint, and it’s worth naming precisely so it doesn’t get inflated into something it isn’t.

In traditional distributed systems, calling a service with a large payload is a latency and cost problem. The quality of the call’s output is unaffected by payload size — a slow REST call returns the same data as a fast one. With LLMs, stuffing the context window degrades output quality, not just cost. The system gets more expensive and dumber simultaneously. The payload is the cognition environment. What goes in shapes what comes out.

This means every old pattern — lazy loading, working set management, pipes and filters — carries slightly different weight in an LLM pipeline. They’re not just cost optimizations. They’re quality optimizations. The agent that reads a structured 3,000-token summary of a 10-K filing reasons better than the agent that holds the full 80,000-token document in context. Not just cheaper. Better.

But — and this is important — the response to that new constraint is still the old patterns. You don’t need a new architecture. You need the discipline to apply the existing ones more rigorously, because the penalty for sloppy context management is worse here than it ever was in a traditional pipeline. The patterns are old. The cost of ignoring them is new.

Something Blue

The creative brief I started with had a wedding mnemonic. The “something blue” in tradition is meant to ward off the evil eye — protection against hidden harm.

The hidden harm in this space isn’t that the frameworks are built on old patterns. It’s that the framing actively discourages practitioners from reaching for the patterns they already know. Teams that have shipped event-driven systems, workflow engines, and middleware pipelines are being asked to learn a new vocabulary for things they’ve already solved, in ecosystems that are 18 months old and forking under their feet. Every time a team learns “DeerFlow middleware” instead of “Pipes and Filters,” the muscle that would let them design their own pipeline atrophies a little more.

The Saga pattern has 37 years of production experience behind it. Enterprise Integration Patterns has been in print since 2003. The field is speedrunning those lessons in about 18 months, hitting the same failure modes in roughly the same order, and calling each rediscovery a breakthrough.

The way out isn’t to avoid the frameworks. It’s to see through them. Strip the name. Find the pattern. Check whether that pattern fits the problem you actually have — not the problem the framework was designed to demo. If it fits, use the framework. If it doesn’t, you now have 30 years of alternatives to choose from, and none of them require a $200/month platform tier.

Architecture Alert

I use these frameworks. Depending on the stack I’m in, I reach for LangChain, Vercel’s AI SDK, or Semantic Kernel / Agent Framework — and I’m genuinely glad they exist. What I use them for is the unified interface to the model: consistent tool calling, structured output, provider abstraction. That’s valuable plumbing and I don’t want to write it myself.

What I don’t do is let the framework decide my architecture. The orchestration, the coordination pattern, the state management — those should be designed bespoke to the problem. When you let a framework make those choices for you, you’re not adopting a tool. You’re fitting your problem to someone else’s solution. And in this space, that someone else has might know the pattern for about 18 months. You might have known it for 15 years.

Use the libraries. Design the solution.