Agent Looping

Shift from one-shot prompts to persistent loops that own discovery → planning → execution → verification — without the human driving every intermediate step.

Popularized in Jun 2026 discourse by @shannholmberg (10.5K bookmarks): "for the last two years we prompted agents one task at a time. that is starting to change." Source: X/@shannholmberg, 2026-06-08

The reviewed diagram adds the missing operating distinction. A single-agent loop runs discovery -> planning -> execution -> verification -> iteration by itself until it passes or ships. A fleet loop puts the same cycle under an orchestrator and fans it out to specialists and sub-agents. Whether the loop is affordable depends on open vs closed task shape: open-ended roaming burns tokens and only works with loose budgets; closed tasks have bounded goals, preset steps, eval gates, and a standard that improves across runs. Source: local X image artifact, 2026-07-03

One-shot vs loop

The loop is the shape Harness Engineering already describes (while loop + invariants). Agent looping names the product/UX shift: users configure the loop once instead of micromanaging turns. Source: compiled from Harness Engineering, 2026-06-12

Loop phases (typical)

1. Discovery — read repo, docs, errors, user context.
2. Planning — decompose goal; optional human-visible plan (Claude Code Harness Plan mode).
3. Execution — tools, edits, sub-agents.
4. Verification — tests, lint, doctors, eval scores (The Eval Loop (Slop Is an Output Problem), Security and Review Skills).
5. Iterate or exit — fix until invariants pass or budget exhausted.

Anthropic's managed-agents framing (Fable 5 + /loops, dynamic workflows, "dreaming") pushes the same direction for self-improving systems. The reviewed 13-minute demo makes the loop boundary concrete: longer task horizons require more autonomy, but also controlled access to credentials, internal systems, proprietary code, identity, and auth. The platform loop is agent definition, environment configuration, session execution, and event handling, with observability modeled through user, agent, session, and span events. Source: X/@0xCodez video artifact, 2026-07-03

Boris Cherny's WorkOS/Acquired interview gives the practical Claude Code version of the same idea: mature agent work shifts from writing prompts to writing loops. The durable unit is the workflow that reads context, runs tools, checks itself, and repeats under constraints. For Kevin, that means loop prompts belong in skills and doctors when they repeat; otherwise the agent learns the human's phrasing instead of the system learning the workflow. Source: X/@0xCodez, 2026-06-04; Source: WorkOS YouTube, 2026-06-04

Kevin stack connections

• Browser Testing Skills skill — worktree → implement → validate → browser → review → PR (human-supervised loop).
• Claude Code /goal Command — goal-directed autonomous execution within Claude Code.
• Hermes Agent (Nous Research) — cron + skills + memory as standing loops on Agent Machines.
• AI SDK HarnessAgent — embed mature harness loops (Claude Code, Codex) in apps with sessions + sandboxes.

Agency-in-a-company pattern

@shannholmberg documents building an agent company inside an agency (2,532 bookmarks): Source: X/@shannholmberg, 2026-06-04

Agency gBrain
  → Orchestrator Hermes Agent
    → Department verticals
      → Specialist agents
        → Scoped sub-agents

The local visual review adds the missing structure. The agency gBrain is maintained by a human champion plus an orchestrator Hermes agent; it reads transcripts, chats, past campaigns, client learnings, strategy docs, workflows, and examples of good output. The Hermes layer routes work and reads the brain. Department verticals (content, lifecycle email, technical SEO, paid ads) own specialist agents, and each specialist can call scoped sub-agents with one narrow job and a clear definition of done. Client pods isolate each customer's brain, orchestrator, specialists, workflows, approvals, and memory. Source: local visual review of X artifact, 2026-07-01

gBrain = company brain ingested with agency data and experience. Maps to Kevin's stack: Knowledge Brain System / wiki compiled truth as brain, Hermes Agent (Nous Research) orchestrator on Agent Machines, department skills as specialists. Same loop shape at org scale. The practical rule is "build one vertical well, then fork it to the next client at a higher starting point." Do not share raw client memory across pods.

Loop Engineering PDF

The Loop-Engineering-IEEE.pdf bookmark names the same shift at the system layer: prompt engineering is only one layer; loop engineering designs the system that discovers, hands off, verifies, persists, and schedules agent work. Its useful framing is that generation has become cheap while judgment remains scarce, so the loop must separate generator and evaluator roles instead of letting the same model declare its own output good. Source: X/@0xCodez, 2026-06-24; Source: local visual/PDF review, 2026-07-01

The PDF's caution list is more durable than the "Anthropic playbook" marketing frame:

