What Is an Agent Framework? – Definition and How It Works
Learn what an agent framework provides, which parts it standardises, how single-agent and multi-agent designs differ, and when to build without one.
An agent framework supplies the scaffolding around a language model that turns it into something which plans, calls tools, and iterates: the loop, the tool interface, state handling, and observability.
1. What an Agent Framework Provides
The parts every agent needs, so they are not rebuilt per project.
| Component | Role |
|---|---|
| Loop | Observe, decide, act, repeat, with a stop condition |
| Tool interface | Schemas, validation, and dispatch |
| State | What persists between steps and between runs |
| Routing | Which model or agent handles which step |
| Tracing | A record of every observation and action |
| Guardrails | Step caps, budgets, and output validation |
2. Single-Agent and Multi-Agent Designs
Single agent — one model with a tool set and a loop. Simple to reason about, easy to trace, and sufficient for most tasks.
Multi-agent — several specialised agents coordinating, usually through a supervisor that delegates and collects results. Useful when subtasks need genuinely different tools, prompts, or models.
Multi-agent designs add coordination overhead and more failure modes. They pay off when specialisation is real, and not when it is merely tidy.
3. Where Frameworks Differ
- Control flow. Some express agents as graphs with explicit nodes and transitions; others hide the loop behind a higher-level abstraction.
- State model. Explicit, inspectable state is easier to debug than state carried implicitly in conversation history.
- Tool definition. Decorator-based, schema-based, or protocol-based discovery.
- Human checkpoints. Whether pausing for approval mid-run is a first-class feature.
- Persistence. Whether a run can be interrupted and resumed.
Explicit state and resumability are the two features that matter most once agents run longer than a single request.
4. What They Do Not Solve
- Compounding error. Per-step reliability multiplies regardless of framework.
- Tool quality. A vague tool description causes wrong calls no matter what wraps it.
- Untrusted input. Content an agent reads can be phrased as an instruction; authorisation must live in application code.
- Cost. Every step is an inference call, and frameworks make it easy to add steps.
5. When to Build Without One
For a single tool and a bounded loop, a short hand-written loop is often clearer than a framework: request, validate, execute, append, repeat, with an explicit cap.
Frameworks earn their place when you need several tools, persistent state, resumability, human checkpoints, or tracing across many steps — the point where hand-rolled code starts reinventing them.
6. Evaluating One
- Can you see and modify the loop, or is it hidden?
- Is state explicit and inspectable?
- Can a run be paused, inspected, and resumed?
- Is every model call and tool result traceable?
- Are step and budget caps first-class?
- How much work is it to leave?
7. Real-World Examples
- A research agent that searches, reads, and composes with citations.
- A coding agent that edits files, runs tests, and iterates on failures.
- A support agent that queries systems and either resolves or escalates.
- A collection agent that visits unfamiliar sites and extracts a defined field set.
8. Summary
An agent framework standardises the loop, tools, state, and observability around a model. Its value grows with the number of tools and the length of the run.
It does not fix compounding error, tool design, or untrusted input — those remain architectural problems, and a framework that hides the loop makes them harder to diagnose rather than easier.