The Bare LLM API Is a Stateless Function; an Agent Harness Gives It Memory, Hands, and a Loop
The gap between a powerful model and a useful coding agent is entirely engineering, not model capability. Understanding the harness as a system of decoupled organs lets teams build agents that survive real-world chaos, swap providers without rewrites, and enforce constraints like keeping source code local while still using the strongest cloud models.
Calling an LLM API directly gives you a pure function: text in, text out. It cannot remember previous turns, cannot read files or run commands, and stops after one response. These three limitations prevent it from completing any real multi-step task like fixing a bug. The engineering system that patches these gaps is called a Harness. It stores conversation history to simulate memory, provides tools the model can invoke to take real action, and wraps everything in an Agent Loop that cycles through think-act-observe until a goal is met. The model is the engine; the harness is the chassis, transmission, and steering that let it drive. A production harness like the catbuddy project splits these responsibilities into six decoupled organs—heart, hands/feet, eyes, memory, resilience, and advanced capabilities—each responsible only to its interfaces, so changes stay locked inside one module.
Stronger models increase the burden on the harness, not decrease it, because they invite longer, riskier tasks that demand more robust loops, context management, and error recovery.
The local-first architecture—using your own API key to cloud models while keeping all file operations local—is an under-explored middle path between pure-cloud tools and weak local models.
Decoupling organs by interface rather than implementation is what lets a harness both run in production and absorb new features without cascading breakage.