Do You Need an AI Agent Framework, or Just the Loop?

Write the loop yourself. That is the right default for most teams building their first agent, and the reason is not ideological. The loop is short, the frameworks broadly agree on what it looks like, and the parts that are genuinely difficult are not the parts a framework hands you on day one.

What follows is the case for that position made honestly, including the four situations where it stops being reasonable and the table of what each AI agent framework actually gives you, read from each project's own documentation on 29 July 2026.

What is the loop, and how long is it really?

Send a message. Read the response. If it contains a tool call, run the tool, append the result, send it back. Otherwise return the answer. Stop when a condition you defined is met. We wrote that loop out turn by turn, with its stop conditions, in one agent built in plain code.

That is the whole thing, and in Python or TypeScript it is a while loop, a conditional and a list you append to. Anthropic's own Agent SDK documentation is unusually direct about the choice: use the Agent SDK if you want an agent without implementing the tool loop yourself, and use the plain client SDK if you would rather call the API directly and implement the loop yourself. Both are presented as reasonable, which is more honest than most framework documentation manages.

The complexity is not in the loop. It is in the six responsibilities that surround it, which we set out separately in a piece on what an orchestration layer has to own. A framework is a decision about which of those six you outsource, and the interesting question is which ones it actually covers well.

What does each framework actually give you?

Read from each project's own documentation, not from benchmarks or blog posts about them.

Three of those five are not really competing with each other. Pydantic AI is solving a validation problem, CrewAI is solving a multi agent coordination problem, and the Claude Agent SDK is packaging a specific working agent. Only LangGraph and the OpenAI Agents SDK are aimed squarely at the general orchestration question, and even they answer it differently.

What is genuinely hard to write yourself?

Durable state. Everything else on the list is a weekend, and this one is not.

LangGraph's persistence documentation describes two layers: checkpointers, which persist a thread's graph state as checkpoints and support conversation continuity, human in the loop, time travel and fault tolerance, and stores, which hold long lived key value data across threads. The framing it gives for why this matters is exact: persistence is what you need when an agent has to continue a conversation, resume after an interruption, recover from a failure, or remember something across interactions.

Building that yourself means serialising the entire conversation and tool state at every step, versioning that format so an old checkpoint still loads after you change the code, and handling the case where a tool ran but the process died before the result was recorded. That is a distributed systems problem wearing an AI hat, and it is the single strongest argument for adopting a framework rather than writing one.

The same docs also warn about the two things people get wrong with it, and both are worth reading before you commit. In memory checkpointers lose everything on restart, so production needs a real backend such as PostgreSQL. And checkpoints accumulate across long conversations, which means a pruning strategy is not optional.

What is the honest case for writing it yourself?

Four arguments, and the first one is the one that keeps mattering after month six.

Debuggability. When a hand written loop misbehaves, the stack trace points at your code and the fix is in front of you. When a framework misbehaves, you are reading someone else's abstraction to work out where your intent got translated into something else. This cost is invisible on day one and dominant on day one hundred.

The stop condition is yours anyway. No framework can tell you when your task is done, because that check has to run against your world: your tests, your schema, your database row. You are writing that logic regardless. Since it is also the most common source of runaway loops, keeping it in plain sight has value beyond the lines saved.

There is no consensus design to inherit. Benjamin Rombaut's source code survey of thirteen open source coding agent scaffolds found tool counts ranging from zero to thirty seven and seven distinct context compaction strategies across the thirteen, with eleven combining multiple control primitives rather than picking one. Where constraints forced convergence, on tool categories and edit formats, the projects agree. Where design is open, on context and state handling, they do not. Adopting a framework means adopting one project's unforced choices about exactly the parts your task will care about.

Upgrade cost. This field moves monthly. A hand written loop that calls an OpenAI compatible endpoint keeps working when a model changes. A framework introduces a second upgrade cadence you do not control, and the abstraction that was convenient in March is the migration you postpone in September.

When does writing it yourself stop being reasonable?

Four thresholds. Cross any one of them and the arithmetic flips.

The first is durable resume. If a run has to survive a process restart and pick up where it left off, stop and adopt something with a checkpointer. This is the threshold that arrives soonest for anything long running.

The second is human in the loop approval mid run. Pausing an agent, persisting its exact state, showing a human what it wants to do, and resuming on approval is the same persistence problem plus a UI, and both LangGraph and the Claude Agent SDK treat it as a first class feature, the latter through its permissions system.

The third is genuine multi agent coordination, meaning several agents with different roles passing work between them and holding shared state. This is what CrewAI is built around, and what the OpenAI Agents SDK calls handoffs. Notably, CrewAI's own documentation advises starting with a Flow for any production ready application and reaching for a Crew only inside a Flow step when a specific complex task needs a team. A framework telling you to prefer the deterministic path is worth listening to.

