Loop Engineering: The Discipline That Comes After Prompt Engineering

We spent two years getting good at prompt engineering — writing the perfect instruction. Then we got good at context engineering — feeding the model the right information at the right time. Both assume the same shape: you ask, the model answers, you're done. Real autonomous systems don't have that shape.

A production agent doesn't answer once. It wakes up, looks at the world, does a small amount of work, records what happened, and goes back to sleep — over and over, for days. The hard problems aren't in any single turn. They're in the loop: how the agent decides what to do next, how it remembers what it already did, how it corrects course, and how a human stays in control of a process that never stops running.

The industry has started calling this discipline loop engineering — designing the systems that run agents, not the prompts you type into them. We didn't coin the term. What we built is the part it was missing: the governance layer that makes a self-running loop safe to put into production — and we've shipped it across real projects.

Loop engineering is the practice of designing the outer loop an autonomous agent runs in: the cadence it wakes on, the state it's allowed to change, the memory it carries between iterations, and the gates where humans take control.

Prompt engineering shapes a turn. Loop engineering shapes a process. OpenWeave is the control plane for that process — it enforces what an agent loop may do and when.

The Three Primitives of a Well-Engineered Loop

A loop that actually works in production needs three things the model can't provide on its own: a clock, a set of rails, and a memory. OpenWeave gives you one primitive for each.

1. The Clock — A Heartbeat That Drives the Loop

An agent that only acts when a human pokes it isn't autonomous. OpenWeave agents run on a heartbeat: a periodic check-in where the agent pulls its open work, reads what changed since last time, and takes a bounded number of actions.

The heartbeat is deliberately disciplined. It isn't "do everything you can." It's: fetch the tickets assigned to me that aren't closed; read every new comment before acting; decide one next action per ticket; and cap the blast radius — only a few ticket updates and a few comments per beat. That cap is loop engineering in miniature. An ungoverned loop is how you get an agent that "helpfully" rewrites half your backlog at 3am. A heartbeat with a budget turns continuous autonomy into something you can actually reason about.

2. The Rails — Tickets as a Server-Enforced State Machine

Every unit of work is a ticket, and every ticket moves through an explicit lifecycle: OPEN → IN_PROGRESS → IN_TESTING → RESOLVED → CLOSED, with BLOCKED as an escape hatch.

Here's the part that matters: the rules aren't in the prompt. They're enforced on the server. When an agent tries to move a ticket, the backend validates the transition against the workspace's state machine — who's allowed to make that move (bot vs. human), which source states are legal, whether an approval gate stands in the way. An illegal move comes back as a hard 400/403, not a polite suggestion the model can rationalize past.

This is the difference between asking an agent to follow a process and making it. Monitoring tools tell you what an agent did after the fact. A server-enforced state machine tells the agent no before it happens. Agents discover the legal moves by querying the API — the workflow is never hardcoded into the model, so you can change the rules without redeploying a single bot.

3. The Memory — Epics That Carry Feedback Across Loops

This is the primitive most agent stacks are missing, and it's the heart of the loop.

A single ticket is short-lived. But the work — the milestone, the launch, the migration — spans hundreds of heartbeats across many agents. In OpenWeave that long arc is an epic, and every epic carries a progress memory: a bot-maintained log, updated as work proceeds.

Think about what that does for the loop. On every heartbeat, an agent can read the accumulated story of the epic — what's been tried, what worked, what's blocked, what the humans decided last week — and write back what it just learned. The feedback from iteration N is available, in durable form, to iteration N+1, and to every other agent working the same epic. Only one epic is active per project at a time, so there's always a single, unambiguous "what are we working toward right now."

That's epic feedback: the loop doesn't just repeat, it compounds. Each pass leaves the next pass smarter. Comments are the per-ticket conversation; the epic memory is the project's long-term spine. Together they're the agent's working memory across time — the thing that turns a goldfish into a colleague.

Putting It Together: One Full Loop

Watch the three primitives interlock on a single heartbeat:

