The Agent Framework Trap

By Vlad Luzin

May 18, 20265 min read

Separate framework environments rendered as walled gardens, with collaboration easy inside each framework and difficult across the walls.

Framework choice feels like an application decision until agents built on different frameworks need to share state, messages, and lifecycle. The article frames this as an O(N^2) infrastructure problem, not a product team mistake.

Pick a framework. LangGraph, CrewAI, PydanticAI, OpenAI Agents SDK, Claude Agent SDK, AutoGen - there are at least six production-grade options, each with a fundamentally different philosophy on how agents should work. Picking wrong means rewriting your orchestration layer in six months.

But here's the thing nobody tells you upfront: picking right is also a trap.

Every framework makes the first agent easy. The second agent - if it's in the same framework - is easy too. The problem starts when your second agent needs to be in a different framework. And in any non-trivial organization, it will be.

One team builds a data analysis agent in LangGraph because they need fine-grained control over state transitions. Another team builds a customer-facing agent in CrewAI because they want role-based crews and fast prototyping. A third team uses the Claude Agent SDK because it's one of the most advanced agent harnesses available - or OpenAI's Codex because it's open source. Each team made a reasonable choice. Now you need these agents to work together.

Good luck. LangGraph models agents as directed graphs with typed state dictionaries and checkpoint-based persistence. CrewAI uses event-driven Flows with Pydantic-validated state and persistence backends. PydanticAI uses dataclasses for dependency injection and state validation. OpenAI has its own thread and run model. Each framework has its own message format, its own state management, its own tool calling conventions, its own execution lifecycle.

And state doesn't transfer between frameworks. If you build in CrewAI and want to talk to something in LangGraph, you start from scratch.

You can see this concretely in something as basic as "where was I in this conversation?" LangGraph tracks continuity with a thread_id keyed to a checkpointer. OpenAI uses thread_id and run_id - same words, different semantics. The Claude Agent SDK uses session files on disk. CrewAI uses Flow state objects with configurable persistence. A2A uses context_id and task_id. Five frameworks, five incompatible answers to "what is a session?" Now try mapping a conversation that spans agents on three of these. Which session ID is the source of truth? Where does the shared context live? Who owns the conversation history?

The industry's answer is protocols. MCP for tools, A2A for agent-to-agent. I've already covered why MCP doesn't work for this and why A2A isn't adopted. But even if both were perfect and universally adopted, they solve interoperability at the communication layer. The state layer - the thing that makes agents useful across conversations - remains framework-specific.

That's the framework trap. It's not about picking the wrong framework. It's that the choice of framework becomes a boundary your agents can't cross. Inside the wall, everything works. Across walls, you're writing custom translation code for every pair of frameworks that needs to interact.

"Just standardize on one framework" is the obvious advice. It's also advice that doesn't survive contact with reality. In any large enterprise, standardizing a single framework across all engineering groups and products is a fantasy. Different teams have different requirements, different expertise, different timelines. And the moment you integrate a third-party agent - a vendor's agent, a partner's agent, an agent from an acquisition - you're back to framework boundaries with no standard bridge between them.

A dense web of custom connections between many framework cards, visualizing the O of N squared integration problem.

The visible symptom is the O(N^2) integration problem: every new framework multiplies the amount of translation code the organization needs to maintain.

Several code and state models side by side, showing incompatible assumptions hidden inside different frameworks.

What's missing isn't a better framework. It's a layer beneath the frameworks - one that handles state, message routing, and execution lifecycle in a framework-agnostic way, so that a LangGraph agent and a CrewAI agent and a Claude SDK agent can participate in the same work without custom glue code between each pair.

More on what that looks like next week.