Loop engineering in Jira

Most teams use AI coding agents interactively: prompt, wait for output, review, and repeat. Loop engineering moves that execution to background cloud agents that run asynchronously. Instead of tying up a developer's terminal, the agent independently handles run-the-business tasks.

Background agents only work when the state persists across runs. Because models have no memory between sessions, the loop needs a system of record to track progress, evaluate pass/fail checks, and hand off work. That state can be the work that the agent has already produced. That makes the real question less about the agent and more about where the work lives, which points straight at your system of record. In Jira, that record already exists.

This guide covers:

• What loop engineering is, and how it differs from prompt engineering

• The parts of an agent loop, from finding work to deciding what is next

• How to run an agent loop in Jira, where your work already lives

What is loop engineering?

Start with the loop itself. A loop is the cycle an agent repeats on its own, running until it meets a goal or hits a limit. Loop engineering is the practice of building and controlling that loop, its trigger and exit conditions. You set the goal and build the cycle. The agent then picks up the work, acts, checks its result, and decides what to do next.

Every working loop combines two things. The first is a cycle that repeats the same four steps: find, act, check, and decide. The second is a durable record of what happened, because the model keeps nothing between runs. Each run writes its state to that record, and the next run reads it back as context. That means each pass starts informed by the last one instead of from a blank slate. Where that record lives determines whether a loop can pick up where it left off. However the loop starts, whether you re-run it or a schedule triggers it, the cycle itself stays the same.

Loop engineering vs. prompt engineering

Prompt engineering and loop engineering are not competitors. They work at different levels. Prompt engineering shapes what an agent does in a single turn. Loop engineering shapes the system that runs many turns toward a goal. You still write good prompts inside a loop, but the loop decides when to run them, checks the results, and keeps going.

The difference shows up in who does the work between turns. With prompt engineering, you are in the chair. You send an instruction, read the reply, and decide the next move yourself. With loop engineering, the system holds the chair. It keeps the agent running, evaluates each result, and only involves you when it needs a decision.

The harness is the environment a single agent runs inside, while the loop is the cycle that keeps pointing agents at work. For how to give a single agent the right inputs, see context engineering.

What are the parts of an agent loop?

1. Discovery: how a loop gets triggered

Every loop needs a trigger. The simplest is a person re-running the agent until the work is done. Smarter triggers remove that dependency, like a schedule, an event, or a queue of open items that starts each run so the loop keeps going without you watching.

2. Action: the agent does the work it is scoped to own

The agent does the step it is allowed to own, and nothing wider. Scope is what makes a loop safe to run unattended.

3. Check: the loop judges its own output

The loop checks its own output before it continues, usually by running the tests or the build. If the check fails, the loop retries or stops instead of moving on. A loop without this step produces more output, not better output.

4. Record: the loop writes down what happened

After each run, the loop writes its state somewhere durable: what it did, what is left, and what failed. This is the part most home-grown loops get wrong, and the reason a shared system of record matters.

5. Decide next: iterate, finish, or hand off

The loop reads its own record and routes the work. It runs again, closes the work, or hands off to a person when it is unsure or out of bounds. Escalation is the exit door, and human-in-the-loop patterns covers how that handoff works.

How Jira runs and remembers an agent loop

A loop needs a durable record and a place to trigger from, and both already live where your team runs work. In Jira, the work item is the record that survives between runs, and automation rules are the trigger that turns a task into a loop. You reuse the access rules and history your team already relies on, instead of maintaining a separate system on the side.

Each part of the loop maps to something Jira already does.

Two things tie it together. The work item holds the state, and the Teamwork Graph turns it into the context the next run reads. It connects the item to the code, decisions, and docs around it. When a run needs a person, that handoff follows human-in-the-loop patterns. The record itself is the advantage over a home-grown script, because it is shared, permissioned, and audit-backed. People and agents work from one system of record, not two.

How to build your first agent loop in Jira

You do not need a redesign to start. Pick one recurring task, give it a trigger and a place to record its state, and run the loop on reversible work first. Here is the order that works.

1. Pick a low-stakes, recurring task

Choose predictable tasks where criteria are objective and changes are easy to verify, like updating dependencies, patching security vulnerabilities, or resolving accessibility violations. Letting a background agent own routine maintenance frees the team to focus on complex feature work.

2. Set the trigger

Create an automation rule that finds that work on a schedule or an event. The rule is what starts each run, so the loop kicks off without you watching for it.

3. Assign the work to a coding agent

Assign the work item to a coding agent, such as the Jira Coding Agent. The agent acts as a known identity, so it reaches only what that identity is allowed to.

4. Add the check

Give the agent an objective test—like a test suite, linter, or build command—to run and self-correct against in its own environment. When it opens a pull request, CI verifies the code, and Jira Automation routes the outcome or escalates failures.

5. Confirm the record, then widen

Check the work item and the agent sessions view to confirm the run is captured. Once it holds up, add the next task type, still on reversible work. The result is a loop that finds and finishes routine work on its own, with the risky calls routed to you.

Frequently asked questions about loop engineering

What is loop engineering for AI agents?

It is the practice of designing the automated cycle an agent runs on its own, so it works toward a goal without a person prompting each turn.

How is loop engineering different from human-in-the-loop?

Loop engineering designs the cycle the agent runs on its own. Human-in-the-loop designs where a person approves, reviews, or takes over.

What are the parts of an agent loop?

Discovery, action, a check, a record, and a decide-next step, plus a durable record that carries state from one run to the next.

How do you stop an agent loop from running forever?

Set a goal state and a budget up front, and give the loop a stop condition so it exits on success or on limit.

Can you run AI agent loops in Jira?

Yes. Automation rules trigger the loop, a coding agent does the scoped work, and the work item holds the state the next run reads as context.