A recommendation layer for NBFC recovery agents, sequenced so the model is useful without becoming the agent's starting point.
47 days and a hardship flag pull opposite ways. One says escalate, the other says restructure. This is the judgement the agent is paid for.
A broken promise sits beside two kept ones. Any tool that reduces this to a score has thrown away the thing that decides the call.
Contact history on the same screen, not behind a tab. The agent has under ninety seconds per case.
The console isn't opened once. An agent works a queue, and the case screen is one stop inside it. Every design decision downstream has to survive being made forty times before lunch.
That's the argument for the whole product. A tool that costs ten extra seconds per case costs seven minutes a shift. A tool that lets an agent skip thinking saves them nothing and costs the company the recovery.
Design an AI panel in isolation and you optimise for the demo. Design it as the fourth thing an agent looks at in ninety seconds and you get different answers.
14 of 40 worked is the number the agent is actually measured on, so it sits in the header rather than a dashboard.
Flags are dots, not badges. At forty rows, badges become a wall of colour and stop meaning anything.
Every decision-support tool I looked at puts its recommendation on screen the moment the case opens. The agent reads it before weighing the 47 days, the hardship flag, or the broken promise.
From there they aren't deciding what to do. They're deciding whether to disagree, which is a different and much lazier task. At forty cases a shift, nobody disagrees.
It doesn't feel like influence from the inside. It feels like the tool saving you time.
Read first, so it becomes the frame. Everything below is now measured against it rather than against the case.
The options are still live, but the decision has effectively been made. This is the industry default, not a strawman.
The question was never whether to show the model's output. It's when. Three of these fail for the same reason, and the reason isn't obvious until they sit side by side.
Grey blocks are case facts and options. The solid dark bar is the model's suggestion. The black bar is commit.
The agent picks an action and commits. The support panel is inert until they do, and says plainly why rather than just showing a lock.
This is the highest-consequence button in the product, so the line under it states what commit means: the decision is written before the suggestion appears. A control that changes what you can un-know should say so.
Commit your decision to reveal. Your call is logged first so the comparison stays honest, the model can't anchor you, and you can't anchor to it.
Dark, full width, no competing action. Nothing else on the panel can be mistaken for it.
Two lines of consequence directly beneath. Most products put this in a modal after the click, which is after it matters.
The locked state explains its reasoning rather than asserting a rule. An agent who understands why won't try to route around it.
Second case. No contact note, no recorded payment, no promise history. A model that answers anyway is guessing in a confident voice, and the agent can't tell that apart from a good answer.
So it returns nothing, itemises what's missing, and routes to a lead. The framing is what the agent can do, not a confidence score they can't act on.
A system that is always sure is a system you eventually stop checking. The refusals are what make the answers worth reading.
The slot stays and reads None. Hiding the panel would leave the agent wondering whether it failed or was never called.
Three named gaps, not a percentage. "Confidence 34%" tells an agent nothing they can act on. Three missing fields tells them exactly what to go and get.
Every dead end has one exit. There is no state in this product where the correct move is to stare at the screen.
The request fails or returns something unreadable. Most tools show a toast and an empty panel, stranding the agent mid-case with nothing to act on.
This says three things: what happened, that the decision stands and is already recorded, and what to use instead.
Because the human commits first, an outage costs the agent nothing. The work is already done. That isn't error handling, it's a consequence of the sequence.
"Your decision stands and is already logged" is the whole message. The agent's first fear is that they've lost the work.
The policy clauses render in full, with the eligibility test. When the model is gone the interface has to do the model's job.
The agent isn't made to read a paragraph to reach the answer. The action comes first, then the case facts that triggered it, then the clause, then the source document.
An agent defends this call to a lead, and eventually to an auditor. Every layer exists because someone downstream asks for it, not because more explanation is friendlier.
Answer. Three words. On the fast cases the agent reads this and nothing else.
Evidence. Four case facts, each checkable against the file. Not prose, a list an auditor can tick.
Policy. The clause and its eligibility test, so the agent can confirm the model applied it correctly rather than trust that it did.
Provenance. "Pending policy check". The system doesn't claim the call is approved, only that it's recorded and matched.
When the two calls differ, nothing is corrected and nothing is blocked. The difference is recorded, and the interface states where the two reasonings diverged rather than only flagging that they did.
Every disagreement becomes an auditable pair: a human judgement and a machine judgement on the same file, each with a stated reason.
Agreement rate is a vanity metric. The disagreements are where you find out whether the model is wrong, or the policy is.
Side by side, equal weight, neither styled as correct. Putting the model's call in a highlight box would answer the question this screen is meant to leave open.
The divergence is explained as what each side weighted. That's the sentence a lead needs; "they disagree" isn't.
Dispute reverses nothing. It routes, stores both, and asks for the agent's note, which is the input the model actually needs.
Collections is regulated. The useful consequence of committing first is that the audit trail falls out of the interaction. There's no separate logging step, because the order of events is the log.
The same record rolls up per session, which is what makes the word calibration mean anything: an agent can see their own divergence rate before anyone else does.
This record is the product's real asset and its real risk. It's a model-improvement loop if a team lead reads it, and performance surveillance if a manager does. That's a policy decision, not a design one, and it has to be settled before this ships.
Five seconds between the human call and the model's. The gap is the whole product, and it's visible in the timestamps.
Marked immutable at the moment of commit. If the record could be edited afterwards, none of the rest of this means anything.
The agent sees their own divergence rate first, in their own session. Whether anyone else sees it is the unresolved question two slides from here.
Right now, no. If I allow it, the second decision is contaminated by definition and the calibration record has to store both. If I don't, the tool is telling an agent to ignore information it has just handed them. I don't know which is worse, and I don't think I can know without watching someone use it.
A lead reading it to find bad policy is a feedback loop. A manager reading it to rank agents is surveillance. Same data, same screen, entirely different product, and agents will work out which one it is inside a week.
I've stamped agent_2841 on the audit trail, which quietly leans toward the second reading. I left it because collections records are regulated and have to be attributable, but I'm aware that's a decision I made without deciding it.
I couldn't get access to one. Everything here rests on published collections process, RBI recovery guidance, and reasoning about how queue work behaves under time pressure. The anchoring effect is well evidenced in the literature; my specific fix for it is untested.
Three failure paths, and none leave the agent stuck. That's the test I kept returning to: if the model does nothing useful, does the work still get done?
Shown first, this is an architecture diagram. Shown here, every box on it is a decision you've already watched me argue for.
| Conventional | This | |
|---|---|---|
| Order | Suggestion first | Human commits first |
| Evidence | Behind an expander | Facts and clause on the panel |
| Uncertainty | Always answers | Declines and names the gaps |
| Disagreement | Treated as agent error | Logged as a calibration signal |
| Model failure | Blocks the workflow | Decision already stands |
| Audit | Reconstructed after | A by-product of the sequence |
A browser prototype running against a local LLM, so the interaction was tested against real model output, including the runs where it was inconsistent or wrong, rather than scripted responses. The HTML scaffold was AI-assisted; the system prompt, the failure states and the decision architecture are mine.
Shibil Mohammed · ntshibil@gmail.com