Loop Engineering: How to Design Self-Prompting AI Agents

The industry is quietly moving away from prompt engineering as the primary craft of building with AI. The new craft is loop engineering — designing the conditions under which AI agents prompt themselves, run on their own schedule, react to external events, and iterate toward goals without a human at the keyboard.

Prompt engineering optimises a single interaction. Loop engineering optimises the autonomous behaviour that surrounds it.

This guide covers the four loop patterns that ship in production, how to pick between them, the platforms that handle each natively, and the failure modes every loop-engineered agent needs guards against.

What loop engineering actually means

Loop engineering is the practice of designing AI agents that prompt themselves on a schedule, in response to events, or until a goal is met — rather than waiting for a human to type each instruction.

The shift is architectural:

• Chat-style AI: human types a prompt, model responds, human types again. One-shot, synchronous, attention-bound.
• Loop-engineered AI: agent runs on a trigger, decides what to do, acts, evaluates, repeats. Autonomous, asynchronous, attention-free.

Most teams building production AI in 2026 are doing loop engineering whether they call it that or not. Every cron-triggered agent, every webhook-driven workflow, every "research until done" autonomous loop is a different shape of the same architectural pattern: the agent prompts itself.

The four loop patterns

Four patterns cover ~95% of production loop-engineered agents. Most workflows combine two or three.

Pattern 1: Heartbeats

The agent wakes up at a set interval — every 5 minutes, every hour, every shift — and checks whether there's work to do. If there is, it acts. If not, it sleeps until the next tick.

The signature use case: a support-monitoring agent that wakes every 10 minutes to check the queue. New tickets? Triage them. Backlog growing? Escalate. Nothing changed? Sleep.

The pattern's strength is reactivity to state without the overhead of constant running. The agent isn't always on — it's only on when the heartbeat fires. The cost is bounded by the heartbeat frequency.

The platform that builds around this pattern explicitly: Paperclip. Its heartbeat system lets you configure an agent to wake on schedule, check a defined condition, act if needed, and sleep — with budget caps and audit logs around each cycle. The closest thing to a turnkey heartbeat implementation among the platforms we review.

The failure mode: heartbeats with no idempotency. If the heartbeat fires while the previous cycle is still running, you get overlapping work — two agents both triaging the same ticket. Every heartbeat workflow needs a lock or a "this cycle is in progress" guard.

Pattern 2: Crons

Scheduled tasks anchored to time, not state. The agent runs every Monday at 9 AM, or the first of every month, or the end of every quarter. Whether or not there's "work to do," the cron fires.

The signature use case: a Friday-afternoon analytics summary that aggregates the week's data into a digest. The agent doesn't check whether anyone wants it — it runs because Friday at 4 PM is when the report goes out.

The strength is predictability. Stakeholders know exactly when the output arrives. The work happens whether or not anyone's paying attention.

The platforms that ship crons cleanly: n8n (visual scheduling on top of 400+ integrations), Lindy (in its no-code interface), and any developer-built workflow with a cron-style trigger.

The failure mode: crons that run on stale prompts. The agent was tuned six months ago against an old model and old assumptions; the cron is still firing those instructions weekly. Nobody noticed because the cron worked. Audit your cron-driven agents quarterly.

Pattern 3: Hooks

Event-triggered loops. Something external happens (an email arrives, a webhook fires, a database row is inserted, a tool is called) and the agent runs in response.

The signature use case: a customer-support agent that wakes when a ticket lands in Intercom. The webhook fires; the agent reads the ticket, classifies it, drafts a response, decides whether to send or escalate.

The strength is real-time responsiveness. The agent acts when something needs acting on, not when a clock ticks.

