agent consumed the whole token budget explaining 2,000 trivial penny breaks and never reached the five material...

TL;DR

The agent worked hard in the wrong order: exceptions were processed in file order, and two thousand one-cent breaks each received a full explanation until the budget died five items short of the ones that mattered. Triage must happen before narration, mechanically: sort and group exceptions by absolute amount and type, auto-dispose of the penny population as one aggregated item (a count, a total of a few dollars, and the known rounding cause, with the detail attached as data), and spend the analysis budget on the material exceptions first. Set the run's contract explicitly: materiality threshold, maximum share of budget for the trivial class, and a completion rule that the report must cover every material item even if the trivial narrative is cut. Penny breaks deserve a line, not a chapter, and the five material exceptions deserve the agent's full attention while budget remains.

agent consumed the whole token budget explaining 2,000 trivial penny breaks and never reached the five material exceptions

Use this when

• An agent exception report exhausts its budget, time or output limit on trivial items and omits material ones.
• The exception population mixes thousands of rounding differences with a few large breaks.
• Stakeholders read the report's omissions as the agent missing the important problems.

Not for this skill when

• Small breaks are individually significant, as in fraud, skimming or regulatory penny-testing investigations. There, the trivial class is the case.
• The run failed for infrastructure reasons before any reporting. Fix the runtime first.

Steps

1. Reconstruct the run: exception counts and totals by amount band, and where the budget was spent, from the agent's logs. Verify: the misallocation is quantified - how much budget the penny class consumed
2. Define the materiality policy with the controller: threshold amount, trivial-class handling, and the rule that material items are reported first and always. Verify: the policy exists in writing with named thresholds
3. Re-run the reporting with mechanical triage: penny breaks aggregated into one item with detail attached, material exceptions analysed individually in descending amount order. Verify: the new report covers all five material exceptions and summarises the penny class in one section
4. Encode the triage and budget allocation in the agent's job configuration, including a reserve that trivial-class work can never consume. Verify: the configuration enforces ordering and the budget reserve
5. Review the first two runs under the new policy with the controller and tune the threshold against what the material class actually contained. Verify: thresholds are validated on real runs and the policy is signed off

Variant phrasings

agent spent budget explaining penny breaks never reached material exceptions

The mis-prioritisation symptom.

materiality triage agent exception report aggregate trivial rounding breaks

The triage-design phrasing.

agent report ordering by amount risk budget allocation exceptions fix

The ordering rule search.

Compatibility: Agent exception analysis and reporting over reconciliation outputs in any ERP or close platform, with run budgets measured in time, tokens or cost.

Why it happens

Exception queues are adversarial to naive order: trivial items are numerous precisely because rounding is everywhere, while material breaks are rare by definition. An agent that processes a queue in arrival order with uniform effort per item will always drown in the numerous class before reaching the important one - the same reason human controllers triage by amount before opening a single item. The agent lacked not intelligence but a queue policy, and queue policy is a design input its owners must supply.

Edge cases / pitfalls

• Aggregate penny breaks still need their total proven immaterial: two thousand cents is twenty dollars, but two thousand larger trivial items may not be trivial in sum.
• A rising penny-break count is itself a signal about rounding configuration; report the count trend even when the items are aggregated.
• Fraud and error have different triage: keep a random sample of trivial items for individual review so aggregation never becomes a hiding place.

Provenance

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

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

Thread query: agent consumed the whole token budget explaining 2,000 trivial penny breaks and never reached the five material exceptions

TL;DR: The agent worked hard in the wrong order: exceptions were processed in file order, and two thousand one-cent breaks each received a full explanation until the budget died five items short of the ones that mattered. Triage must happen before narration, mechanically: sort and group exceptions by absolute amount and type, auto-dispose of the penny population as one aggregated item (a count, a total of a few dollars, and the known rounding cause, with the detail attached as data), and spend the analysis budget on the material exceptions first. Set the run's contract explicitly: materiality thresho