Is an AI agent just a while loop?

Largely, yes. Call the model, run a tool in your own code, append the result to the conversation, and send it again until the model stops or a step cap trips. That cycle is about a hundred lines with no library. The interesting question is not the loop itself but how it holds up in production.

LangGraph vs CrewAI: which should I use?

Pick by the wall you hit. LangGraph suits strict, auditable branching where one step must always run before another. CrewAI leans toward role-based multi-agent teams. Before either, try the plain loop; most projects that reach for a framework on day one end up rebuilding a worse version of it anyway.

Should I build a multi-agent system?

Rarely, and almost never early. Splitting work across a researcher, writer, and editor drops information at every handoff, like a game of telephone. Multi-agent pays off only for truly parallel, read-heavy work where agents never share context. The moment they depend on each other, one capable agent usually wins.

What is a durable runtime, and why does it matter for agents?

A durable runtime like Temporal, DBOS, or Inngest sits under your loop and lets a run resume from the exact step it died on after a crash, with variables intact. Surviving interruption is an old distributed-systems problem, not an AI one, and it is often the real first upgrade an agent needs.

AI Agent Frameworks: Do You Actually Need One?

You decided to build your own agent loop. Just a hundred lines, no need for LangGraph. Six weeks later you are staring at two thousand lines of retry logic, state handling, and approval gates you never planned to write. Congrats. You have built a worse version of the exact framework you swore off, and you are the only person alive who understands it.

That trap is the whole debate in miniature. This article covers what an AI agent framework actually does, when it earns its place, and the one upgrade almost everyone reaches for in the wrong direction.

What is an AI agent framework?

An AI agent framework is a library like LangGraph, CrewAI, or PydanticAI that wraps the model-and-tools loop and does four jobs for you. Strip the marketing and that is all it is: it writes your boilerplate (defining and parsing tools), manages your state (history, memory, checkpoints), handles orchestration (the routing between steps), and runs operations (retries, logging, guardrails).

The part worth internalizing is what is not in there. None of those four jobs is hidden intelligence the model gets only through the framework. Every one is plain code you could write yourself. The real question is never “is the framework smart,” it is “should I hand this part over.”

01 Boilerplate defining and parsing tools you could write this

02 State history, memory, checkpoints you could write this

03 Orchestration routing between the steps you could write this

04 Operations retries, logging, guardrails you could write this

Fig. 1 The four jobs a framework does on top of your loop. Boilerplate, state, orchestration, operations. Each is ordinary code you could write, which is why the honest question is whether to hand it over, not whether it is magic.

Hand it over and you buy speed: a working agent on day one with a stack of nasty problems pre-solved. The cost is visibility. Your prompts, your tool calls, the exact text the model sees, all of it slides one layer back, behind the framework’s code, where you cannot watch it as closely.

The agent loop hiding inside every framework

Underneath every framework is a loop you could write in an afternoon. You send the model two things: the user’s request, and a list of tools it is allowed to call, each one just a name and the arguments it takes. The model replies. If it is a normal answer, you are done. If it is a request to use a tool, your code runs that tool, takes whatever comes back, and pastes it onto the end of the conversation. Then you send the whole thing again.

Call the model, run a tool, append the result, repeat, until it stops asking or a step cap makes it stop. That is maybe a hundred lines, no library required.

Fig. 2 The loop stripped to the metal. Call the model, run the tool it asks for in your own code, append the result, send it all again. A red STOP cap and a normal answer are the two ways out.

Do you need an AI agent framework?

Usually not to start, and the model makers agree. Anthropic’s own guide, Building Effective Agents, tells you to begin with direct API calls, because frameworks add layers of abstraction that can obscure the underlying prompts and responses and make the whole thing harder to debug. The company that makes the models is telling you to go easy on the abstractions.

That is a striking thing for a vendor to say, and it points at the cost of adopting a framework too early. You lose the thing you most need while learning: a clear view of exactly what your agent is doing and why it broke. You will learn more about how your agent really fails in one week of running a plain loop on real tasks than in a month of framework tutorials.

