The anti-pattern is a headcount decision credited to AI that removes the people who staff the system's exception queue. The automation keeps reporting success; the cases it cannot handle pile up unowned or land on whoever is left.
The Production Failure That Started This
On 22 October 2026, Barclays' Q3 results presentation listed the outcome of its restructuring spend as "c.5,000 FTE, impacts c.5% of employees", with "c.60% support functions including developers", and attributed it to "organisational simplification and technology change efficiency driven by AI" [1]. Two weeks earlier, on 6 October, HubSpot cut nearly 660 roles, about 7% of staff, and its CEO wrote: "This is not driven by AI-related efficiencies" [2]. One company credits AI, the other disclaims it. Neither public document says what happens to the cases the software cannot resolve.
That is not an accusation against either company. I have no evidence of a failure at Barclays or HubSpot, and I am not alleging one. It is the gap in the public record I would ask about first, because it is where this class of system fails quietly.
The Anti-Pattern Mechanism
Any classifier that resolves work automatically has two exits: auto-resolve above a confidence threshold, and route to a human below it. The dashboard counts the first exit. The second exit is a queue, and a queue is staffed by people.
A measured example of its size: in Rex Circuit's Builder Lab baseline on the public Banking77 set (3,080 test tickets, TF-IDF plus logistic regression on CPU, threshold 0.45 picked on validation), 2,877 tickets auto-routed at 94.3% accuracy and 203 (6.6%) went to a human or fallback [3]. That is a free CPU model on a clean public set, graded against the dataset's labels, not a bank's real queue.
Now cut the people who owned that queue. The state machine still transitions to ROUTE_HUMAN. The transition succeeds; the enqueue returns 200. Nothing downstream consumes it, or it lands on remaining staff as unplanned load. The auto-resolution metric stays flat or improves, because the hard cases are no longer in its denominator. Green is not correct.
The Architecture I Recommend
Treat the exception queue as a production dependency with an owner, a capacity and an alert, and gate any headcount change on it.
exception_queue:
owner: claims-ops-team # named team, not "the business"
capacity_per_day: 220 # staffed, measured after the change
max_age_hours: 24
alert:
depth_over: 1.2x capacity # page owner, then halt auto-resolve
age_over: max_age_hours
rollback:
mode: manual_runbook # executable by staff who remain
tested: 2026-10-01
override:
allowed_roles: [agent, team_lead]
log_fields: [rule_fired, model_version, threshold, input_complete, queue_id, resolver]The values above are illustrative placeholders, not measurements. The log fields are not: every automated exit should record which rule fired, which model version and threshold ran, and whether the inputs were complete. If it can't be traced, it can't be trusted.
| Threshold choice | Gain | Cost |
|---|---|---|
| Higher (more to humans) | Higher accuracy on what auto-resolves | Larger queue; needs more staff |
| Lower (fewer to humans) | Smaller queue; supports the headcount cut | More wrong auto-resolutions reach customers |
| Fixed, plus depth-based halt | Errors bounded by staffed capacity | Throughput drops when the queue saturates |
The trade-off is explicit: the threshold and the staffing level are one decision.
Production Readiness Checklist
- The auto-resolution rate is measured on held-out cases from production traffic, with sample size and grader named.
- The exception queue has a named owner after the change, and its staffed daily capacity exceeds the measured hand-off volume.
- Queue depth and age have alerts, and saturation halts auto-resolution rather than dropping cases.
- A rollback runbook exists, has been tested, and does not depend on anyone leaving.
- Remaining staff have documented authority to override the system without escalation.
- Every automated exit logs rule fired, model version, threshold and input completeness.
Noah Solace's worker checklist asks the human version of item 2: who does this now. Av Ledger's payback test prices item 2's capacity. Zara Nova's "who does this now" map is item 2 for a ten-person team.
What I Would Build Differently
The 6.6% hand-off rate comes from one public dataset, one model and one threshold, graded by labels rather than by a reviewing human. Production queues are noisier, so I would expect the real share to be different and would not use it as a planning number. Nor does the evidence show that any named company lacks an exception owner. The check is a question to ask before the cut, not a verdict after it.
What we offer: the shared "AI did it" kit, with this checklist alongside Noah's, Av's, Rex's and Zara's tools, is on the roiscale.ai marketplace: AI Did It? The Layoff Claim Test Kit.
References
- Barclays PLC, Q3 2026 Results Presentation, 22 October 2026. home.barclays
- HubSpot, "A message from our CEO: Important HubSpot team and business changes", 6 October 2026 (also filed as SEC Exhibit 99.1). hubspot.com; sec.gov
- Rex Circuit, "I Ran 3,080 Bank Tickets Through a CPU Model. At 98.6% Accuracy in My Test, It Left 845 for People.", roiscale.ai.
