Policy assistant inside the loan origination system

The leak

Sales staff and credit managers work inside the loan origination and onboarding systems all day, and all day they have questions. What does policy say about this income type. Which document is acceptable here. Why is this step blocked. The policy documents are long, the people who know the answers are busy, and the support queue fills with questions that have been answered a hundred times before. Every question costs the asker a wait and the answerer an interruption, and the customer in front of the sales person waits with them.

Nobody could see the questions in aggregate. The support team saw tickets. The policy team saw a document they had published. Neither saw that the same question was being asked across the same regions in the same weeks, which is a training problem, not a support problem.

The constraint

The assistant had to live where the staff already are, inside the origination and onboarding systems, not in a separate chat window. It had to answer from the company's own policy and the platform documentation, not from a model's general knowledge, and it had to know when it did not know. Policy changes, so the knowledge had to be updatable by the policy team without an engineer. And the first version could only read: no actions on live systems until the read-only behaviour had earned trust.

The system

An orchestrator sits in front of several retrieval systems. A question is first understood and routed to the knowledge base that can answer it: lending policy, product rules, platform how-to, or the technical knowledge base built from six months of resolved support conversations. The answer comes back with its source. When a question needs a person, a manual override, a system fix, an exception, the assistant says so and drafts the support ticket with the context already filled in, so the asker submits in one click and the support team starts with the facts.

Behind it, an admin panel the brief never asked for. It shows the request volume by topic, the clusters of questions, where answers were rated unhelpful, and which regions and roles ask what. That view belongs to the policy and operations teams: it tells them where understanding is failing, so they fix the material or the process and watch the question volume on that topic fall.

The next version adds toolkits over internal APIs, in read-only mode first, so the assistant can look up the state of a file or a step and answer "why is this blocked" from live data rather than from documentation.

The number

Questions answered in place, tickets drafted when needed, and the question volume by topic shown to the people who can remove the questions. The second product, the training-gap view, turned out to be the more valuable one.

What I would do differently

Build the technical knowledge base earlier. The assistant could answer policy from day one because policy was documented; it could not answer platform questions until the support conversations had been mined into documentation that did not exist before. That mining should start the day the support dashboard goes live, not months later.