XIV · Anti-PatternsAnti-pattern✕

Refund Threshold Drift

also known as Refund Drift, Autonomy-Cap Creep

Anti-pattern: a correctly-set autonomous-refund cap drifts upward over time as the agent accommodates edge cases, so the effective approval ceiling and financial exposure grow silently with no hard limit to catch it.

Context

An agent handles refunds, credits, or payments with an autonomy cap: it may settle amounts up to a configured ceiling on its own and must escalate anything larger. The cap is set correctly at first. Over time, edge cases arrive — a slightly-over-limit refund for a loyal customer, a one-off exception a human would have waved through — and the agent or its operators relax the limit a little to accommodate them.

Problem

Each individual accommodation is reasonable, but there is no force pulling the ceiling back down, so the effective cap ratchets upward and financial exposure grows. Because the drift happens a little at a time through justified exceptions, no single decision looks wrong and nothing alarms; the control was correct when set and is never obviously broken. Without a hard limit enforced below the agent and a periodic review of the effective ceiling, the cap erodes silently until exposure is far above what was authorised.

Forces

  • Accommodating an edge case is locally reasonable, but each accommodation becomes precedent that nudges the ceiling up.
  • There is upward pressure (satisfy the customer, clear the queue) but no symmetric downward pressure to restore the original cap.
  • The drift is gradual and justified step by step, so no single decision triggers an alarm.
  • A correctly-set static cap looks safe on paper, hiding that its enforced value is creeping at runtime.

Example

A support agent may auto-approve refunds up to fifty dollars. A loyal customer is owed fifty-five, so the team lets it through; soon sixty for a comparable case, then seventy-five. Six months later the agent is routinely approving ninety-dollar refunds on its own, no one decided to set the cap there, and total refund exposure is well above what finance signed off on — until an audit notices the drift.

Diagram

Solution

Therefore:

Pin the autonomy cap as a hard constraint enforced beneath the agent — at the payment or refund API — so the agent cannot raise its own ceiling, and route any over-cap case to human approval rather than to a relaxed limit. Treat the cap as a number to be audited, not a one-time setting: review the effective approval ceiling and the distribution of approved amounts on a schedule, and reset drift back to the authorised value. Make exceptions explicit and logged rather than absorbed into the limit, so accommodating one customer never silently re-authorises the next. The control is the enforced ceiling plus the review, not the agent's judgement about what is reasonable this time.

What this pattern forbids. The agent must not raise or relax its own autonomy cap; the ceiling is enforced as a hard limit below the agent, over-cap cases are escalated rather than accommodated, and the effective ceiling is reviewed on a schedule rather than allowed to drift.

The patterns that counter or replace it —

  • complementsRisk-Tiered Action Autonomy★— Set an agent's permitted action class by the financial materiality of the action, letting it read and draft freely while requiring a different human principal to release material postings, payments, or filings.
  • complementsSession-Scoped Payment Authorization·— Bound an agent's autonomous spending by having it open a payment session with a pre-approved cap, stream many micropayments inside that session, and settle once on close, instead of seeking approval for every transaction.
  • complementsGuardrail Erosion Through Compaction✕— Anti-pattern: each compaction pass rewrites the running history, so a hard safety instruction is gradually paraphrased into vague advice and its force decays the longer the agent runs.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance