LOOP PATTERNS AND PARADIGMS

The Four Loop Patterns

Beyond the six primitives, loop engineering identifies four distinct trigger patterns. Most production agents combine more than one.

Pattern 1: Heartbeat Loop

The agent runs continuously on a short, fixed interval — checking for work each tick. This is the always-on assistant: a CI health dashboard, a PR monitor, a real-time issue tracker.

Cost profile: Highest fixed cost; price is set by frequency. Best for workflows where work is steady and low-latency response matters.

Pattern 2: Cron Loop

The agent runs on a defined schedule — daily, weekly, at a specific time. This is the pattern for batch work: morning standup prep, overnight dependency audits, weekly release notes.

Cost profile: Cheapest unless frequency is high. Best for predictable, time-anchored work.

Pattern 3: Hook Loop (Event-Driven)

The agent fires in response to an external event — a PR opens, a test fails, a deploy completes, a Slack message arrives, a web page changes. The agent is a component running continuously inside a larger system, waking only when there is something new to react to.

Failure mode: Webhook storms. A misconfigured vendor can push thousands of events in minutes, spawning thousands of agent runs. Every hook-triggered workflow needs a rate limit and a backpressure mechanism.

Pattern 4: Goal Loop

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.

Canonical use: an autonomous research agent given the goal “produce a competitive analysis of the top five players in our space.” It searches, reads, summarizes, evaluates whether the brief is complete, decides what’s missing, searches more — until its own success check returns true.

Failure mode: Goals without convergence criteria. “Research the competitive landscape” doesn’t have a clear stopping condition. The agent runs indefinitely and burns tokens until someone notices.

Open Loops vs Closed Loops

A useful design distinction for production work:

Open Loops hand the agent a target plus guardrails and let it pick its own route through the problem. Good for prototyping, exploration, or unknown terrain. The catch: if the project’s standards are vague, the output is mostly noise.

Closed Loops map the route first — what each step does, how it is checked, when the loop is allowed to stop — and agents iterate inside that scaffolding. Runtime cost stays predictable, and results tend to improve over time because every run is graded against the same rubric.

In production, closed loops win by default. You keep one loop in charge of the goal, assign each step to dedicated specialist subagents, and let an automated check decide what gets through.