🛠 Technical Implementation

Claude Code has a built-in capability called the "loop skill" that teaches the agent to configure loops automatically.

It's the simplest starting point for loop engineering. A single prompt carries the entire system.

Loop skill as a capability. Initial prompt. Agent self-configuration.

A Markdown document with numbered tasks that the agent processes one by one, marking each as complete.

The quality of plan.md determines the quality of the output. Well-defined tasks = better results.

Ideal granularity. Acceptance criteria per task. Sequential vs. parallel order.

The prompt loads the loop skill and instructs the agent to process plan.md. The agent configures /loop on its own.

A good initial prompt is the difference between a functional loop and a chaotic one.

"Load the loop skill." Automatic /loop setup. A prompt as a system, not an instruction.

The agent completes a task, schedules the next wake-up via /loop, and continues until all tasks in plan.md are complete.

Seeing the actual workflow helps you understand how the primitives connect in practice.

Wake-up cycle. Validation between tasks. Prompt automatically generated by the agent.

A collection of copyable prompts for the most common scenarios: task runner, code review, and exploration.

Starting with tested prompts speeds up adoption and avoids common configuration mistakes.

Reusable templates. Adjustable parameters. Adaptation by context.

The basic loop runs in a single session, uses a single model, and has no external state. This limits scalability and reliability.

Understanding the limitations motivates the search for more robust solutions in the following modules.

Single session = context bloat. Single model = high cost. No state = no durability.

Archon is Cole Medin’s tool for orchestrating coding agent sessions with human-defined workflows.

Represents the opposite approach to a pure loop: the human defines the process, not the agent.

Harness vs. loop. Workflow file. Deterministic steps. Mix of providers.

Deterministic pipeline: extract the issue, find context, classify the type, research, implement, validate, and create a PR.

It's the most practical example of how to combine determinism with an LLM, using the agent only where it's really needed.

Pipeline as a graph. Deterministic vs. LLM-driven steps. Classification as a lightweight decision.

In a deterministic workflow, the human defines which steps exist and in what order. In a pure loop, the agent decides everything on its own.

Understanding this trade-off is essential to choosing the right approach for each scenario.

Reliability vs. flexibility. The agent as an executor, not a decision-maker.

Each workflow node can use a different model. Lightweight steps use cheaper models; critical steps use more capable models.

It's the main cost optimization lever in autonomous workflows.

Model routing. Cost per step. Provider mixing. Kimi for exploration, Claude for implementation.

Logs, runs, and conversations are recorded in Postgres/Neon. If the machine goes down, the workflow resumes at the exact step.

Durability is what turns an experiment into a reliable system.

State store. Resume from step. Neon branching for parallel workers.

Prompts optimized for each step: classification, research, implementation, validation, and code review.

Ready-to-use prompts save time and serve as a starting point for adapting to your context.

Template per step. Markdown as context. Handoff between steps via documents.

Open-source dashboard Cole built to manage loops with durability, observability, and human-in-the-loop.

Without visual control, loops are black boxes that burn tokens without feedback.

Dashboard as a nervous system. Open source on GitHub. Backend with Pi/Kimi.

All loops, events, and logs are recorded in Postgres (via Neon) for durability and analytics.

External state lets you resume loops after crashes and analyze execution patterns over time.

Orchestrator reads state from the database. Workers update state in the database. Database as the source of truth.

See in real time what decisions the orchestrator makes, how many workers it launches, and each round's progress.

Being able to see and understand the orchestrator's decisions is essential for debugging and improving the loop.

Decision log. Round history. Worker dispatch tracking. Event stream.

Metrics for tokens consumed per round, per worker, and total run cost. Visible in the dashboard.

Without cost tracking, optimization is impossible. The dashboard showed 1M+ tokens for a simple app.

Tokens per round. Orchestrator vs. worker costs. Breakdown by model.

The loop can pause after each round and wait for human approval before continuing.

HITL is the essential guardrail that prevents the problem of "run for a day, come back to crap."

Pause between rounds. Approve/reject workflow. Permission groups. Identity verification.

The dashboard can be deployed to the cloud via Retool, allowing remote access and sharing with the team.

Remote deploy turns a local tool into team infrastructure.

Import React into Retool. Connect to Neon. Permission groups. Audit trails.

Use different providers for different roles: cheaper models for orchestration, stronger models for implementation.

It's the main lever for reducing costs without sacrificing the quality of the final output.

Pi/Kimi as a low-cost orchestrator. Claude Code for execution. Codex for review.

Route tasks to models based on complexity: simple classification uses Haiku, complex implementation uses Claude.

Every token counts. Using Opus to classify a bug vs. a feature is wasteful.

Complexity-based routing. Cost per token by model. Lightweight vs. heavyweight decisions.

Keep state in an external database instead of accumulating it in the LLM context window. Each session starts fresh and reads the state.

Context bloat is the #1 cause of degradation in long loops. External state solves it.

Context window as cache. Database as storage. Stateless session. Read-execute-write cycle.

Git worktrees create isolated copies of the repo so N agents can work in parallel without code conflicts.

Real parallelism requires real isolation. Worktrees are the most practical mechanism for this.

One worktree per worker. One branch per task. Merge after validation. Port conflict avoidance.

Batch: accumulate tasks and process them all at once (cheaper). Real-time: process immediately (more responsive).

Choosing the wrong mode wastes money or time. Context determines the choice.

Batch for overnight GitHub issues. Real-time for urgent fixes. Latency vs. cost trade-off.

The three essential metrics: tokens consumed per task, orchestrator cost per round, and worker success rate.

What isn't measured can't be optimized. These metrics are the minimum needed to avoid waste.

Tokens/task as a KPI. Cost per round. Success rate. Trend analysis. Budget alerts.