Loop engineering: design the system that prompts your agent, not the other way around

The prompt

Stop prompting the coding agent turn by turn. Instead, design a small system, a loop, that prompts it for you, checks the result, and decides what happens next. A loop needs:
1. A trigger that runs on a schedule or on demand and does discovery of what needs doing.
2. An isolated workspace, such as a git worktree, so parallel runs don't collide.
3. A documented skill or reference file so the agent doesn't re-derive your project's conventions from scratch every run.
4. A separate verifier step, a different agent or model pass, that checks the work against a concrete, checkable stop condition, instead of the same agent grading its own output.
5. A persistent state file outside the conversation, such as a markdown log or issue tracker, that records what's done and what's next, so the next run picks up where the last one stopped.

Example, a daily CI-failure triage loop:
Trigger: runs every morning.
Discovery: agent reads yesterday's CI failures and open issues, writes findings to PROGRESS.md.
Isolation: for each finding worth fixing, it opens a fresh worktree.
Fix: one agent drafts the fix.
Verify: a second agent checks the fix against the project's test suite and coding conventions before it's allowed to open a PR.
State: PROGRESS.md is updated with what was tried, what passed, and what's still open, so tomorrow's run continues instead of starting over.

Expected result

A running system that finds work, does it, checks it against a real condition, and remembers progress across runs, instead of you re-typing prompts every session.

Why it works

The value here is separating the agent that writes the code from the agent that verifies it, and writing progress to a file the agent re-reads instead of relying on conversation memory, which resets every session.