• Verification debt — the loop produces more work than the reviewer can honestly check.
• Comprehension rot — humans stop understanding the system because the loop hides too much execution.
• Cognitive surrender — the operator accepts the agent's frame instead of keeping judgment.
• Token blowout — the loop becomes expensive because it never compresses, stops, or hands off cleanly.

Kevin's implementation rule: any recurring loop belongs in a skill, doctor, eval, schedule, or capsule only when it carries a harder evaluator than "the agent said it passed."

Design requirements

Loops without gates produce expensive slop. Minimum viable loop needs: stop conditions, verification hooks, budget caps, and observability (what did each iteration do?). See Agent Guardrails Architecture and The Eval Loop (Slop Is an Output Problem).

Omar Sanseviero's X Article makes the same constraint explicit from a research/startup angle: loop engineering is strongest for repeatable tasks with a clear goal or metric, not every open-ended agent workflow. The recovered source comments are useful because they name two concrete failure modes: retry loops that keep spending API calls after the environment is dead, and weak verifiers that check the transcript or another model's opinion instead of the produced artifact. The stop condition should evaluate the artifact that matters. Source: X/@omarsar0, 2026-06-19; Source: Digg mirror of X Article, 2026-06-19

Hermes' Kanban block-loop artifact adds a task-state rule: the loop should remember why it stopped. A blocked task needs a typed reason, recurrence count, and recovery path. dependency can auto-resume when parents finish; repeated same-cause blocks should escalate to a human; needs_input, capability, and transient should not all be treated as the same "retry later" state. This is a practical antidote to autonomous loops that unblock themselves and immediately recreate the same failure. Source: X/@Teknium and local artifact review, 2026-07-03

The Google Cloud Claude talk adds the system-design framing: the loop should carry its own prompting substrate. A good loop reads the right files, calls the right skills, checkpoints its state, and verifies its output without the human restating the same meta-instructions every turn. That is why Kevin's reusable flows should become SKILL.md files or doctors once they repeat. Source: X/@eng_khairallah1, 2026-06-06

---

Timeline

• 2026-06-30 | Added the Google Cloud Claude talk as evidence for "system prompts itself": loop quality belongs in files, skills, checkpoints, and verification, not repeated human prompt phrasing. Source: X/@eng_khairallah1, 2026-06-06
• 2026-07-04 | Source-reviewed Omar Sanseviero's loop-engineering X Article through a recoverable mirror; added the repeatable-task boundary, artifact-level verifier rule, and runaway-cost failure mode. Source: X/@omarsar0, 2026-06-19
• 2026-06-04 | Boris Cherny (Claude Code creator) on WorkOS: "I don't prompt Claude anymore. I write loops — and the loops do the work." Full episode linked in @0xCodez thread. 10,276 bookmarks. Source: X/@0xCodez, 2026-06-04
• 2026-06-04 | @shannholmberg agency hierarchy thread — gBrain → Hermes orchestrator → verticals → specialists → sub-agents. 2,532 bookmarks. Source: X/@shannholmberg, 2026-06-04
• 2026-07-01 | Deep-reviewed Shann's diagram artifact and expanded the agency-in-a-company pattern with human champion, Hermes routing, vertical specialists, scoped sub-agents, isolated client pods, and forkable verticals. Source: local visual review, 2026-07-01
• 2026-07-01 | Deep-reviewed Loop-Engineering-IEEE.pdf; added the generator/evaluator separation and loop failure modes: verification debt, comprehension rot, cognitive surrender, and token blowout. Source: X/@0xCodez, 2026-06-24
• 2026-07-03 | Deep-reviewed the Fable 5 / Claude Managed Agents self-improvement demo. Added the autonomy/access-boundary and event-topology reading to the loop phases. Source: X/@0xCodez, 2026-06-11
• 2026-07-03 | Added Hermes Kanban block-loop breaker: typed block reasons, recurrence counters, dependency auto-resume, and human escalation for repeated same-cause blocks. Source: X/@Teknium, 2026-06-26
• 2026-07-03 | Deep-reviewed Shann Holmberg's root agent-looping diagram and added the single-agent loop, fleet loop, and open-vs-closed cost boundary to the concept. Source: X/@shannholmberg, 2026-06-08; Source: local image artifact, 2026-07-03
• 2026-06-08 | @shannholmberg viral thread defining "agent looping" vs one-task-at-a-time prompting. 10,465 bookmarks. Source: X/@shannholmberg, 2026-06-08
• 2026-06-12 | Concept page created during full bookmark absorption pass. Source: User, 2026-06-12