Do we still need LangGraph for multi-agent systems?

A hand-drawn panel. On the left, four separate adapters labelled A to B, B to C, C to A and A to D, with loose ends pointing at nothing. On the right, one pair of connectors joined by a single cable marked MCP and A2A. Underneath: a framework had to invent the connector, now there is a standard one.

I have been building with LangGraph for a few months. I am starting to wonder whether I still need it.

LangGraph is a framework for running several AI agents together. You declare each agent as a node, you declare the paths between them as edges, and the framework walks the graph. I was about to refactor a multi-agent system with it when I stopped. Two open protocols had arrived since I chose it, and they do most of what I was using it for.

This is what the setup used to be:

Build the agents in LangGraph
Wire them together with your own state management
Hope they cooperate
Hope it survives production

This is what it can be now:

Any LLM SDK, from OpenAI or Anthropic or anyone else
One open protocol connecting an agent to its tools
One open protocol connecting an agent to another agent

Two panels. On the left, Agent A and Agent B both connect down into a LangGraph box, which connects down to tools, and nothing is labelled. On the right, the same two agents connect to each other over a wire marked A2A, and each connects down to its own tools over a wire marked MCP.

Those two protocols have names. MCP, the Model Context Protocol, connects an agent to a tool. A2A, Agent2Agent, connects an agent to another agent. IBM’s ACP and Ecma’s NLIP are aiming at the same target from other directions. I went through all four, and through the 1996 standard they keep rediscovering, in how agents actually talk to each other.

LangGraph solved a real problem when it launched in early 2024. Multi-agent coordination was a mess and nothing standard existed, so a framework had to invent its own answer. The protocols arrived afterwards and took that job away from it.

The lock-in went with it. I can build an agent with one SDK and you can build yours with another, and the two still talk over MCP and A2A. Neither of us has to adopt the other’s framework to work together.

There is a second reason, and it is about how the agents behave rather than how they connect.

The agents I built in LangGraph felt mechanical. Every node and every edge is a decision I made before the model ever ran. The model then chooses between paths I had already drawn, so a good deal of the behaviour is my logic and not its reasoning.

Two hand-drawn panels. On the left, in red, the model sits inside a ring of four branches reading if intent = A, then call B, if reply = C, else go to D, wired nose to tail, and it says it only goes where the edges go. On the right, in green, the same model points at three tools named search, fetch and write, and says it will pick the one this needs.

Tool calling is the alternative. The model is handed a list of tools and decides for itself which one to call and when. When I let it do that, the conversations run better and the agent handles turns I did not plan for.

So here is where I land, with a different answer for each case.

For simple tool calling you never needed LangGraph. The LLM SDK already does it.

For a complex workflow inside a single agent, LangGraph may still earn its place. A graph is a fair way to describe a process whose shape you already know.

For multi-agent systems, the protocols look like the better bet.

I might be missing something. If you are building multi-agent systems now, are you still using an orchestration framework, or have you moved to protocols? If you stayed with a framework, what keeps you there? I ask because I am about to rewrite a good deal of code. I would rather find out first that the framework was doing something I have not noticed.

Related