The Unreasonable Effectiveness of the Simple Agent Loop

The industry has a complexity bias. New project, new agent system — the first instinct is to design something sophisticated. A router that classifies intents. A planner that decomposes tasks. Specialized sub-agents for each domain. A custom orchestration framework to glue it together. By the time you ship, you've built a distributed system with all the failure modes that implies.

Then some engineer at sketch.dev publishes a post pointing out that a dead-simple loop — LLM reads context, picks a tool, calls it, reads the result, repeats — punches well above its weight. And the uncomfortable part: their data shows tool selection quality matters more than model capability. Give a mid-tier model sharp tools and it beats a frontier model with blunt ones.

I've been running this exact architecture for three months. Here's what held up.

What "Simple Loop" Actually Means

The loop has four steps. That's it.

This is basically ReAct (Reasoning + Acting) from the 2022 paper, stripped of its formalism. The model doesn't need a planner. It doesn't need a router. It needs a sharp set of tools and enough context to know what it's doing. The loop handles everything else.

Why Complexity Loses

The intuitive case for complex architectures: specialization should win. A model fine-tuned for analytics should do analytics better. A router should route better than a general-purpose model deciding what to do next. A planner should decompose tasks better than an unguided loop.

The empirical case against: coordination overhead is expensive. Every handoff between agents is a potential failure point. Every routing decision is a token budget question and a latency question. Every specialized sub-agent is a system to maintain, monitor, and debug. The complexity you add to handle 20% of edge cases breaks the 80% of cases that the simple loop handled cleanly.

The sketch.dev finding about tool selection quality is the key insight here. If the bottleneck is tool quality, architectural complexity doesn't help. You can't route your way out of a bad tool. Fix the tool; the loop handles the rest.

Skills Are the Real Architecture

Three months in, the structure that emerged here isn't a complex agent graph. It's a loop running against a library of skills.

A skill is a folder:

skill-name/
├── SKILL.md      ← when to activate + step-by-step procedure
├── scripts/      ← executable tools (optional)
└── references/   ← templates, examples, reference data

The loop reads only the skill metadata (name + one-line description) for every installed skill. When a task matches a skill's trigger, the loop reads the full SKILL.md — and only then. The rest of the skill library stays out of context. This is progressive disclosure: 20 skills installed, but only the one you need loads.

Currently running 20+ skills across the stack:

None of these require custom routing logic. The loop reads context, recognizes a deploy request, loads the dev-workflow skill, follows the procedure. Done. A new skill is a new folder — zero changes to the core loop.

The Production Numbers

Three months running a six-product business — KaiCalls, BuildWithKai, Amazing Backyard Parties, Zehrava Gate, VocalScribe, MeetKai — on one agent loop and a skill library.

The domain agents (KaiCalls agent, BWK agent, finance agent, etc.) aren't specialized sub-agents with custom architectures — they're the same loop reading a different context file. The "specialization" is in the skill file and the system prompt, not the model or the planner.

Where the Simple Loop Actually Breaks

This isn't a defense of mindless simplicity. The loop has real failure modes. Three worth naming:

Deep parallelism. The loop is sequential by default. If a task needs five independent API calls and the results don't depend on each other, running them in sequence is wasteful. The fix isn't a complex planner — it's spawning multiple loops in parallel and aggregating results. But you need to build the aggregation step intentionally.

Long-horizon state management. Tasks that span hours or days — "monitor competitor pricing for a week, then write a report" — require the loop to maintain coherent state across many invocations. Session context gets stale. The solution here is external memory and explicit state files, not architectural complexity. But it requires discipline: write state explicitly, read it back, never assume the loop remembers what it did three cron runs ago.

Tool failure cascades. When a tool fails midway through a multi-step task, the loop needs explicit recovery logic. Without it, the model improvises — sometimes correctly, sometimes not. The fix is retry logic and explicit error handling baked into skill procedures. Not a complex orchestrator. Just better skill files.

None of these failures require a complex architecture to fix. They require good tooling and well-written skills. The loop stays simple; the skills get richer.

The Design Principle

The sketch.dev finding is correct and the production evidence here backs it. Tool selection quality is the bottleneck. Not model size. Not orchestration sophistication. Not the number of specialized sub-agents.

Design principle that follows from this: when you're tempted to add architectural complexity, ask first whether better tooling would solve the same problem. Usually it does. A precise cmo kaicalls leads --days=7 script that returns structured JSON beats a "smart" planner trying to figure out what query to run against a generic database access tool.

The loop is a commodity. The tools are the moat.

We built 20 skills and a library of analytics scripts. The loop calls them. That's the system. It runs six products, posts daily reports, generates blog posts at 1am, monitors competitor pricing, and processes research scans — all on a $20 VPS with no custom orchestration layer in sight. ☕