Agentic Prompt Loops

What should an agent know before it prompts itself again?

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.

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

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.

Scheduled And Fresh-Session Loops

A scheduled run should assume it inherits no useful chat context. Give it stable inputs and a durable checkpoint instead of relying on the previous conversation.

1. Reconstruct. Resolve the goal, source handles, authority, budget, and last accepted checkpoint.
2. Classify. Distinguish provider, source, permission, tool, verifier, and consumer failures. One early failure can hide the next.
3. Act idempotently. Use read-only actions first. Protect writes, sends, payments, and publications with idempotency keys or approval gates.
4. Checkpoint. Persist completed work, failed attempts, evidence, and the next allowed action. Do not store the whole conversation log as state.
5. Recover or escalate. Resume from verified state, compensate for partial side effects, or stop with a precise request for human authority.
6. Close to a consumer. Name who or what reads the output and which decision can change. Kill recurring work whose outputs remain unused.

Proof requires a cold-start test: restart without conversation history and show that the loop reconstructs state, avoids duplicate side effects, and produces the same accepted proof shape.

Loop Test

A loop compounds only when three axes improve together:

• Telemetry shows what happened.
• Verification lets something other than the maker fail the work.
• Durable state gives the next pass a stronger starting point than chat memory.

If one axis is missing, the loop can still look busy while it degrades.

No telemetry turns mistakes into mystery. No independent verification turns confidence into self-grading. No durable state turns each pass into re-briefing.

Treat the missing axis as the first constraint before adding more agents, tools, or cadence.

Loop Types

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

Type	Good use	Avoid when
Scheduled discovery loop	News, dependency drift, queue scans, recurring research.	The source changes rarely or the action after discovery is unclear.
Goal/run-until-done loop	A bounded objective with a verifier.	Success depends on taste or hidden human judgment.
Hook-triggered loop	A file, command, session, or tool event should trigger control.	The hook cannot see enough context to decide.
Maker/checker loop	Quality matters and review can be independent.	The checker only repeats the maker's assumptions.
Subagent fan-out loop	Parallel scouts reduce uncertainty.	Fan-out has no merge rule or cost cap.
Skill-capture loop	A repeated human move should become reusable procedure.	The procedure is still changing every run.
Mechanical feedback loop	Work 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.
• Trust debt — weak output forces humans back into manual re-verification, so automation becomes bureaucracy again.
• Cognitive surrender — the loop produces faster than operators can understand, so unread approvals become hidden intent debt.
• Context degradation — long loops keep running after the useful context has gone stale or crowded.
• Hidden inheritance — a scheduled job works manually only because the interactive session supplied paths, state, or decisions that the job contract omitted.
• Retry duplication — recovery repeats an external action because the tool contract lacks idempotency or compensation.
• Orphan output — reports arrive on schedule, but no consumer accepts, rejects, routes, or deletes them.

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;
• a fresh session can resume from verified state without repeating a side effect;
• a named consumer can act on or kill the output.

Sources

• Loop Engineering — current practitioner framing for designing the system that prompts the coding agent.
• AI SDK Loop Control — concrete controls for stopping and changing agent steps.
• Agentic Artificial Intelligence: Architectures, Taxonomies, and Applications — research frame for single-agent loops and multi-agent systems.

Context

• depends-on Loops — hub for loop engineering.
• depends-on Delegation — decision rights before autonomy.
• depends-on The Tight Five — the purpose/principles/platform/perspective/performance connection for proof and quality thresholds.
• pairs-with Mechanical Feedback Loops — how each pass becomes control evidence.
• applies-to Agentic AI Systems — where loops meet harnesses, tools, memory, and evals.
• risk-governed-by Loop Registry — when recurring loops need a health reader.

Controller

Changes my mind: A loop with telemetry, independent verification, durable state, stop condition, and proof still degrades or creates more manual rechecking.

Next question: Which loop field most often goes missing when agents drift?

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?