Why the framework question changed

The framework people were not wrong to build these. Back in 2023 they were fixing a real problem: the models were bad at this. Ask one for a clean block of JSON to trigger a tool and it might wrap it in chatter, misspell a key, forget an argument, or smother it in markdown that broke your parser. Early frameworks became scaffolding. They forced the output into shape, retried when it came back malformed, and covered for everything the model could not do alone.

Then the models got good. Tool calling went from a prompt-engineering trick to a native feature the providers built in. Context windows grew big enough to hold a long task without clever memory hacks. Planning several steps ahead became something the model just does. A lot of what those frameworks did for a living, the model now handles on its own.

2023 Scaffold holds it up

The model mangled tool output: broken JSON, a misspelled key, a missing argument. The framework forced it straight and retried.

HELPS

2025 The model absorbs the jobs

Tool calling went native. Context windows grew. Planning got better. The work the scaffold did for a living, the model now just does.

NATIVE

now Scaffold becomes an anchor

Bolt the same brace onto a stronger model and it drags. One Anthropic trick that helped an older model turned into, in their words, dead weight.

DEAD WEIGHT

Fig. 3 Why the case for frameworks weakened. A 2023 model leaned on yellow scaffolding; a stronger model absorbed those jobs; the same scaffold, unchanged, became a red anchor that drags the newer model back.

Anthropic’s own context-engineering guidance makes this concrete: a trick that reset the context and clearly helped an older model became, in their words, dead weight once they moved to a stronger one. The help had turned into a drag. Scaffolding you build for last year’s model can be the exact thing holding this year’s model back.

The accidental framework: four walls every loop hits

So you start simple, the way everyone says to, and bring your clean loop to production. Then it hits a wall. Then another. Each wall has an obvious fix, and each fix is a part you weld on.

Crash Bolt-on: state to disk

Forty-five steps into a fifty-step job the process dies and the whole history, sitting in memory, evaporates. So you save state after every step.

Runaway cost Bolt-on: spend cap + step limit

It gets stuck on a dead end, runs the same nothing twenty times, and you find out from the bill. So you add a budget and a hard step ceiling.

Session bleed Bolt-on: sessions

A second user shows up and their conversation leaks into the first, because one history array assumed one person. So you add per-user sessions.

Destructive tool Bolt-on: approval gate

You hand it a tool that can delete things and you do not want it deciding alone. So you add a gate where a human signs off before it fires.

Fig. 4 The four walls a plain loop hits in production, and the yellow part you bolt on to survive each one. Weld all four together and you are holding a framework you built by accident.

Look at what you are holding now: state persistence, budget control, sessions, an approval gate, routing. That is the accidental framework, and it is the reason the “just build it yourself” crowd so often ends up with a worse version of LangGraph. Nearly every team that swears off frameworks rebuilds one by accretion, minus the docs, the tests, and anyone else who understands it.

But look back at the very first wall. The crash. It had nothing to do with whether the model was smart or dumb. It was about whether your run could survive being interrupted, and that is one of the oldest problems in plain distributed systems. It predates AI by decades.

Is a durable runtime the real first upgrade?

For a lot of teams, yes, and this is the reframe that makes the whole loop-versus-framework fight feel a little beside the point. To fix the crash, you do not reach up for an agent framework. You reach down, for a durable runtime underneath your loop: Temporal, DBOS, or Inngest. You keep your plain loop exactly as it is, run it on one of these, and when the server reboots mid-task it resumes from the line where it died with every variable intact.

on top Framework optional, and it can wait

the middle Your loop unchanged, exactly as you wrote it

underneath ↓ Durable runtime Temporal · DBOS · Inngest the real first upgrade: resume, don’t restart

Fig. 5 The real stack. A framework is an optional slab on top; your loop sits unchanged in the middle; the durable runtime is the blue foundation you reach down for. The first upgrade lives underneath the loop, not above it.

This is not a fringe take. Anthropic hit the same wall building their research agents and said it plainly: agents are stateful, errors compound, and restarting from scratch is brutally expensive, so they built systems to resume instead. And the money is following the same logic. In February 2026, Temporal raised a $300 million Series D at a $5 billion valuation, betting that durable execution, not agent orchestration, is where the real production pain lives.

