You have shipped a proof of concept. It worked. Now you are wiring your third agent by hand: writing custom logic to route messages between them, deciding exactly where to store intermediate state across turns, and implementing retry loops for when an LLM inevitably returns malformed output. The coordination seams are showing.
At this stage, a question surfaces, quietly at first: should I keep assembling this system using a framework, or move to a platform that handles this layer for me?
The real spectrum
The multi-agent ecosystem is crowded, but structurally, the tools fall onto a single spectrum.
On one end are frameworks and toolkits. You might be using CrewAI, LangGraph, Pydantic AI, LangChain, LlamaIndex, or vanilla Python and TypeScript orchestration. These libraries give you primitives. They provide state graph definitions, memory wrappers, tool-calling utilities, and prompt constructors. They do not run your system; they give you the parts to build a runtime. You provide the wiring. You decide how state persists between node executions. You write the loop that evaluates output and manages the handoff.
On the other end is a platform: an abstraction layer paired with a managed runtime. It owns the coordination logic, state management, and evaluation loops. You provide the agent definitions, the tools, and the desired topology; the runtime executes it.
This is fundamentally an abstraction-versus-control trade-off. It is an engineering decision, not a religion, and certainly not a brand war. You are deciding which layer of the stack you want to own.
Where the abstractions leak
To evaluate the trade-off, look at where each approach fails. Both models lose, just in different places.
When you build on a framework, you own coordination, state, and every seam in the system. This becomes an assembly burden. Because you are writing the glue code, there are more ways to lose a message in transit, corrupt a context window by appending an incorrect intermediate step, or silently miss a failure because an exception was caught but not handled upstream. Debugging is raw. Observability is entirely do-it-yourself. You are responsible for ensuring that the exact system state at step four passes accurately to step five.
Platforms fail differently: you surrender low-level control. Lock-in risk is real because the runtime owns your coordination logic. If the platform’s abstraction leaks, debugging becomes opaque. You might see that a task failed, but because the execution loop is hidden behind an API or a closed runtime, you cannot step through the execution graph to see exactly where the state diverged. Furthermore, if you need to express bespoke coordination patterns the platform did not anticipate, you will find yourself fighting the runtime rather than using it. Workarounds in closed abstractions are usually brittle.
Choosing the right seam
Deciding between a framework and a platform comes down to mapping your organisation’s constraints against the reality of agentic operations.
Team size and infrastructure appetite. A small team with a deep appetite for infrastructure often leans towards a framework. They want total execution control and are willing to maintain the boilerplate to get it. A larger team that wants to move fast on application logic and domain expertise will find a platform pays off by removing the operational tax of running the system.
Coordination complexity. As noted in Anthropic’s Building Effective Agents, most practical systems rely on a few standard patterns. Whether it is a sequential chain, parallel execution, or a Coordinator-Worker-Delegator handoff, these topologies are largely solved problems. If your system relies on these standard patterns, a platform handles the boilerplate reliably. If your system requires truly novel multi-agent choreography, a framework gives you the necessary escape hatches to build it yourself.
Observability needs. Production systems require deep visibility into the execution graph. Frameworks let you wire your own tracing exactly where you want it, emitting spans to your preferred telemetry backend. Platforms give you built-in, out-of-the-box views — like step-by-step execution receipts — but strictly at their chosen level of abstraction. You see what the platform chooses to expose.
Maintenance dependencies. Adopting a platform is a maintenance bet. You are taking a dependency on someone else’s runtime evolution. If the runtime changes how it handles memory or parallel execution, your deployment is affected. Frameworks isolate this risk slightly; if a library deprecates a feature, you can often pin the version or fork the component with less operational disruption. Size that risk honestly against the cost of maintaining your own runtime.