Loops are prevented by limits the platform enforces, not by asking agents to notice them. Every task carries its lineage, so the platform can see when work returns to an agent that already handled it. Caps on hops, retries and re-opened tasks stop the cycle, a budget limits cost, and a person takes over when a cap is hit.
How do loops between agents start?
Loops rarely look like loops from inside. Each agent does something reasonable with what it receives. Common patterns:
- Ping-pong corrections. A reconciliation agent posts an adjusting entry; a ledger-review agent flags it as unusual and reverses it; the reconciliation agent sees the gap again and re-posts.
- Escalation circles. Agent A cannot resolve a case and hands it to B; B lacks the data and hands it back to A.
- Auto-reply storms. An agent replies to an email; an outside system auto-acknowledges; the agent treats the acknowledgement as a new message and replies again.
- Injected loops. Text in an input instructs the agent to "forward this to the review agent", and the review agent's output contains the same text. Treat this like any other prompt injection.
- Memory echoes. Two agents keep re-reading each other's notes and re-opening an issue each thinks is unresolved, a risk discussed in how AI agents remember context between tasks.
What are the steps, and who acts?
- Give every task an id and a lineage. Platform. Each handoff records the parent task, so the chain of agents is known. Evidence: lineage on every task record.
- Cap hops. Platform, with limits set by the process owner. A task that has passed between agents more than a set number of times is held. Evidence: hop count in each verdict.
- Cap returns to the same agent. Platform. If a task comes back to an agent that already handled it, without new input from outside the chain, it is held. Evidence: the hold reason.
- Detect duplicate actions. Platform. An action identical to one taken within a short window on the same record, such as the same entry posted again, is refused or held. Evidence: the duplicate check in the verdict.
- Set a budget per task. Process owner sets; platform enforces. Model calls, elapsed time and cost all have ceilings. Evidence: budget consumption on the task.
- Ignore automated replies. Developer and platform. Messages marked as automatic, or from known no-reply senders, do not create new tasks. Evidence: the filter rule.
- Route to a person on any cap. Platform holds; a named person decides. Evidence: the held task and the decision.
What does this look like in practice?
Take a finance team using one agent to reconcile records between two systems and another to review unusual ledger entries. A bank fee appears in the bank feed but not in the ledger. The reconciliation agent posts it to the fees account. The review agent, whose rules flag fee postings over a threshold, reverses it as unusual. The reconciliation agent sees the gap reappear and posts again.
With duplicate detection, the second identical posting is held. The task's lineage shows it is the third action on the same item by two agents. A finance analyst sees both agents' reasoning side by side, confirms the fee is legitimate, and adds a rule that review flags on fee postings are held for a person rather than reversed. The loop ends with one entry and a recorded decision.
How do separation of duties and loops interact?
Designs that split work between agents for control reasons, such as one agent preparing and another checking, create natural places for loops: the checker rejects, the preparer resubmits. That is intended, up to a point. The cap on returns turns an endless back-and-forth into a held case after a set number of rounds. How to split the work is covered in how to keep separation of duties between AI agents.
What stays with a person?
- Setting the caps and budgets for each process.
- Every task held by a cap.
- Changing the rules that caused the loop, such as a review threshold.
- Deciding whether a reversal-and-repost pattern needs either agent's depth reduced.
Where Pryme fits
In Pryme, every handoff passes the governing layer and every verdict is filed in an append-only record with its task lineage. A task that keeps returning shows up as a sequence of verdicts on one item, and a hold names the bound that stopped it. The full design is in the governed agentic operating system guide.
Questions people ask
Can agents detect loops themselves?
Sometimes, but not reliably. An agent sees only its own part of the chain. The platform sees the whole lineage, which is why caps belong there.
Do loops cost much?
They can. Each turn uses model calls and may write to systems. A budget per task bounds the cost, and duplicate detection stops repeated writes.
What hop limit is right?
It depends on the process. Set it a little above the longest legitimate chain for that process, and review held tasks to see whether the limit is catching real loops or normal work.