Agent Frameworks vs Writing the Loop Yourself

The argument is usually framed as build versus buy, which is the wrong frame for something you can write in an afternoon. The loop is eighty lines. The question is what surrounds it, and whether somebody else’s answer to that fits the shape of your problem.

This page names capabilities rather than products deliberately. The libraries move quickly enough that a feature comparison written today is misleading by the time it is read; the categories below have been stable for years and will decide the question either way.

The loop is not the hard part

Anyone can write the loop — send, check for tool calls, dispatch, append, repeat. If the pitch for a framework is that it saves you from writing that, the pitch is weak. Everything genuinely difficult about agents is in the five categories below, and how much of each you need is what decides the answer.

Five things frameworks genuinely do

1. Durable execution

This is the big one and the least appreciated. A thirty-step run that takes eight minutes will be interrupted — a deploy, a crash, an instance rotation, a network partition. Resuming means persisting the message list, the budget, and which tool calls have already had effects before executing each one, then replaying without repeating the side effects. That is a checkpointing problem with idempotency requirements, and it is genuinely hard to get right. Frameworks built on durable-execution engines earn their existence here alone.

2. Streaming assembly

Accumulating partial tool calls across streamed deltas, keyed by index, while simultaneously streaming prose to a user and holding back anything that turns out to be part of a call. Fiddly, provider-specific, and worth zero differentiation — precisely the kind of code to inherit.

3. Provider normalisation

Tool schemas, tool result shapes, system prompt handling, image blocks, reasoning blocks and stop reasons differ between model families in small, tedious ways. Worth outsourcing if you genuinely run several, and worth nothing if you run one. Note that a gateway solves the same problem one layer down and without an abstraction in your process.

4. Interrupt and resume for approvals

Pausing a run mid-loop for a human approval means serialising the whole run state to storage, surfacing it, waiting an unbounded time, and resuming into the same message list. If your agent is a request handler, this converts it into a workflow engine — and if you would rather not build one of those, this is a strong reason to adopt something that already has.

5. Multi-agent plumbing

Handoffs, shared state, budget propagation, and trace correlation across sub-agents. Worth having if you have concluded you need a real topology, and pure overhead if you have not.

Four places the abstraction costs you

• It hides the messages array. The messages array is the program. Every agent bug is ultimately “the wrong thing was in the context at step N”, and a framework that assembles it three layers down — with its own system prompt additions, its own compaction, its own tool result formatting — puts distance between you and the only artefact that explains the behaviour.
• It has opinions about prompts. Many frameworks inject their own instructions, scratchpad formats or output parsers. These interact with your prompt in ways that are invisible until you dump the payload, and they change between versions — so an upgrade can alter agent behaviour with no change on your side.
• Its retry and error semantics are not yours. A framework that retries a failed tool three times inside its own executor has spent your budget without consulting the classification in error recovery, and may have retried something non-idempotent.
• The escape hatch is the real API. The demo is five lines; production is those five lines plus a dozen callbacks, middlewares and subclassed components to reach the behaviour you wanted. At that point you have written the loop anyway, indirectly, in a vocabulary somebody else designed.

The deciding test

One question, and it discriminates better than any feature matrix:

Can you print the exact JSON payload sent to the model for step 7 of a failed production run, in under a minute, without adding code?

If yes, the framework is a library and you can adopt it cheaply — it is doing work for you without standing between you and the evidence. If no, you will eventually hit a behaviour you cannot explain, and the debugging will consist of reverse-engineering the framework rather than fixing your agent. That is the failure mode people describe when they say they ripped a framework out, and it is predictable in advance from this one question.

A second, cheaper test for the same property: how long does it take to find, in the source, the line where the HTTP request is constructed? Two minutes is a good sign. Not finding it is the answer.

The middle path most teams end at

• Own the loop. Eighty lines, in your repository, with your budget, your stopping conditions and your error classification. This is the part that encodes your product’s judgement and it is small.
• Borrow the tedious parts. Streaming assembly, schema generation from type hints, retry primitives, a tracing integration. Libraries, not frameworks — things you call, not things that call you.
• Push normalisation down a layer. One OpenAI-compatible endpoint in front of every model removes the provider-differences argument entirely, without an abstraction inside your process.
• Adopt a workflow engine only when durability demands it. If runs must survive a deploy or wait days for an approval, that is a real requirement with a mature answer, and it is a much better reason to adopt something heavy than any of the others.