- An agent is a raw model plus a loop that lets it call tools, keep state, and decide the next step. You can write that loop yourself or adopt a framework that supplies it along with orchestration, tool integration, memory, planning scaffolding, and observability. The value of a framework is not reinventing the loop each time.
- The space is young and churns fast, so reason by category, not by vendor: code-first orchestration frameworks, low-code and visual builders, and managed or hosted agent platforms. Every framework charges an abstraction tax in lock-in and a debugging layer between you and the model, and that tax starts to hurt exactly when you most need to see through it.
- Underneath every framework sit the same primitives: tool-calling, memory, and planning. Learn those and you can evaluate any framework on its merits, drop to a thin do-it-yourself loop when that is the better trade, and avoid being captive to a vendor whose abstractions may not outlive next year.
Build your own or adopt a framework
Strip an agent down and it is unglamorous: a model, a loop, and a way to give the model tools and feed the results back. The loop calls the model, the model asks to call a tool, your code runs the tool and returns the output, and the loop calls the model again until it decides it is done. That is the whole mechanism. You can write it yourself in a couple hundred lines, or you can adopt a framework that ships that loop for you along with a great deal of surrounding machinery. This is the first real fork on the agent build path, and it is worth taking deliberately rather than by reflex.
The reflex, right now, is to reach for a framework, because that is what "building an agent" has come to mean and because the ecosystem markets hard in that direction. But the honest starting position is that both options are legitimate, and which one wins depends on the agent, not on fashion. A framework saves you from rebuilding the loop and its scaffolding every time. A thin hand-rolled loop keeps you close to the model with nothing in the way. Neither is the grown-up choice by default.
What makes this decision awkward is the state of the field. Agent frameworks are young and they churn: APIs shift between minor versions, abstractions that looked canonical are deprecated a few months later, and the shortlist of what is credible is not the same shortlist it was a year ago. Betting your architecture on any single named tool is betting on a fast-moving target. So the useful move for an architect is to stop reasoning by vendor and start reasoning by category. Vendors come and go; the categories, and the trade-offs each one carries, are stable enough to design against. The rest of this piece is that category map, and the primitives that let you read it.
What a framework gives you
The case for a framework is straightforward once you have written the loop by hand a few times: the loop is the easy part, and everything around it is the work. A framework earns its place by supplying that surrounding machinery so you do not rebuild it per project. Five capabilities cover most of what the credible ones provide, and it is worth naming them precisely because they are also the checklist you use to judge any framework, or to size what you would owe if you skipped one.
| What it provides | What it saves you from |
|---|---|
| Orchestration | Hand-writing the act-observe-replan loop, retries, and control flow every time |
| Tool integration | Wiring each tool's schema, invocation, and result parsing by hand |
| Memory | Building state and context handling from scratch across turns and sessions |
| Planning scaffolding | Structuring decomposition and multi-step reasoning yourself |
| Observability | Instrumenting every step so a run is inspectable and debuggable |
Read the right column, because that is the actual value. A framework is not offering you intelligence, the model supplies that. It is offering you the plumbing that turns a model into a running, inspectable system: the loop and its retries, the glue that presents tools in a form the model can call, a place to keep state between steps, some structure for multi-step work, and the tracing that lets you see what happened after the fact. On a single simple agent, none of this is much. Across a portfolio of agents built by different teams, rebuilding it every time is exactly the waste a framework exists to remove.
The observability line deserves a flag, because it is the one teams undervalue up front and miss most in production. An agent that decides its own steps is only trustworthy if you can see the steps it took, and standing up that tracing yourself is real work. A framework that gives it to you for free is providing something genuinely load-bearing, not a convenience.
The categories
Because the vendors churn, the durable way to hold this market is as three categories, distinguished by how much of the stack you own and how much the tool owns for you. They are not a ranking. Each is the right answer for a different combination of skill, control, and speed, and the interesting failures come from picking the category that does not match your constraints.
- Code-first orchestration frameworks. Libraries you program against in a general-purpose language. You keep control of the loop, the tools, and the deployment; the framework gives you primitives and structure. Highest ceiling and highest control, at the cost of writing and owning code. This is where engineering teams with real requirements tend to land.
- Low-code and visual builders. Drag-and-drop or config-driven canvases where you assemble an agent from blocks without writing much code. Fast to a working prototype and open to non-engineers, at the cost of a ceiling: you can build what the canvas exposes, and hit a wall where it does not. Strong for well-shaped internal use cases and for letting domain owners iterate.
- Managed or hosted agent platforms. A vendor runs the loop, the tools, the memory, and the infrastructure; you configure and consume it, often through an API or console. Least to operate, fastest to production for standard shapes, and the most lock-in, since the agent lives inside someone else's runtime and moving it out is a rebuild.
The categories sit on a single axis, which is why holding them together is more useful than memorizing tool names: as you move from code-first to hosted, you trade control and portability for speed and reduced operational load. Where you want to sit is a function of your constraints, not the market's enthusiasm. A team with strict data-residency rules and unusual tools belongs at the code-first end; a team that needs a standard retrieval agent live next quarter may be right to buy the hosted version and move on.
This is the same build-buy-orchestrate decision the Atlas draws for the wider stack in the platform landscape. Agent frameworks are one slice of that larger picture, and the reasoning transfers: decide by category and constraint, treat any specific vendor as replaceable, and design so that a category choice is not an irreversible one.
The abstraction tax
Every framework speeds you up by hiding things, and everything it hides is something you no longer see directly. That is the abstraction tax, and it is not a reason to avoid frameworks, it is a cost to price honestly. The same abstraction that saves you from writing the loop also stands between you and the model, so when behavior goes wrong you are now debugging two things: the model's decision and the framework's interpretation of it. The prompt the model actually received, the exact tool schema it saw, the order of the messages, all of it is now mediated by a layer you did not write and may not fully understand.
The tax has three components, and they compound. The first is abstraction distance: the framework's mental model may not match the model's actual behavior, so you reason in the framework's terms while the failure lives in the model's. The second is lock-in: the more of your logic you express in a framework's constructs, the more expensive it is to leave, and in a market this young, the thing you built on may itself be deprecated before you are done. The third is the debugging layer: when a run misbehaves, you must first peel back the framework to see what the model was actually asked and actually answered, and a heavy framework makes that peeling slow.
None of this argues for purity. It argues for weighing the tax against what the framework returns. Early, on a standard agent, the machinery is worth far more than its cost and you should take it gladly. Later, on an agent with unusual requirements or one you must debug under pressure, the same abstraction that accelerated you can become the thing you are fighting. The discipline is to notice the crossover rather than defend the original choice, and the way you keep the option to notice it is by understanding what sits underneath.
When build-your-own wins
For a whole class of agents, the right framework is no framework: a raw model, a thin loop you wrote, and nothing in between. This is not contrarianism. When the agent is simple, when you need full control over the prompt and the tool calls, or when you are unwilling to bet on a framework that may churn under you, the do-it-yourself loop is straightforwardly the better trade. You give up the surrounding machinery, but for a simple agent that machinery was overhead, and what you get back is a system with no layer between you and the model.
FRAMEWORK PATH DO-IT-YOURSELF PATH ------------------ -------------------- your goal your goal | | framework abstractions your ~200-line loop | | framework's loop call model -> tool -> repeat | | +--> model +--> model + orchestration, memory, + full control, no lock-in, tools, observability nothing between you & model out of the box - abstraction tax, - you build the scaffolding lock-in, churn risk yourself as you need it
The build-your-own case is strongest at the low-autonomy end of the agentic spectrum, where the loop is short and the tool set is small and known. A tool-using agent with three tools and a bounded loop does not need an orchestration framework; it needs a hundred lines and clear eyes. It is also strong when control is non-negotiable: regulated contexts where you must be able to state exactly what the model was sent, or performance-sensitive paths where you cannot afford a framework's overhead in the hot loop.
The honest counterweight is that build-your-own scales with complexity into rebuilding a framework badly. The moment you find yourself adding retry logic, then a memory store, then tracing, then a planning structure, you are reconstructing exactly what a framework gives you, and doing it as a side project. The decision is therefore not permanent. Start thin, and adopt a framework when the scaffolding you keep hand-rolling has grown into a framework's worth of surface. Knowing the primitives is what lets you make that move on your own terms rather than a vendor's.
Know the primitives
Here is the through-line that survives every churn cycle: no matter which category or vendor you choose, underneath the abstraction sits the same small set of primitives. Frameworks package them differently, name them differently, and hide them to different degrees, but they do not invent new ones. Learn the primitives and you can read any framework as an arrangement of things you already understand, judge what it does well and badly, and reproduce the essential parts yourself if you ever need to. That knowledge is the opposite of capture.
Three primitives carry most of the weight, and the Atlas treats each in its own right. Tool-calling is how the model reaches outside itself to act and to fetch information, and it is the mechanism every agent framework is ultimately orchestrating; the tool-calling deep-dive covers the schema, the invocation, and the failure modes. Memory is how state persists across steps and sessions so the agent is not amnesiac between turns, and the agent memory deep-dive covers what to keep, where, and for how long. Planning is how a goal becomes an ordered sequence of steps, whether the model does it implicitly or you scaffold it explicitly.
This is why the primitives, not the frameworks, are what the Atlas spends its depth on. Frameworks are the fashion layer, and the fashion layer moves. The primitives are the physics, and the physics holds. An architect who has internalized tool-calling, memory, and planning can pick up a framework nobody had heard of last quarter, understand it in an afternoon, and put it down again without regret when it churns. That fluency, more than any single tool choice, is what keeps you free.
The architect view
The framework question is not "which one," it is "how much abstraction do I want between me and the model, and can I afford to change my mind later." Answer that well and the specific tool matters far less than the market's noise suggests. Answer it by reflex, adopting the loudest framework because it is the loudest, and you inherit its abstraction tax and its churn risk on an agent that may not have needed either.
Four commitments carry the discipline, and they belong in the design phase, not in the post-mortem:
- Choose by category and need, not by vendor. Decide first whether the agent wants a code-first framework, a low-code builder, a hosted platform, or no framework at all, and derive that from your constraints on control, skill, and speed. Treat any named tool inside the chosen category as replaceable.
- Prefer thin over heavy. Start with the least abstraction that solves the problem, often a raw model and a small loop, and adopt heavier machinery only when the scaffolding you keep rebuilding has grown into a framework's worth of surface. Weight is a cost you justify, not a default you assume.
- Learn the primitives, not the framework. Invest your depth in tool-calling, memory, and planning, because those survive every churn cycle. A team fluent in the primitives can evaluate, adopt, and abandon frameworks on its own terms rather than a vendor's.
- Design for churn. Assume the framework you pick will change or fade, and keep your agent's core logic expressed in terms you own so a swap is a migration, not a rewrite. The market is young; plan for it to keep moving.
None of this is a counsel against frameworks. The good ones remove real, repetitive work and hand you observability you would otherwise have to build, and for most standard agents adopting one is the correct and unremarkable choice. The point is to adopt from strength: knowing what the framework does for you, what it charges in return, and how to leave if the trade turns. Place the framework decision inside the larger design, on the same axis the platform landscape maps for the rest of the stack, and it stops being a bet on a vendor and becomes one more deliberate placement. To feel the difference between a framework and a thin loop rather than read about it, the Agent Studio in the Lab lets you build the same agent both ways and watch what each costs you in control and in convenience.