The No-Framework Agent
Building production-ready agents with just the LLM API and a while loop. When frameworks add overhead without value, and how to write a complete agent in about 100 lines of code.
Quick Reference
- →The core agent loop is: call LLM → check for tool calls → execute tools → feed results back → repeat
- →A production-ready agent without a framework needs: tool loop, retries, timeout, max iterations, error handling
- →Skip frameworks when: single provider, fewer than 5 tools, no complex state, no multi-agent coordination
- →Graduate to a framework when: you need checkpointing, human-in-the-loop, graph-based routing, or multi-agent
- →The 100-line agent outperforms framework agents on simplicity, debuggability, and startup time
When Frameworks Add Overhead
Frameworks solve real problems — state management, checkpointing, multi-agent coordination, provider abstraction. But if you don't have those problems, the framework is pure overhead: more dependencies, more abstractions to debug through, more concepts to learn, and more ways things can break. The majority of production agents are simple tool-calling loops that don't need any of this.
| Signal | Skip Framework | Use Framework |
|---|---|---|
| Provider count | One LLM provider | Multiple providers or need to switch |
| Tool count | 1-5 tools | 8+ tools needing routing |
| State complexity | Messages array is sufficient | Complex state with branching logic |
| Conversation persistence | Stateless or simple DB | Need checkpointing, time travel |
| Agent coordination | Single agent | Multiple agents collaborating |
| Human-in-the-loop | Simple approval gate | Complex interrupt/resume patterns |
| Team size | 1-3 developers | Large team needing shared abstractions |
In a survey of production AI systems, over 60% of 'agents' are single-model, single-provider tool-calling loops with fewer than 5 tools. A framework for these is like using React to build a static landing page — technically works, but the overhead isn't justified.