Loop Engineering on Exemplar

Loop engineering is the practice of replacing yourself as the person who prompts the agent: instead of typing the next prompt, you design a system that discovers work, assigns it, verifies results, and persists state—and escalates to a human only when judgment is required.

The idea comes from the coding-agent community—see the loop-engineering reference repo  by Cobus Greyling (inspired by Addy Osmani and Boris Cherny):

“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” — Boris Cherny, Anthropic

A loop is a recursive goal: a scheduler fires, a triage skill reads state and live signals, sub-agents implement and verify, connectors act on real systems, and durable memory carries context to the next run. The leverage moves from crafting individual prompts to designing the control system that orchestrates agents over time.

This guide shows how to run those loops on the Exemplar Platform—with the governance the reference patterns ask you to build yourself (budgets, policy gates, audit) already in the platform.

The primitives, mapped to Exemplar

Loop engineering names five building blocks plus memory. Every one has a first-class platform surface:

Anatomy of a loop on Exemplar

The canonical loop shape—schedule → triage → state → implement → verify → act → human gate—maps onto the platform like this:

Worked example: Daily Triage loop

Daily Triage is the recommended first pattern in the reference repo: start each day with a prioritized picture of what needs attention—CI failures, stale PRs, open incidents—without checking each system manually. Report-only for the first weeks, then add action.

Here is the same loop built on Exemplar.

1. Encode intent as a skill

The loop-triage skill carries the judgment the loop applies every run—what counts as high priority, what is noise, when to escalate. Author it once, version it in the registry:

# Scaffold locally, then push to the org registry
exemplar skills init loop-triage --description "Daily triage: read CI, issues, PRs; produce prioritized findings; never invent architectural work"
exemplar skills push ./skills/loop-triage

Every run—and every IDE agent, if you install the same skill in Cursor or Claude—applies the same bar. Updating the skill updates every loop without touching workflow definitions.

2. Give the loop durable state

The reference pattern keeps a STATE.md in the repo. On Exemplar, state lives in memory scoped to the loop’s agent id, so it survives across runs, channels, and repos:

# What the loop writes at the end of a run
exemplar memory add "2026-07-21: CI red on main (#1241 flaky auth test). Fix proposed, awaiting PR review." \
  --agent-id daily-triage --type fact
 
# What the loop reads at the start of the next run
exemplar memory recall "what is in progress and what is waiting on a human?" --agent-id daily-triage

Good state answers three questions every run: what are we working on, what did we try last time, and what is waiting for a human.

3. Wire the loop in Automation Studio

Build the graph on the canvas—no orchestration code:

• Triggers — Schedule trigger at 0 8 * * 1-5; add an event trigger later for mid-day signal.
• AI steps — the triage, implementer, and verifier are separate Exemplar agent steps with different instructions. The implementer never marks its own work done.
• Connectors — GitHub, Jira, Slack, and CI tools come from Tools & MCP; credentials stay vaulted, calls share one audit trail.
• Approval — the Human approval step is the loop’s escalation path, with an assignee and an explicit timeout verdict.
• Trace — watch each run live in Trace; re-run, cancel, or retry from the same canvas.

4. Cap the blast radius

The reference repo is blunt about the caveats: token costs explode, unattended loops make unattended mistakes. On Exemplar those mitigations are platform policy, not shell scripts:

5. Phase the rollout: L1 → L2 → L3

Follow the same autonomy ladder as the reference patterns:

Move up a level only when the previous one has proven its value—and its failure modes.

More patterns from the catalog

The reference repo ships seven production patterns. They all reuse the Daily Triage graph shape—swap the trigger, the skill, and the connectors. Here are the others, built the Exemplar way.

CI Sweeper

Goal: react quickly to failing CI on main—classify the failure, propose a minimal fix, escalate what the loop cannot confidently resolve. The repo calls it the best entry loop: high frequency, bounded scope, clear verification—but also its most expensive (very-high token tier), so early exit is mandatory.

On Exemplar the loop is event-driven instead of polling: an Event trigger fires on CI failure, so there is no 15-minute tick burning tokens while CI is green—the no-op case costs nothing.

The pattern’s loop-guard circuit breaker—log every attempt, trip after 3, escalate with a pruned summary—maps to two platform pieces: a CEL filter on the attempt count recalled from memory, and Guardrails circuit breakers as the backstop if the loop ever retry-storms anyway. The repo’s warning that a 15-minute cadence without early exit can burn 5M+ tokens/day becomes a hard daily token budget on the workflow rather than a convention.

