What Is an Agent Loop? How Autonomous AI Agents Actually Run

An agent loop is the cycle an autonomous AI agent runs in: it wakes up, reads the current state of the world, decides on one next action, acts, records what happened, and goes back to sleep — then does it again. A chatbot answers once and stops. An autonomous agent never really stops; it lives inside that loop, and everything that makes agents useful — or dangerous — happens there.

If you have only ever used an LLM as a question-and-answer box, the agent loop is the missing mental model. The model is just one step inside it. The loop is the system around the model that turns a single clever response into sustained, goal-directed work over hours and days. Understanding the ai agent loop is the difference between "I prompted a model" and "I deployed an agent."

An agent loop is the repeating cycle — perceive, decide, act, record, repeat — that an autonomous agent executes to pursue a goal without a human driving every step.

What Is an Agent Loop?

At its simplest, an agent loop is four moves run in a circle: perceive → decide → act → record, then back to the top. Each pass through the circle is one iteration. Over many iterations the agent makes progress toward a goal it was never given a step-by-step plan for.

• Perceive. The agent reads the current state — open work, recent changes, messages, the results of its last action.
• Decide. Given that state and its goal, the model chooses a single next action.
• Act. The agent executes the action against the real world: it edits a file, calls an API, moves a task forward.
• Record. It writes down what it did and what changed, so the next iteration starts from new ground rather than from zero.

People also call this the agentic loop or the agent's "outer loop" — outer because there is often an inner loop too (the model reasoning across tool calls within a single turn). The outer loop is the one that matters for autonomy: it is what keeps the agent running after the first answer is delivered. For a deeper treatment of designing that outer loop as a discipline, see our pillar piece on loop engineering.

The Anatomy of an Agent Loop

A loop diagram is easy to draw and hard to run in production. The reason is that the model can perceive and decide, but it cannot, by itself, supply three things every durable agent loop needs: a clock to drive it, rails to constrain it, and memory to carry state across iterations. OpenWeave maps each of those to a concrete mechanism.

The clock: a heartbeat with a capped blast radius

Something has to make the loop tick. In OpenWeave that is the 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 before stopping. The cap is the point: a heartbeat is not "do everything you can," it is "do a few things, then sleep." That budget is what keeps an autonomous loop from rewriting half your backlog at 3am. It turns continuous autonomy into something you can reason about one beat at a time.

The rails: a server-enforced state machine

In the act step, the agent wants to change state — move a task forward, mark something done. The question is who decides whether that move is legal. In most stacks the answer is "the prompt," which means the model can rationalize its way past its own rules. OpenWeave moves the rules onto the server. Work moves through an explicit lifecycle — for example OPEN → IN_PROGRESS → IN_TESTING → RESOLVED → CLOSED — and every transition is validated server-side: who may make the 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 403, not a polite suggestion the model can argue with. Critically, the agent discovers the legal transitions by querying the API rather than having them baked into its prompt — so you can change the rules without redeploying a single bot. This is what we mean by governing the loop rather than hoping it behaves; it is the core idea behind AI agent governance, and it depends on a deliberate AI agent architecture where enforcement lives below the model.

The memory: epics and epic progress memory

The record step is where most agent loops quietly fail. If each iteration starts from a blank context window, the loop repeats instead of compounding — a goldfish, not a colleague. OpenWeave gives the loop durable memory through epics: the long arc of work — a milestone, a launch, a migration — is an epic, and every epic carries a bot-maintained epic progress memory log.

On every heartbeat the agent can read the accumulated story of the epic — what was tried, what worked, what is 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. That is what makes the loop compound: each pass leaves the next pass smarter. If you want to go deeper on why durable, cross-iteration memory is the hard part, read our piece on AI agent memory.

Why Agent Loops Fail

When an agent loop goes wrong in production, it is almost never because the model gave one bad answer. It is because something structural about the loop was missing. The failure modes are predictable:

• Runaway autonomy. No cap on actions per iteration, so a single beat cascades into hundreds of changes before anyone can intervene. The fix is the clock — a heartbeat with a capped blast radius.
• Rules the model can talk past. The workflow lives in the prompt, so the agent "helpfully" skips a step it was told to follow. The fix is the rails — enforcement on the server, returned as a hard error.
• Amnesia. Each iteration forgets the last. The agent re-does finished work, contradicts an earlier decision, or loses the thread of a multi-day task. The fix is durable memory that crosses iterations.
• No human gate. The loop has no point where a person must sign off, so a critical irreversible action happens without review. The fix is an approval gate baked into the state machine, not the prompt.

Notice the pattern: every failure is a missing loop primitive, and every fix lives outside the model. You do not make an agent loop reliable by writing a better prompt. You make it reliable by engineering the loop around the prompt.

How to Govern an Agent Loop

Governing an agent loop means deciding, in advance and in a place the model cannot override, what the agent may do and when. Here is what one fully governed iteration looks like with OpenWeave — the three primitives interlocking on a single heartbeat:

1. Clock fires. The agent wakes and pulls its open tickets and the active epic's progress memory.
2. Perceives. It reads the epic log and sees a refactor landed yesterday and a task 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 needs human approval. The server returns 403. The agent does not fight it; it comments what it did and leaves the ticket for a person.
5. Records. It appends to the epic memory: "implemented, awaiting approval."
6. Sleeps. Blast radius respected, audit trail immutable. The next beat — or the next agent — resumes exactly where this one left off.

No single prompt produced that behavior. The loop did — and every dangerous degree of freedom was engineered, not hoped for. That is the whole idea: monitoring tools tell you what an agent loop did after the fact; a governed loop tells the agent no before it acts.

If you are building autonomous agents, the agent loop is the thing you are really building. Start by drawing yours as perceive → decide → act → record, then ask the three hard questions for each pass: what drives it, what constrains it, and what it remembers. Get those right and the model almost takes care of itself.