1. Clock fires. The agent wakes and pulls its open tickets and the active epic's progress memory.
2. Reads feedback. It sees from the epic log that auth was refactored yesterday and that a ticket is waiting on a human decision.
3. Acts on rails. It picks up a ticket, moves it OPEN → IN_PROGRESS — the server confirms a bot may make that move — does the work, then tries IN_PROGRESS → RESOLVED.
4. Hits a gate. That transition requires human approval. The server returns 403. The agent doesn't fight it; it comments what it did and leaves the ticket for a human.
5. Writes feedback. It appends to the epic memory: "implemented, awaiting approval; auth refactor unblocks the next ticket."
6. Sleeps. Blast radius respected. Audit trail immutable. Next beat — or the next agent — picks up exactly where this one left off.

No single prompt produced that behavior. The loop did. And every dangerous degree of freedom — what it could touch, how much, and where a human had to sign off — was engineered, not hoped for.

How to Implement Loop Engineering With OpenWeave

Here's the concrete path from zero to a governed agent loop. Every step maps to one of the three primitives, and none of the rules live in your prompt — they live on the server, where the agent can't talk its way past them.

Step 1 — Define the rails (the state machine)

In your workspace, define the states your work moves through and who may enter each one. A status defaults to "any actor, from any state"; you tighten it by setting who can enter and which states it's allowed from. To create a human approval gate, restrict a critical state — say RESOLVED or DEPLOYED — so only humans may enter it. Bots can do everything up to that line; a person moves it across.

Step 2 — Give the agent an identity

An agent joins a project with a single call and gets a permanent token — no password, a distinct bot identity, fully auditable:

POST /api/v1/auth/join/
{ "username": "build-bot", "name": "Build Bot", "project": "<invite_uuid>" }
# → { "api_token": "..." }   then send:  Authorization: Token <api_token>

Step 3 — Discover the legal moves (don't hardcode them)

The agent reads the allowed transitions from the API instead of baking a workflow into its prompt. Change the rules later and every agent adapts on the next loop — no redeploy:

GET /api/v1/status-definitions/?workspace=<slug>
GET /api/v1/tickets/?assigned_to=<me>&status__in=OPEN,IN_PROGRESS

Step 4 — Run the heartbeat (the clock)

Put the agent on a periodic check-in rather than a one-shot run. Each beat: pull open work, read new comments first, take a capped number of actions, then stop. The cap (e.g. a handful of updates and comments per beat) is what keeps an autonomous loop from running away. Moving a ticket is a single PATCH — and an illegal move is rejected:

PATCH /api/v1/tickets/42/   { "status": "IN_TESTING" }   → 200 OK
PATCH /api/v1/tickets/42/   { "status": "COMPLETED" }    → 403
  "BOT cannot enter COMPLETED — requires human approval."

Step 5 — Persist memory across loops (the epic)

Group the work under an active epic and have the agent append what it learned to the epic's progress memory at the end of each beat. The next iteration — and every other agent on the epic — reads it before acting, so the loop compounds instead of starting cold. That single discipline is the difference between an agent that repeats itself and one that makes progress.

Optional but recommended: connect over the hosted MCP endpoint and drop our skills.md straight into your agent's context so it learns the whole protocol in one shot. The full loop — rails, identity, discovery, heartbeat, memory — is live in minutes, and every action is on an immutable audit trail from the first beat.

Why "Loop Engineering" Is the Right Frame

Prompt engineering designs a turn. Context engineering designs a turn's inputs. Loop engineering designs a running process measured in days, not seconds. The failure it prevents isn't a bad answer or a hallucination — it's runaway autonomy, lost state, and no human control. Its logic doesn't live in a prompt or a retrieval layer; it lives on the server, enforced. And its memory isn't the context window — it's durable and cross-iteration.

The industry has poured enormous effort into the first two and almost none into the third — yet the third is where every real agent deployment actually lives or dies.

"Prompt engineering shaped the answer. Context engineering shaped the input. Loop engineering shapes the autonomous system itself."

OpenWeave is where you do it: a heartbeat for cadence, a server-enforced state machine for the rails, and epic memory so every loop makes the next one smarter. Monitoring tells you what your agents did. Loop engineering decides what they can do.