Do You Even Need an Agent Framework?

Most agent guides are wrong about frameworks. They present adopting one as the obvious first step, as if writing an agent without LangGraph or CrewAI were reckless. The truth is closer to the opposite: a large share of agents in production are a few dozen lines of plain code, and reaching for a framework first often adds more complexity than it removes. The agent framework vs no framework question deserves an honest answer, not a default.

Let me tear down the reflex, then draw the real line.

Before: The Agent Framework vs No Framework Instinct

The common instinct goes like this. You decide to build an agent, you Google how, and every tutorial opens with "first, install this framework." So you do. You spend day one learning the framework's abstractions — its way of defining agents, its state objects, its decorators — before you've written a single line of your actual logic.

Framework-first path:
  day 1: learn the framework's concepts and API
  day 2: fight the framework's opinions to fit your case
  day 3: finally start on your actual problem

What this does: it shows where the time goes. Two days spent on framework overhead before touching the problem you set out to solve. Sometimes that investment pays off. Often, for a simple agent, it never does — you've learned an abstraction to avoid writing forty lines.

And the framework rarely fits your case perfectly out of the box, so day two often goes to bending its opinions to your problem — the classic tax of any abstraction that assumed a slightly different use case than yours.

Why It Fails

The framework-first instinct fails for simple agents because it front-loads a cost you may never recoup. A basic agent — a loop, a few tools, a stop condition — is genuinely small. You saw in earlier guides that the core loop is about fifteen lines. Wrapping that in a framework means learning the framework's version of concepts you could have written directly, plus inheriting its dependencies, its upgrade cycle, and its opinions about how your agent should be shaped.

Multiply that across a team and the abstraction becomes something everyone has to learn before they can contribute — a real cost for a simple agent and a real benefit for a complex one. The same feature, priced differently by context.

It also fails silently in a specific way: it hides the mechanics you most need to understand. When your framework-based agent misbehaves, you're debugging both your logic and the framework's abstraction over it, without a clear view of the loop underneath. People who never built one raw often can't tell which layer is broken.

And the cost isn't only time. Every framework you adopt is a dependency you now track — its releases, its breaking changes, its security patches, its eventual maintenance-mode surprise. For a forty-line agent, you've traded code you fully control for a dependency you only partly do. Sometimes that trade is right. For a simple agent, it rarely is.

⚡ Pro tip: Build one agent from scratch before you ever touch a framework, even if you plan to use one. Understanding the raw loop is what lets you debug the framework's abstraction of it later, instead of treating the whole thing as a black box.

After: Drawing the Real Line

Frameworks aren't bad — they're a trade, and the trade is worth it past a clear threshold. Here's the honest split.

No framework wins when:
  - single agent, a handful of tools
  - you control the loop and want to see every step
  - the task is stable and small

Framework wins when:
  - multiple agents coordinating
  - you need durable state / resume-after-crash
  - you need built-in tracing, retries, human-in-the-loop
  - a team will maintain it and needs shared structure

What this does: it replaces "always use one" with a decision. The left column is where raw code is cleaner and faster to reason about. The right column is where a framework earns its complexity by giving you real infrastructure — observability, durability, coordination — that you'd otherwise have to build and maintain yourself.

The honest framing is that a framework buys you infrastructure, and infrastructure is only worth buying when you'd otherwise have to build it. Nobody writes their own web server anymore because that infrastructure is deep and shared. Agent frameworks aren't quite there yet for simple cases — the "infrastructure" of a basic loop is small enough to own. It's the durability, tracing, and coordination layers that are deep enough to be worth outsourcing.

⚡ Pro tip: Name the specific capability pulling you toward a framework — durability, tracing, or coordination — and confirm raw code can't cheaply provide it. If a small library covers it, you may not need the framework at all.

⚡ Pro tip: The clearest signal you've outgrown raw code is when you start writing your own retry logic, your own state persistence, and your own tracing. At that point you're building a framework by hand, and adopting a real one is the smarter move.

Breaking Down Each Element

Observability is often the first real reason to adopt a framework. A raw agent needs you to add logging by hand; mature frameworks ship tracing that shows every step, tool call, and decision. Once you're running agents you can't easily watch, that built-in visibility is worth a lot.

There's a middle path people forget: you can add a standalone tracing or logging library to raw code without adopting a whole framework. If observability is the only thing pulling you toward a framework, buy just the observability.

Durability matters for long-running agents. If a run can take minutes and might crash partway, checkpointing and resume-after-failure are hard to build well yourself, and frameworks that offer them save real pain.

Coordination is the big one. The moment you have multiple agents handing work to each other, the plumbing gets genuinely complex, and a framework's orchestration is usually worth more than the loop it replaces. Single-agent jobs rarely cross this line; multi-agent jobs almost always do.

This is the cleanest dividing line of the three. One agent, however many tools, usually stays comfortable as raw code. Two or more agents coordinating is where hand-rolled plumbing turns into a second project, and where a framework's orchestration stops being overhead and starts being the point.

⚡ Pro tip: Adopt a framework for the feature you're missing, not for the loop you already have. If you only need tracing, you might add a tracing library to raw code and skip the framework entirely — buy the specific capability, not the whole platform.

Variations for Different Contexts

A solo developer shipping a single-purpose agent is usually better off with raw code plus maybe one small library. Less to learn, less to break, full visibility.

A team building several agents that share patterns benefits from a framework's shared structure, because consistency across engineers matters more than the raw-code savings on any one agent.

An enterprise with compliance and durability requirements almost always wants a framework, because building auditable, resumable, observable agents by hand is a project in itself — the framework is cheaper than the infrastructure it replaces.

A researcher or hobbyist experimenting to learn should almost always go raw first, precisely because the goal is understanding. A framework that hides the loop defeats the purpose when the purpose is to see the loop. Save the framework for when you're shipping, not when you're learning.

⚡ Pro tip: Factor in who maintains the agent, not just who builds it. Raw code that one author understands perfectly can become a liability when handed to a team; a framework's shared conventions are sometimes worth adopting purely for maintainability.

Save and Reuse This

The agent framework vs no framework decision isn't ideological. Raw code wins for single, small, stable agents where you want to see every step. Frameworks win when you need coordination, durability, tracing, or team-wide structure. The mistake is defaulting to a framework before you know which side of the line you're on.

A good rule: earn your framework. Start raw, ship if you can, and let the framework be the answer to a specific pain you actually felt — a crash you couldn't recover from, a trace you couldn't reconstruct, a second agent you couldn't cleanly coordinate. Frameworks adopted to solve felt problems get used well; frameworks adopted preemptively mostly get fought.

⚠️ Common mistake: Adopting a heavyweight framework on day one for a simple single-agent task, spending days on its abstractions, and ending up with more complexity than the forty lines of code the job actually needed. Start raw, feel where it strains, and adopt a framework to fix that specific strain — not to prevent an imagined one.

The prompts and tool descriptions that drive your agent sit above this decision entirely — they're the same whether you run raw code or a framework. PromptABCD keeps them versioned and reusable, so if you start framework-free and later migrate, or move between frameworks, your prompts survive the transition untouched.