Skip to main content

Agentic Prompt Loops

This method turns repeated agent prompting into a bounded loop contract.

Prompting is one pass. Loop engineering is the system that decides when the next pass starts, what it may touch, how it proves progress, and when it stops.

Inputs

  • A repeated job where the desired result is clear enough to check.
  • A trigger: schedule, hook, event, issue, command, or goal.
  • A state store outside chat context.
  • A verifier that can contradict the agent.
  • A budget for time, turns, tokens, model class, or fan-out.

Method

  1. Purpose. State the outcome the loop should improve, then choose the loop type: scheduled discovery, goal/run-until-done, hook-triggered, maker/checker, subagent fan-out, or skill-capture.
  2. Boundary. Define the trigger, input data, workspace, permission mode, source boundary, and decision rights.
  3. Context. Name the skill, issue, plan, memory file, queue, retrieval surface, and allowed tools the agent may use.
  4. Control. Set the verifier, maker/checker split when risk warrants it, stop condition, escalation rule, and budget cap.
  5. Proof. Write the report, receipt, issue comment, diff, status row, or evaluation result that the next run can read.

Loop Types

The taxonomy has seven named types so loop designers can classify before building; keep one primary type per loop contract.

TypeGood useAvoid when
Scheduled discovery loopNews, dependency drift, queue scans, recurring research.The source changes rarely or the action after discovery is unclear.
Goal/run-until-done loopA bounded objective with a verifier.Success depends on taste or hidden human judgment.
Hook-triggered loopA file, command, session, or tool event should trigger control.The hook cannot see enough context to decide.
Maker/checker loopQuality matters and review can be independent.The checker only repeats the maker's assumptions.
Subagent fan-out loopParallel scouts reduce uncertainty.Fan-out has no merge rule or cost cap.
Skill-capture loopA repeated human move should become reusable procedure.The procedure is still changing every run.
Mechanical feedback loopWork must feed a better next pass.The correction has no future reader.

Checks

  • The purpose names value, not activity.
  • The trigger is observable.
  • State survives outside the chat.
  • The verifier can fail.
  • Decision rights say act alone, ask first, escalate, and refuse.
  • The stop condition is exact enough for another agent to follow.
  • The budget is explicit.

Failure Modes

  • Runaway loop — no stop condition, weak verifier, or tool calls that keep earning another step.
  • Prompt treadmill — the human still reprompts every pass because state and trigger were never externalized.
  • Context soup — the loop loads broad memory instead of the smallest relevant state.
  • Checker theater — the checker has no independent evidence.
  • Budget blindness — the loop is productive only because nobody counted cost.
  • Authority fog — the agent guesses whether it may edit, publish, spend, or call an external system.

Proof Of Done

The loop is ready when another operator can run it from the contract and get:

  • the same trigger;
  • the same source boundary;
  • the same allowed tools;
  • the same verifier;
  • the same stop condition;
  • the same proof artifact.

Sources

Context

Questions

What should the agent know before it prompts itself again?

  • What starts the loop?
  • What state must survive?
  • What verifier earns the next step?
  • What budget stops the loop before waste compounds?