L/A/B — Loop Agent Builder

What should your agent do?

Pick a starting point, then describe the goal in one sentence. Everything technical gets safe defaults you can review at the end.

Start from a template

Goal (one sentence: what should be true when it's done?) How do you check your project works? (this becomes the agent's test)

Add project documents (optional)

.md, .txt, .json, .yaml — summarized in your browser, not uploaded anywhere

It's finished when… (edit freely — each line should be checkable)

When should it run?

The decisive question: are you at the keyboard while it runs?

Run mode

Which tool will run this agent?

Claude Code Codex Both / not sure

This decides the file format and your setup steps at the end.

Can it use your GitHub?

Yes — needed for PRs, issues, and schedules that run on GitHub's servers

Project folder (where scheduled runs start)

Safety limits

Review & download

Everything below ships in the ZIP. Anything marked "change" can be fine-tuned.

Your loop

Files it will create

Show files

Human-in-the-Loop Checklist (you remain accountable for the output)

1. Review the Diffs — look at every change before merging. The loop proposes; you decide. 2. Resolve "NEEDS-HUMAN" Notes — fix blockers the loop flagged before restarting it. 3. Check the Cost — run /usage or /cost after runs to watch spending.

What to do next

Pillar I — The Objective & "Heartbeat" Engine

The heartbeat transforms a one-off run into a recurring loop. Define your objective, derive verifiable success metrics, and choose the primitive that drives the loop.

Objective Ingestion

High-level objective

Loop name (kebab-case, used for command & skill names) Target repository / directory (optional)

Verifiable Success Metrics (3–5 required — each must be checkable by a command or condition)

Heartbeat Selection Matrix

The system recommends a heartbeat from your objective. You can override it.

In-Session /loop

Active monitoring of long test runs and deploys.

⚠ Stops when the terminal/session closes.

Run-Until-Done /goal

Complex tasks requiring turns until a condition is met.

Uses a separate judge model (e.g. Claude Haiku).

Scheduled cron / Routines

Morning triage, dependency audits, daily briefings.

Exports local cron syntax and GitHub Action YAML.

Event-Driven Channels / Webhooks

Reacting to PR opens or GitHub issues.

Real-time response via MCP connectors.

Unattended operation — background autonomy (vs. in-session active monitoring). Tightens default guardrails.

Pillar II — Infrastructure & Isolation

Isolation is the prerequisite for parallel agentic work: it prevents file collisions and repository-history corruption.

Isolation Configurator — Repository State Detection

Paste the output of git worktree list (and optionally git status -sb) and the configurator will detect your state — or declare it manually.

Paste git worktree list output (optional)

Isolation state: No worktree isolation yet — generate init commands Clean worktree environment already present Run in main checkout (no isolation — single loop only)

Loop branch name Parallel sub-agent threads

Connector (MCP) Integration

Enable autonomous action through Model Context Protocol connectors. Keys are mapped as environment-variable references — never stored in generated files.

GitHub

PR management, issues, CI status

GITHUB_TOKEN

Linear

Ticket updates & triage

LINEAR_API_KEY

Playwright

Independent UI verification

—

Write key references into: .claude/settings.json env block .env file (+ .env.example)

Pillar III — The Knowledge Layer (Skills & Prompt Generation)

Prevent "Goldfish Syndrome" — agents restarting with zero context — by codifying project knowledge into persistent, validated Skills.

SKILL.md Generator

Skill name

Intent (required metadata — when should an agent invoke this skill?) Tool-use instructions (required — specific commands the agent must run)

Reference Library

Upload proprietary documentation (internal API specs, runbooks). Each document is summarized into the skill's metadata section so the agent starts every run with context.

.md, .txt, .json, .yaml — summarized client-side (or via LLM if configured)

Tiny Prompts

To reduce token bloat and maintenance friction, the system generates single-line invocations instead of large instruction blocks.

Pillar IV — The Maker–Checker & Verification Split

Adversarial Code Review: the model that writes the code must never be the one that grades it.

MAKER — Implementer

Model Reasoning effort

Extra instructions (optional)

CHECKER — Adversarial Reviewer

Model (must differ from maker) Reasoning effort

Reviewer independently runs Playwright UI verification Include security-review pass (high-effort)

Decision Justification (prevention of cognitive surrender)

Require agents to document why each architectural choice was made in the Spine's Decision Log. Keeps the human the engineer.

Output Format

Markdown → .claude/agents/ (Claude Code) TOML → .codex/agents/ (Codex) Both

Pillar V — The Spine, Reliability & Guardrails

The Spine (progress.md) is the persistent state file that lets the loop survive between runs. Deterministic guardrails prevent Loop Drift.

Spine File

progress.md AGENTS.md

Schema: status tracking (in-progress / completed / failures flagged), decision log, and the NEEDS-HUMAN escalation flag.

Defensive Parameters

max_iterations hard turn limit — prevents infinite cycles max_spend ($) hard dollar limit — controls financial liability similarity_threshold Jaccard similarity vs prior 3 turns — detects repetition max_minutes temporal cap on background execution

Escalation & Termination Logic

Verification-failure repeats before NEEDS-HUMAN

Context Maintenance Routine

Append a Context Maintenance Routine to CLAUDE.md — guides the agent to use /compact or /clear to manage token bloat while relying on the Spine for long-term memory.

Structured Output & Implementation Guide

The deployable file structure is the primary deliverable. Review every file, then export.

Export Manifest

Loop design backup:

—

Human-in-the-Loop Checklist (mandatory audit — you remain accountable for the output)

1. Review the Diffs — manually audit code changes before merging. The loop proposes; you decide. 2. Verify "NEEDS-HUMAN" Notes — resolve blockers the loop could not handle before restarting it. 3. Usage Auditing — run /usage or /cost to monitor for Shadow Costs incurred by sub-agents.