Precedent reconciliation that remembers the running approval screen →

An agent that writes
its own knowledge base.

Reconciliation exceptions are resolved by an agent that retrieves precedents from past resolutions. Every confirmed resolution is written back as a new precedent, so the corpus is authored by the system’s own operation — and autonomous resolution rate is the measurement, not the claim.

0%20%40%60%80%100%03367100134precedents depositedretrieved precedentsonly-a-precedent casesrandom controlrules alone, 49.2%
Held-out exceptions replayed against the corpus at five sizes. The test set is never deposited: each point asks the same questions of more accumulated knowledge. The control draws the same number of precedents from the same corpus and differs only in whether they are relevant.
70.0% → 86.7% resolved without a human, as the corpus grew from 42 to 151 precedents
56.7% → 61.7% the random control over the same range — flat, which is what rules out “more text in the prompt”
p = 0.041 paired exact McNemar, 15 cases gained against 5 lost

What an exception looks like

A payment from Coral Textiles. The bank credit is net of the processor’s fee; the invoice is gross. Those are two different comparisons, and collapsing them into one “matches / does not match” line is what makes reconciliation tools untrustworthy — the reviewer can no longer tell a genuine shortfall from a fee deduction.

At the bank

Payments captured, gross1,678.00
processor fee (39.60)
tax on the fee (6.04)
Should have landed 1,632.36
Actually landed1,632.36
Unexplained0.00

The credit ties out.

Against the invoice

Ledger expects, gross1,864.44
Customer paid, gross1,678.00
Kept back 186.44

The customer withheld part of the invoice.

How it decides

A LangGraph investigation with a verify → revise cycle. Two of these steps deliberately do not call a model.

  1. classifyproportional shortfall

    Computed from the case, not asked of the model — naming the class before the evidence is gathered would anchor every step after it.

  2. retrieve5 precedents, BM25 over the corpus

    Searched with the computed observations rather than the whole record dump: the per-record boilerplate buries the few sentences that discriminate.

  3. investigatefetch_payment · compute_expected_amount(rate 0.10)

    A tool loop capped at five calls in code, not asked of the model. The arithmetic tool is the same code that will check the answer, so a figure from it cannot disagree with the verifier.

  4. proposetds_short_payment @ 0.96, citing precedent 2

    Structured output, Pydantic-validated. A parse failure escalates rather than guessing.

  5. verifypassed

    Deterministic. A check performed by the model being checked samples the same distribution that produced the error.

  6. routeabove the 0.90 threshold — resolve

    The threshold is set from measured outcomes, not chosen: it gives up one case of coverage to remove ₹23,739 of false-resolution exposure.

The same customer, before and after

Konark Logistics deducts a rebate negotiated with them. It is not a statutory rate, and nothing in the case says what it is — so the answer cannot be worked out from the evidence. It can only be remembered.

First time it saw them

corpus: 42 hand-written precedents, none about this customer

Shortfall against the invoice2.65%
Matches a statutory bandno
Explained by fees or a refundno

Escalated at 0.65 confidence.

Correct behaviour: the evidence is genuinely insufficient. A guess here would close an invoice that was never settled.

After a reviewer resolved one

corpus: one precedent about Konark Logistics, written from that resolution

Situation. Payments from Konark Logistics arrive short of the invoice by 2.65 percent, a proportion matching no statutory withholding band, with no refund or fee explaining the gap.

Resolution. Konark settles under a negotiated rebate agreed in their supply contract. Reconstruct the invoice from the receipt and close it in full. This is not withholding tax: no tax credit arises.

Resolved as a negotiated rebate at 0.94, citing it.

Written generically — “this counterparty” rather than the name — the same knowledge resolved 1 case in 5. Naming them resolved 4 in 5. A customer name generalises to that customer’s future cases; a payment id generalises to nothing. That distinction is now in the deposit prompt, with the measurement attached.

Nothing is deposited without a human

A confirmed wrong resolution does not cost one record. It is written into the corpus and then retrieved to justify future wrong ones, which makes corpus poisoning the most serious failure mode in the system — and this screen the only thing standing between it and the corpus.

Confirming writes this into the corpus. It will be found and cited on future cases that look like this one. Decide on the figures and the precedents, not on the verdict.

What deposits

Confirmedyes
Correctedyes, at the corrected answer
Rejectedno
Unreviewednever

A corrected resolution is the higher-value precedent: it records a case the system got wrong.

Under a realistic reviewer

Confirmed66
Corrected44
Rejected24
Precedents from 134 cases109

The curve above is measured this way — rejections included — so it is an estimate rather than a ceiling.

Does it work

DepositsCorpusResolved ControlOnly-a-precedent cases Escalated
04270.0%56.7%0.0%8.3%
337078.3%58.3%50.0%18.3%
679681.7%66.7%66.7%18.3%
10012186.7%60.0%72.2%10.0%
13415186.7%61.7%83.3%13.3%

Paired significance, first snapshot to last

ComparisonW–L p
headline 15–50.04139significant
control 10–70.62906not significant
counterparty 15–00.00006significant

What the tools do to the case for retrieval

The gain over answering with no precedents at all splits into an effect of having precedents and an effect of their relevance. Giving the agent investigation tools removes the first entirely.

from having precedents from their relevance
single prompt +14.2pp +9.0pp
with an investigation graph +0.0pp +9.7pp

What this does not show