The fourth is when you find yourself building tracing. If you are writing code to capture every turn, its token counts, its tool calls and its timings, you are rebuilding something that both Pydantic AI, through Logfire, and the OpenAI Agents SDK give away. That work is not interesting and it is not differentiated.

Is structured output an orchestration problem?

No, and confusing the two is why some teams adopt an agent framework to solve a validation problem.

Pydantic AI's documentation is explicit about what it is selling, describing the goal as bringing the FastAPI feeling to agent development, moving entire classes of errors from runtime to write time, and guaranteeing that the response conforms to the declared output type. It also supports streaming structured output with immediate validation, and passes dependencies through a typed run context that the docs point out is particularly useful in tests and evals.

If your actual pain is that the model returns nearly valid JSON often enough to be unusable, that is the tool shaped like your problem, though it is worth reading the four ways of getting a model to hold a schema reliably before you adopt a library for it. It does not require you to give up your loop, and it composes with a hand written one. The general point holds beyond this one library: match the library to the specific responsibility that hurts, rather than adopting a whole architecture to fix one of six.

Is multi agent a real requirement or a shape people like?

Both, and the split between the two is worth being precise about because it decides an architecture, in the same way that the rung you buy decides what a support system can resolve.

Three of the projects here offer a different answer to the same question. The OpenAI Agents SDK models it as handoffs, agents exposed as tools so one can delegate to another, sitting alongside guardrails that validate inputs and outputs. The Claude Agent SDK models it as subagents, spawned for focused subtasks inside a single run. CrewAI models it as crews of role playing agents with autonomous collaboration and task delegation, which is the most elaborate of the three and the one that gives the pattern its name.

The genuine requirement looks like this: different steps need different tools, different system prompts, or different permission levels, and the outputs have to be combined. A research step that may read the web and a writing step that must not is a real separation, because the tool sets differ and the risk profiles differ.

The imagined requirement looks like a diagram of five named specialists passing a document around. That version usually performs worse than one agent with all the tools, because every handoff is a lossy summarisation step and every specialist has less context than the one before it. It also multiplies the token bill, since each agent carries its own system prompt and tool definitions.

The test is whether you can name what each agent is allowed to do that the others are not. If you cannot, you have named roles rather than designed boundaries, and one agent will do it better.

How do you leave a framework once you are in one?

This is the question worth asking before you enter one, and it is the reason the escape hatch column sits in the table above.

Three of the five projects make leaving straightforward by construction. LangGraph nodes are ordinary functions, so the logic survives even if the graph does not. The OpenAI Agents SDK states its Python first approach explicitly, using built in language features rather than new abstractions, which means the code you wrote is mostly ordinary code. Pydantic AI's output types and dependency injection are plain Python objects that outlive whichever loop calls them.

What does not travel is anything expressed in the framework's own vocabulary. Persisted checkpoints in a proprietary format, role definitions that only mean something to one orchestrator, tracing tied to one vendor's backend: those are the parts you rewrite. So the practical discipline is to keep your business logic in functions the framework calls, rather than in configuration the framework interprets. If a step is a function that takes typed input and returns typed output, it works anywhere. If it is a YAML role description, it works in one place.

That is also the honest reason the write it yourself default is not stubbornness. It produces exactly the artefact you would want to keep if you later adopted a framework, which means the cheap path and the reversible path are the same path.

Where should the tool layer sit?

Outside whatever you choose, which is the one architectural decision here that is genuinely hard to reverse.

Tools defined inside a framework's own abstraction move with that framework. Tools exposed over a documented protocol do not. Every project in the table above can consume tools over the Model Context Protocol, which means the same tool server serves a hand written loop today and a framework next quarter with no rewrite. We covered the mechanics of setting one up in a guide to running your first MCP server, and the tools MaShop exposes are listed on our MCP page.

The cost side of the decision is also worth pricing before you commit. Every framework adds tokens you did not write, through its own system prompt scaffolding and tool descriptions, and those are billed as input on every turn. The method for measuring that is in our breakdown of what a real feature costs once every token category is counted, and it is worth running against a framework before and after adoption rather than assuming the overhead is small.

How do you decide, in one sitting?

Answer four questions honestly and the choice usually makes itself.

Does a run need to survive a restart? If yes, adopt a framework with persistence. If no, that is the biggest reason gone.

Does a human approve steps mid run? If yes, same answer, because it is the same problem.

Do you need several agents with distinct roles passing work between them, today, not hypothetically? If yes, look at the projects built around that. If it is hypothetical, ignore it, because a single agent with more tools solves most of what people imagine multi agent systems for.

Is your real pain validation rather than control flow? If yes, take a typed output library and keep your loop.

Four noes means writing about forty lines and moving on. And whichever way it goes, the thing that determines whether the agent is any good is not the framework. It is whether you can tell that a change made it better, which is a measurement problem we took apart in a guide to evaluating an LLM feature without a leaderboard. A hand written loop with a real evaluation beats a well chosen framework without one, every time.