The platforms that handle hooks well: n8n for webhook-triggered workflows, Lindy for no-code event triggers, Claude Code for tool-event hooks (PreToolUse, PostToolUse, Stop, Notification — fired on the agent's own actions), and OpenAI Codex for similar CLI-driven hook patterns in the OpenAI ecosystem.

The failure mode: hooks without rate limiting. A webhook storm — a vendor pushes 10,000 events in a minute — can spawn 10,000 agent runs and burn through your budget in an hour. Every hook-triggered workflow needs a rate limit and a backpressure mechanism. We've seen single Slack webhook misconfigurations cost teams hundreds of dollars before they noticed.

Pattern 4: Goals

The agent runs continuously, prompting itself until a strictly defined outcome is validated. No heartbeat, no cron, no external trigger past the initial start — the agent decides each next step based on whether the goal has been met.

The signature use case: an autonomous research agent given the goal "produce a competitive analysis of the top five players in our space." The agent searches, reads, summarises, evaluates whether the brief is complete, decides what's missing, searches more — until its own success check returns true.

The strength is unbounded effort applied to a well-defined goal. The agent will keep trying approaches until one works.

The platforms that handle goal-driven loops: OpenClaw (single-user goal-driven harness), Hermes (server-deployed with learning across runs), Manus AI (autonomous browser-based goals), OpenHands (autonomous task-completion for engineering work — runs until a PR review, CVE fix, or migration is complete), and Claude Code's autonomous mode for code-shaped goals.

The failure mode — and this is the most expensive one — goals without convergence criteria. "Research the competitive landscape" doesn't have a clear stopping condition. The agent runs, runs, runs, and burns thousands of tokens before someone notices. Every goal-driven loop needs: a max iteration cap, a budget cap, a success function the agent can actually evaluate, and an escalation path when the goal can't be met. Skip any one of these and you have a runaway. Our guardrails article covers the full safety stack.

How to pick the right loop pattern for your job

Five questions in order:

1. Is the work anchored to time or to state? Time → cron. State → heartbeat.
2. Does the work fire in response to an external event? Yes → hook. No → continue.
3. Does the agent need to keep working until a condition is met, with no fixed schedule? Yes → goal. No → continue.
4. What's the cost ceiling per cycle? Heartbeats are cheap (bounded by frequency); goals can spiral (need explicit caps).
5. What's the failure escalation? Every loop needs a "give up and tell a human" path.

Most production agents combine patterns. A customer-support agent might use a hook for incoming tickets, a heartbeat to check escalation queues, and a cron to send a daily volume report. The loop engineering question is which pattern fits which part of the job, not which pattern wins overall.

The platforms that ship each pattern

A compact reference for picking the loop layer:

Pattern	Best platform pick	Why
Heartbeats	Paperclip	Pattern-native heartbeat system with budget caps
Crons	n8n or Lindy	Clean scheduling UI, 400+ integrations
Hooks (webhook-triggered)	n8n	Visual webhook builder, deep integration library
Hooks (tool-event)	Claude Code	PreToolUse/PostToolUse/Stop event hooks
Goals (autonomous)	OpenClaw or Hermes	Goal-driven harness with skill accumulation
Multi-pattern composition	Paperclip + agent runtime underneath	Orchestration layer with controls

The 2026 shortlist has the full breakdown across all 27 platforms.

The cost math

What loop engineering actually costs, with concrete numbers on Claude Sonnet 4.6:

Pattern	Example	Tokens/cycle	Frequency	Monthly cost
Heartbeat	Ticket-queue check	500	Every 5 min	~$13
Cron	Weekly digest	5,000	Once/week	~$0.06
Hook	Support ticket	2,000	1,000/month	~$60
Goal	Research brief	60,000 (20 iterations × 3k)	5x/month	~$9

Heartbeats with high frequency are the highest-fixed-cost pattern. Goals are the highest-variable-cost pattern. The cron is cheapest unless its frequency is high. The cost calculator sizes any of these against your specific volumes and model choice.

The four guards every loop-engineered agent needs

Loop engineering's main failure mode is runaway cost. Four controls, all required, in every production loop:

1. Per-loop iteration cap. Maximum 50 cycles, or whatever number makes sense for your workload. Goal-driven loops especially need this — they don't naturally stop.
2. Per-day budget cap. Tokens spent per workflow per day. Platforms like Paperclip ship this by default; if you're building on a framework, build it yourself.
3. Success condition the agent can actually evaluate. If the agent can't tell when the goal is met, it can't stop trying. "The brief is complete" is too vague; "the brief covers competitor X, Y, and Z, with one named source per claim" is testable.
4. Escalation path on failure. When the goal isn't met after N attempts, the agent stops and writes a message to a human queue. Without this, failed goals become silent runaways.

Our guardrails article covers the broader safety stack; these four are the loop-engineering-specific ones.

The honest take on loop engineering as a craft

Prompt engineering as a discipline is still useful — knowing how to phrase instructions for a model matters. But for production agents, the leverage has moved up the stack to loop engineering. Whether your agent runs on the right schedule, with the right triggers, against the right termination conditions decides whether it ships value or burns money.

The teams that take loop engineering seriously ship reliable autonomous systems. The teams that treat it as an afterthought — wiring up a cron in Zapier and calling it agentic — ship demos that break in production.

Practical advice we'd give any team designing a new agent: write the loop on a whiteboard before you open any platform. What triggers it? What does it check each cycle? What does it do? When does it stop? When does it escalate? Get those answers right and the build itself takes hours, not weeks.

What to read next

The AI agent workflow design guide covers the layer below — what the agent does once a loop fires. Multi-agent AI covers when loops should spawn specialist sub-agents vs running single-agent. AI agent guardrails covers the seven controls every production agent needs, including the four loop-specific ones. The observability guide covers what to instrument so loop failures are debuggable.

If you're stuck deciding between platforms for a loop-engineered agent, the picker is a five-question version of the question.