autonomous-loop-patterns
Autonomous Loop Patterns
Concept Card
What it is: Autonomous loop patterns are reusable control shapes for running an agent repeatedly until an explicit stop condition is reached. They define how a session continues, stops, checkpoints, respawns, and avoids runaway behavior.
Mental model: A loop has five primitives: a trigger, a worker session, a progress signal, a stop condition, and a safety cap. Ralph Wiggum puts the stop condition in a Stop hook and completion word. Manage-loop puts it in a continuation signal. Grind-loop puts it in an external supervisor that respawns fresh sessions based on status files and exit outcomes.
Why it exists: Without named loop patterns, agents invent ad hoc respawn logic that has no checkpoint, no cap, and no clear owner for recovery. These patterns let the system choose the smallest loop that can safely finish the work.
What it is NOT: It is not command selection, task execution, inter-agent messaging, or budget steering. Those are handled by ai-coding-agents, task-execution, agent-to-agent, and agent-control.
Adjacent concepts: Hook patterns provide lifecycle intercepts, loop infrastructure provides checkpoint mechanics, agent control provides steering and abort signals, and observability provides evidence that a loop is progressing.
One-line analogy: Autonomous loop patterns are autopilot modes: each mode keeps moving, but each needs instruments, altitude limits, and a clear handoff back to the pilot.
Common misconception: A loop is not safer because it can run forever. A safe autonomous loop is defined by when it stops, what it persists, and how it proves progress between iterations.
Domain Context
More from jacob-balslev/skills
layout-composition
Use when deciding responsive page or screen structure: section order, scan pattern, grid/flex composition, breakpoints, viewport hierarchy, responsive media, and density. Do NOT use for user-goal decomposition (use `task-analysis`), navigation taxonomy (use `information-architecture`), visual polish (use `visual-design-foundations`), or component/token contracts (use `design-system-architecture`).
8context-graph
Use when designing or auditing the multi-graph context architecture of an AI-coding workspace: skill graph, document routing graph, memory index, script registry, and the cross-graph edges between them. Covers edge typing, orphan detection, connectivity health, deterministic graph synthesis signals, change-propagation checks, and drift or hub-and-spoke anti-patterns. Do NOT use for authoring one SKILL.md (use `skill-scaffold`), validating one skill (use `graph-audit`), live routing decisions (use `skill-router`), context-window budgeting (use `context-window`), or session load/drop choices (use `context-management`).
8visual-design-foundations
Use when designing or auditing visual craft: color palette, typography, spacing, elevation, rhythm, density, visual hierarchy, brand fit, contrast intent, and motion feel. Do NOT use for sign-system meaning (use `semiotics`), token/component architecture (use `design-system-architecture`), responsive structure (use `layout-composition`), or accessibility compliance (use `a11y`).
7project-knowledge-extraction
Use when extracting durable project knowledge from code, docs, issues, incidents, reports, screenshots, or conversations into reusable context such as skills, ADRs, glossaries, context docs, or memory. Do NOT use for writing a new skill contract (use `skill-scaffold`), maintaining library tooling (use `skill-infrastructure`), or generic documentation polish (use `documentation`).
6problem-framing
Use when a team is converging on solutions before agreeing on the problem, when a brief reads as a feature request, when symptoms and root needs are tangled, or when assumptions need surfacing before design work proceeds. Do NOT use for code-level bug triage, runtime failure diagnosis, or root-cause analysis of system errors — those are engineering investigation tasks, not design problem framing.
6ai-native-development
Use when reasoning about agent autonomy levels, designing auto-improve loops, evaluating AI-generated code quality, or measuring agent productivity in an LLM-assisted codebase. Covers Karpathy's three eras of software (1.0 explicit / 2.0 learned / 3.0 natural-language), the vibe-coding-vs-agentic-engineering distinction, the 0–5 autonomy slider with task-type recommendations, the one-asset / one-metric / one-time-box AutoResearch loop, Software 3.0 productivity metrics, and the documented quality regressions of ungated AI-generated code (the 'vibe hangover'). Do NOT use for choosing a specific autonomy-loop topology (use `agent-engineering`), for the per-prompt authoring discipline (use `prompt-craft`), or for reviewing the AI-generated code that comes out of a Software 3.0 workflow (use `code-review`).
6