Take one concrete case. A customer disputes a €212 card payment — a chargeback. Today a human agent opens the case, pulls up the order and delivery records, reads the card network's reason code, checks which evidence the network's rules require for that code, drafts a response, attaches the evidence, and files it before the deadline. Call it fifteen minutes of reading, checking, and form-filling. A mid-sized payments or e-commerce operation handles thousands of these a month, and the same shape repeats everywhere: VAT filings, KYC reviews, refund approvals, back-office healthcare paperwork. Rules plus documents plus a decision.
Everyone can see an LLM should be able to do this. The interesting question is what the system around the model has to look like before you'd let it — because the money moves, an authority or card network is on the other end, and someone will eventually ask why did you file that? So let me walk through the pipeline stage by stage, as an engineering problem.
The pipeline, stage by stage
1. Intake and classification. The case arrives and gets classified into a decision class — not just "chargeback" but "duplicate-charge dispute under €100" versus "fraud claim" versus "novel case type we haven't modelled." Everything downstream keys off this label, so it's a first-class model task with its own accuracy tracking, not an afterthought.
2. Extraction. The model reads the unstructured mess — dispute notice, order history, delivery confirmation — and produces typed, structured fields: amounts, dates, reason code, customer identifiers. This is the mature part of the stack; modern document AI hits high-90s accuracy on structured documents, and it's where most vendors stop. Extraction is table stakes; the decision is the product.
3. Policy retrieval. The system pulls the rules that govern this decision class from a versioned knowledge layer: the card network's evidence requirements for reason code 13.1, your internal refund policy, the jurisdiction's quirks. Retrieved, not memorised — because policies change, and "the policy changed but the model didn't hear" is the most preventable failure in this whole domain. This is the knowledge-layer argument made concrete: the automation is exactly as trustworthy as what the system knows.
4. Decision draft. The model applies the retrieved policy to the extracted facts and produces a recommended action — "accept the dispute and refund" or "contest with this evidence bundle" — with each claim in the draft citing the document and policy clause it rests on. Citations aren't decoration; they're what makes stage 6 reviewable in seconds instead of minutes.
5. Confidence and routing. The draft gets a calibrated confidence score, and a routing policy decides: execute automatically, or queue for a human. This pattern is not exotic — it's been productised for years. Amazon A2I exists precisely to route predictions below a confidence threshold to human reviewers, and AWS publishes a worked example with Textract where low-confidence form fields trigger a human loop and a random sample of confident ones is audited anyway. What LLMs change is the ceiling: the whole decision can now be drafted, not just the field extraction.
6. Execution or review. Auto-approved actions run through idempotent, narrowly-scoped tools — tool contracts, so a retry can't refund twice. Everything else lands in a review queue where the human sees the case, the draft, and the cited evidence side by side, and approves or corrects in one action. Every correction is captured as a labelled example.
7. The audit record. For every decision, automated or human: the inputs, the knowledge version consulted, the model and prompt versions, the confidence, the route taken, who (or what) executed. When the card network, the auditor, or an angry customer asks why, you replay the record. "The model said so" is not an answer; this is.
The routing table is where the judgement lives
Here's the heart of the system — the part that's policy, not model:
# decision-class routing policy (excerpt) duplicate_charge_refund auto if conf ≥ 0.97 and amount ≤ €100 subscription_cancel_refund auto if conf ≥ 0.95 and amount ≤ €50 dispute_response_filing draft → human approves fraud_claim draft → human approves, always anything ≥ €5,000 draft → human + second sign-off novel_case_type human (no model path yet) audit_sample 5% of all auto decisions → human review
Three things to notice. Autonomy is granted per decision class, not per process — "we automated chargebacks" is not a statement this table can even express. The thresholds are parameters, not vibes — they're set from measured calibration, and they're versioned and reviewed like any other config. And the audit_sample line means automation never goes unwatched — a slice of the machine's own decisions is always flowing past human eyes, which is how you notice drift before your customers do.
Where the thresholds come from
A confidence score is only useful if it's honest. If the cases your model scores at 0.95 are actually correct 95% of the time, you can reason about risk; if they're correct 80% of the time, your 0.95 is a lie with decimals. So you measure calibration per decision class against real outcomes, and you maintain a golden set per class — a few hundred adjudicated cases — that runs on every change: model upgrade, prompt tweak, policy update in the knowledge layer. Promotion works like a deployment pipeline: a decision class starts at draft, accumulates evidence in the queue (agreement rate between drafts and human decisions), and gets promoted to auto only when it clears the bar within an explicit error budget. Every incident becomes a new golden-set case. Demotion is one line in the routing table — a kill switch per class, not a system-wide panic. Feelings aren't findings anywhere in AI; here, the findings decide whether money moves unwatched.
Why this is worth building properly
The industry numbers make the gap plain. Across accounts-payable teams, only about a third of invoices are processed with no human touch today; best-in-class teams manage roughly half, and well-built AI pipelines reach 60–70% straight-through processing. The cost spread is $12.88 per document over 9.2 days manually, versus $2.88 over 3.1 days automated — and the latency often matters more than the cost, because an answer in seconds instead of days is a different product, not a cheaper process.
But the number to optimise is not the automation rate — it's the trustworthy automation rate, because the errors are asymmetric. One fraud claim wrongly auto-refunded, or one filing auto-submitted with the wrong evidence, costs more than a thousand correct automations save — in money, in audit exposure, and in the organisation's willingness to let the system keep running. That's why the ladder matters: every class starts at draft (the same human-gate discipline I argue for in agentic delivery), earns auto on calibration evidence, and keeps earning it under sampled audit. The gate isn't permanent friction; it's the mechanism that generates the evidence for its own removal.
The ratchet beats the leap
Notice what the straight-through rate becomes in this design: not a hope, but a dial. Each quarter you look at the queue data, find the decision class with the best volume-to-risk ratio, do the work — more golden cases, better retrieval for that class, maybe a cheaper specialised model — and promote it. Deciding which class to chase next is genuine roadmap work, sitting exactly where product, business, and engineering meet. The teams that win here won't be the ones that automated fastest in the demo; they'll be the ones whose machinery — provenance, knowledge, calibration, evals — lets them raise the rate every quarter and never walk it back. In regulated automation, boring machinery is the moat.