agent loop detected: asking the ERP for unapplied payments returns the same 500 every call

TL;DR

The ERP endpoint returns the same open items because the agent never changes its query: no paging, no since-filter, no exclusion of already-seen items. The agent must fingerprint each response and stop treating repeats as new work. Then fix the query to iterate properly: page through the unapplied set with a stable sort, or ask for items since a timestamp, and work each item once, recording decisions per payment instead of re-fetching forever.

agent loop detected: asking the ERP for unapplied payments returns the same 500 every call

Use this when

• Every ERP call for unapplied payments returns the same 500 records.
• The agent's call repeats indefinitely with no completion or progress metric.
• The unapplied population is roughly stable, so repeats are stale data, not a flood of new items.

Not for this skill when

• New unapplied payments genuinely appear at high volume, such as during a payment run. Then repeated full lists are normal; the agent needs a since-filter, which the loop fix below also provides.
• The endpoint is misbehaving and returning 500 errors or partial pages. Fix the response handling first.

Steps

1. Add response fingerprinting: count and first and last ids of each returned list. Verify: the repeat is detected from state within two cycles
2. Change the query to iterate: page through the set with a stable ordering, or use a changed-since filter if the API offers it. Verify: successive requests return successive slices, not the same slice
3. Persist the set of seen payment ids durably. Verify: a restarted agent does not reprocess items it already handled
4. Work the unapplied payments once each: match, apply, or queue each with a decision recorded. Verify: the 500-item set shrinks as decisions are recorded
5. Set the ongoing job to a bounded cadence, for example daily, querying only new or changed unapplied items since the last run. Verify: a steady-state run fetches a small delta and terminates

Variant phrasings

agent loop same unapplied payments ERP every call

The repeating-feed phrasing.

ERP unapplied payments pagination since filter polling

When fixing the query.

Compatibility: ERP unapplied payment and open item endpoints consumed by polling agent jobs.

Why it happens

Polling an open-items endpoint without iteration semantics is a question the API answers the same way every time: here is the current open set. The agent's mistake is treating the answer as a queue of new work. Fingerprinting breaks the illusion by making repetition visible, and proper iteration, paging or deltas, converts the open set into workable units. The deeper lesson is that open items are a data set with decisions attached, and each decision is what shrinks the set.

Edge cases / pitfalls

• If the unapplied set is large and stable, the polling job is not the right tool; a one-time working session plus a small delta poll fixes the structure.
• A since-filter on a modified timestamp must handle bulk updates that touch many items at once, or the delta itself becomes the whole set.
• Unapplied payments that are really old may need write-off or refund decisions, which are the human part of the workflow.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HYa5LdOIS3gkdCb7IKwgMw