Should you build a multi-agent system?

Rarely, and almost never as early as people reach for it. The multi-agent swarm, a researcher handing to a writer handing to an editor, all chattering at each other, sounds great and mostly is not. Even the vendors whose product is multi-agent say so. Cognition, whose Devin is a multi-agent AI engineer, published one of the most-cited essays in the space, and the title is literally Don’t Build Multi-Agents.

Both Cognition and Anthropic trace the problem to the same root, and it is not the number of agents. It is context. Split a job across three agents and every handoff is a chance to drop information. Agent one summarizes a little badly, agent two builds on the gap, and the mistakes compound down the line like a game of telephone.

Multi-agent handoff

Researcher “ship the v2 auth flow by Friday, skip SSO”

Writer “ship the auth flow Friday (SSO?)”

Editor “auth flow, sometime, with SSO”

More agents = more telephone

One capable agent

Single agent “ship the v2 auth flow by Friday, skip SSO” one wide context window · nothing handed off

Nothing dropped between heads

Fig. 6 Why multi-agent breaks. A message degrades at every handoff down a researcher-writer-editor chain (left), while one capable agent with a wide context window keeps the whole brief intact (right). Add more agents and you mostly add more telephone.

There is a narrow case where the swarm wins: work that is truly parallel and mostly reading rather than writing, where you fan out, gather a lot at once, and pull it back together. The second your agents have to share context or make decisions that lean on each other, one capable agent with a big context window tends to beat the whole committee.

AI agent framework vs loop: which should you pick?

Neither, as a default. Pick the smallest fix that clears the specific wall in front of you, and climb only when a wall forces it. The honest path is boring and it runs in order.

The loop

One model, a couple of tools, a step cap so it cannot spin forever. Ship it on real tasks before you add a single thing.

A thin library

Buried in boilerplate for typed tools? Pull in something small like PydanticAI. A library, not a whole framework.

A graph framework

Need strict, auditable branching where step A must always run before step B? That is where LangGraph earns its keep.

A durable runtime

Crashes losing work, runs lasting hours? Reach down for Temporal or DBOS so the job resumes instead of restarting.

Multi-agent

Dead last, and only for the narrow case: work that is truly parallel and mostly reading, where agents never share context.

Fig. 7 The escalation ladder. Start on the loop and only climb a rung when a specific wall forces it: a thin library for boilerplate, a graph framework for auditable branching, a durable runtime for crashes. Multi-agent is dead last.

Match the fix to the wall, and nothing more. The table below is the same ladder read as symptoms, so you can find your wall first and pick the tool second.

The wall you hit	Reach for	Not this
Nothing yet, just starting	A plain loop: 1 model, a few tools, a step cap	Any framework on day one
Buried in boilerplate for typed tools	A thin library like PydanticAI	A full orchestration framework
Strict, auditable branching (A before B)	A graph framework like LangGraph	Hand-rolled if-else routing
Crashes lose work; runs last hours	A durable runtime: Temporal, DBOS, Inngest	A framework bolted on top of the loop
Truly parallel, read-heavy fan-out	Multi-agent, and only here	Multi-agent for anything sequential

There is a clean signal for when you have outgrown the loop. The day debugging a failed run takes longer than just shipping the feature would have, your hand-rolled loop has quietly become its own little platform, and a real framework is probably cheaper than babysitting it.

The bottom line

An AI agent framework is not magic and it is not a scam. It is four jobs of ordinary code you can either write or rent, bought at the price of seeing less of what your agent does. For most projects, the right first move is the boring one: build the ~100-line loop, run it on real work, and let the wall you actually hit tell you what to add.

When that wall arrives, fit the fix to it and stop there. Often the fix is not a framework on top at all, but a durable runtime underneath. Start with the loop, feel the wall, then go get the one piece that fixes it, and not a piece more. For the full walkthrough with every stage animated, watch the companion video below.

Watch the explainer