Academy

Framework or platform? Choosing the right abstraction for your agent system

Past the prototype, you are assembling your third agent by hand — and the coordination tax is real.

The Felesh team 6 min

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.

Three agents and the glue between themThree agents sit in a row: triage reads the intent, lookup calls the carrier API, and reply, the third, was added today. A message about shipment SH-3382 travels along them. Under them is the code you write by hand: a routing rule that sends delay intents to lookup, a question of where the delivery estimate lives between turns, and a retry when the model returns eta as tomorrow-ish, which is not a date. Three agents, three seams, all of it your code.three agents, wired by handtriagereads intentlookupcarrier APIreplyadded todayrouteintent == delay → lookup, else replystatewhere does eta live between turns?retryeta = “tomorrow-ish” → not a date, retry (max 3)3 agents, 3 seams, all of it your code
Wiring the third agent means writing the routing, state and retry code between them yourself.

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.

Who owns which layer on each end of the spectrumA table of six layers against the two ends of the spectrum. Routing messages, state between turns, retries on bad output: on a framework such as LangGraph or CrewAI you write each one; on a platform the runtime owns them. Tracing: on a framework you wire your own spans; on a platform you get built-in views. Agent definitions and tools with topology are yours on both ends.who owns itframeworkLangGraph, CrewAIplatformmanaged runtimeroute messagesstate between turnsretries on bad outputtracingagent definitionstools and topologyyou write itruntimeyour own storeruntimeyour own loopruntimeyour own spansbuilt-in viewsyouyouyouyoublue: you write and run it · grey: the runtime doesbelow the dashed line it is yours on either end
On a framework you write and run the routing, state, retries and tracing; a platform's runtime takes those over, and you still supply the agents, tools and topology.

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.

Where each approach loses youTwo panels. On a framework, step 4 holds eta 2 Nov and passes it to step 5 across a seam of glue code you wrote; the error is caught but not handled, so step 5 sees eta none, though you can trace every step. On a platform, task SH-3382 enters the runtime’s execution loop, which is not exposed, and comes out as status failed with no way to see why. Both lose you, in different places.frameworkplatformyou own every seamthe runtime owns the loopstep 4 · eta: 2 Novglue code, yourscaught, not handledstep 5 · eta: nonetask SH-3382 queuedexecution loopnot exposedstatus: failed, why?both lose you, in different places
A framework fails in your own glue code, where an unhandled error loses the state; a platform fails behind its runtime, where you see that the task failed but not why.

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.

Four constraints, two leaningsA decision table with four rows. Team size and infrastructure appetite: a small team that wants full runtime control leans framework; a larger team moving fast on domain logic leans platform. Coordination: a novel choreography needing escape hatches leans framework; standard patterns such as chain, parallel or CWD lean platform. Observability: your own spans wired where you want lean framework; built-in receipts at the platform’s own level lean platform. Maintenance: with a framework you pin a version or fork a deprecated piece; with a platform you bet on someone else’s runtime roadmap.decide onlean frameworklean platformteam sizeappetitecoordinationcomplexityvisibilityneedsmaintenancedependenciessmall team, totalruntime controlnovel choreography,needs escape hatchesyour own spans,wired where you wantpin a version orfork a dropped piecelarger team, faston domain logicstandard patterns:chain, parallel, CWDbuilt-in receipts,at its own levela bet on someoneelse’s runtimemap your own answer row by row; no side wins every row
Each constraint pulls toward one side: weigh your team, your topology, your tracing and your tolerance for someone else's roadmap, row by row.

Start with the architecture →