Key rules carried over from the pattern: the verifier checks root cause, not just green CI (no fix-the-symptom loops); flakes get quarantined with a ticket, never auto-fixed; the implementer only proposes—merge stays human.

PR Babysitter

Goal: stop herding pull requests through review, CI, rebase, and merge—while the human stays in the judgment seat. High cadence (5–15 min), so the design centers on the no-op run: most ticks should exit in the filter step at near-zero cost.

Per the pattern: the loop only proposes; a human merges (an explicit auto-merge allowlist for trivial cases is the L3 exception, expressed as policy on the connector action). Its PR comments are clearly signed so reviewers know which updates came from the loop. State records human decisions that overrode the loop—that is what the triage skill reads next run, so the loop stops re-proposing what a reviewer already rejected.

Mitigations from the pattern land as configuration: rebase attempts capped per PR (CEL filter on attempt count), closed/merged PRs pruned from state every run, and notifications sent only when human action is truly required—everything else lives in state.

Dependency Sweeper

Goal: keep dependencies current and unvulnerable by applying the smallest safe updates in isolation, and escalating anything risky. The core of the pattern is triage into three risk buckets, each with its own path through the graph:

The pattern’s hard rules translate directly: the verifier re-runs the audit after the change (a security patch must not introduce a new vuln), only direct dependencies are touched in the minimal-fix step, attempts per package are capped at 2 per 24h, and packages on a denylist (auth, payments, core infra) always route to the human branch—on Exemplar that denylist is policy, not a markdown file.

Rollout mirrors the repo’s advice: patch-level + known CVE fixes only on one repo for the first weeks; minors after you trust the verifier; majors stay human-gated indefinitely.

Issue Triage

Goal: a continuously clean, deduplicated, prioritized top-of-queue. The repo rates it extremely low risk, high leverage—pure report/proposal mode in week one, and a natural feeder for Daily Triage. It is the cheapest place to start if CI Sweeper feels like too much.

At L1 the loop never labels or closes anything—it maintains a scored top-5 in memory that humans (and the Daily Triage loop) read. At L2 it may apply allowlisted labels only (area:*, needs-repro)—on Exemplar that allowlist is policy on the Jira / Linear / GitHub connector tools, so the boundary is enforced rather than promised. Uncertain duplicate matches are always surfaced as “possible duplicate of #NNN” for a human to confirm.

Changelog Drafter

Goal: categorized, accurate release-notes drafts from merged PRs and commits—the repo calls it one of the highest-ROI, lowest-risk loops. Trigger daily or on a release tag; the drafter proposes, never publishes.

Two pattern details worth keeping: the verifier cross-checks every draft item against actual PR titles and commits (the anti-hallucination gate), and the post-run critique—what the draft missed or misclassified—is written back to memory so the next run improves. Project voice lives in a skill, so tone stays consistent without re-explaining it per run.

Post-Merge Cleanup

The seventh pattern—delete merged branches, sweep stale worktrees, tidy after the other loops—is an off-peak Schedule trigger plus connector actions, all L1-safe. It needs no diagram: it is the Daily Triage graph with a janitorial skill and no implement/verify branch.

Running multiple loops

The repo’s multi-loop guidance—loops collide when they share state or act on the same resources—gets simpler on the platform: each loop is a separate Studio workflow with its own agent-scoped memory, all connector actions share one audit trail (so you can see which loop did what), and org-level Guardrails budgets cap total spend across every loop rather than per-repo budget files. Issue Triage feeds Daily Triage; CI Sweeper and PR Babysitter coordinate through PR state they both read from memory.

For coding agents in the IDE (the other half of the loop-engineering story), the loop primitives live client-side—but governance stays central: Relay evaluates every bash, path, MCP, and prompt action before side effects, and the same org skills and memory are available to Cursor and Claude via the MCP endpoint.

Related

• Automation Studio — triggers, agent steps, approvals, and live trace for your loops
• Skill management — version the judgment your loops apply
• Memory — the durable state spine across runs
• Tools & MCP — governed connector actions the loop acts through
• Guardrails — budgets, rate limits, and breakers that keep loops on a leash
• Relay — the same discipline for IDE coding agents
• loop-engineering reference repo  — patterns, checklists, and stories this guide builds on