AI agent frameworks vs writing your own loop

The agent loop is about twenty lines of code. Frameworks exist anyway, and the reason isn’t the loop.

They’re selling everything around it: retries, tracing, tool schemas, state, evaluation hooks. Whether that’s worth a dependency depends on which of those you’d otherwise build badly.

What the loop actually is

Send the task and the available tools. The model replies with an answer or a tool call. If it’s a call, run it, append the result, send everything back. Repeat until done or until a limit trips.

Nobody has ever failed to build an agent because the loop was hard. They fail on the retries, the budgets and the logging that a demo never needed.

Three things must be bounded from the first version: iteration count, spend, and wall-clock time. An agent without those is a program that can bill you indefinitely, which our guide to building one covers.

The comparison

	Framework	Your own loop
Time to first demo	An hour	An afternoon
Tracing and logging	Included	You write it
Debugging a bad run	Through abstraction layers	Straight through your code
Swapping providers	Usually supported	A base URL
Unusual control flow	Fights you	Trivial
Upgrade churn	Theirs, on their schedule	Yours

What AI agent frameworks genuinely give you

Governance is becoming a reason too. Vendors now sell products to govern what agents do with company data in real time, and a framework with structured tool-call events is easier to wire into that than an ad-hoc loop.

Observability is the strongest argument, and it’s undersold. Seeing every tool call, its arguments, its result and the token spend is the difference between debugging an agent and guessing at one.

Most teams building their own loop skip that until they need it, and by then the failing run is over and unlogged.

Tool schemas are the second. Generating a JSON schema from a function signature, validating arguments and returning a useful error is tedious code that frameworks have already got right.

That error message matters more than it looks. The model reads it, so one saying which argument was wrong and what values are valid gets corrected on the next iteration, while a stack trace gets the same mistake retried.

What they cost you

Debugging through an abstraction is the recurring complaint, and it’s a real one. When an agent behaves strangely, the question is always what exactly was in the context at that step, and a framework that assembles context for you makes that harder to answer.

Context assembly is precisely where long-running agents fail, too. Research this year found masking stale observations helps until it doesn’t, with the effect depending on where in the trajectory it’s applied, and a framework’s uniform policy is the shape most likely to misfire.

Our piece on why long-horizon agents fail covers the rest of that evidence. The short version is that context management is the thing you most need to control, and it’s the thing frameworks most want to own.

Then there’s churn, from two directions at once. Frameworks iterate quickly, and so do the models underneath them, with Google shipping an entry-level model three weeks after its predecessor.

An upgrade to either can change behaviour in ways your evaluation set catches and your intuition doesn’t, which is an argument for owning at least one of the two layers.

The middle path most teams land on

Write the loop yourself and borrow the pieces. Use a provider’s structured-output mode for schema enforcement, an off-the-shelf tracing library for observability, and keep control flow in your own code.

That gets you the parts frameworks are good at without the part they’re worst at, which is deciding what the model sees at each step.

Ask for a plan before the first tool call while you’re at it. Google Research showed in Chain-of-Thought Prompting that working through steps improves accuracy substantially, and in a loop a wrong first step is the most expensive kind.

Where frameworks are clearly right

Prototyping, where you’re testing whether an agent can do the job at all and throwaway code is the correct kind of code.

Multi-agent orchestration, where the coordination logic is genuinely complex and someone has already thought about message passing and shared state. That pattern is becoming standard, with Meta’s coding agent fanning work out to parallel sub-agents.

And teams without the capacity to maintain infrastructure. A framework is a dependency; a homegrown agent runtime is a product you now own, and that trade is only worth it if someone is going to look after it.

Where writing it yourself is clearly right

Production systems where reliability matters more than development speed, because compounding errors mean a 95% step is a 36% task across twenty steps and you’ll be tuning that curve for months.

Simulating a plan before executing it is one of the more promising ways to bend that curve, with research on self-regulated simulative planning spending reasoning tokens rather than tool calls to discover a dead end. Implementing it means changing the loop, which is easier when the loop is yours.

Anything with unusual control flow: a human approval in the middle, a resumable long-running job, a hard budget per customer. Those are trivial in your own loop and awkward in someone else’s.

And anything where you need to know exactly what the model was sent, which in practice means anything regulated or anything you’ll be asked to explain.

The honest recommendation on AI agent frameworks

Prototype with a framework, then rewrite the loop when you know what you’re building. The rewrite is a day, and by then you’ll know which of the framework’s opinions you actually needed.

Keep tools narrow either way, since the tool definitions matter more than either choice. Meta’s coding agent showed the pattern by isolating sub-agents in separate worktrees, which is a containment decision no framework makes for you.

And whichever you pick, log every tool call with its arguments from day one. That single artefact makes every other debugging decision possible, and it’s the one thing that’s expensive to add later.