Skip to main content
DoneThat

AI Adoption GuideBankingService

Agent assist copilot

LLM retrieves relevant policy, transaction history, and case notes in real time and surfaces the next-best action to the human agent during the call, using tools like Salesforce Einstein or Amazon Q.

Banking processAcquireOnboardOpenFundTransactServiceReviewClose

By Don, DoneThat’s AI coach · updated

Keep retrieval and action separate on the live call

An agent-assist copilot on a bank service call should retrieve the policy, transaction history, and case notes the agent is entitled to see, then surface a cited next action for the human to accept, edit, or reject. It should not invent a concession, display another customer's file, or change a product until the agent confirms.

The quality outcome is a next action the human still owns. Lookup can be faster and more consistent. Accountability for what the customer hears, and for any write to core or CRM, stays with the agent on the call.

Salesforce Einstein, Amazon Q, and Temenos belong to the same class of desktop, CRM, core, and knowledge layers that can host this pattern. Do not rank them. Do not assume a named capability exists on a given stack. Specify the control: entitled sources with cites in, a proposed action out, no write without confirmation.

This is not the same job as tier-1 service deflection, which tries to finish the request before an agent joins. Agent assist starts once the agent is live. It is also not agentic end-to-end case resolution. If the system can complete a card block or a fee adjustment without the agent saying so, you have left assist and entered unattended execution.

Pull only what this agent is entitled to see, and show the cite

Before the copilot suggests anything, it must know which customer is authenticated, which agent is logged in, and which roles that agent holds. Retrieval is scoped to that pair. Transactions, policy clauses, and case notes outside that entitlement must not appear, not even as a related snippet.

Every retrieved item needs a cite the agent can open during the call: policy ID and section, product version, knowledge article, case ID, or statement period. If the model cannot point to a source, it should say the source is missing rather than paraphrase a rule from training data. Contact-centre policy is local to the bank and the product version in force. A model that recalls a fee waiver from another institution is inventing.

Here is one illustrative path, not a measured result. A customer is on the line about an unexpected cash-machine fee after travel. The agent has verified the caller. The copilot should pull three things only: the authenticated customer's transactions for the relevant period; the current fee schedule for that product and channel; open or recent cases on that same customer that this agent is allowed to read. Each line carries a cite. The agent reads the cite, not a confident summary that cannot be checked.

If retrieval mixes files, stop the suggestion. Showing another customer's notes is a privacy incident, not a coaching note. The copilot must not include a similarly named account, a household member the agent cannot serve, or a prior case from a different customer ID that shared a phone number. Match on the authenticated customer key the desktop already uses. When identity is weak, retrieve less, not more.

Transcript text used as a retrieval query stays inside the same entitlement boundary. A mention of a relative's account is not consent to open that account. Do not use similar cases as a back door to other customers' notes.

Draft the next action as a proposal with grounds

Once cites are on screen, the copilot may propose one next action, or a short ordered list if the transcript is genuinely ambiguous. Each proposal names the action, the source it rests on, and what the agent would still need to confirm with the customer.

In the cash-machine fee path, a grounded proposal might be: explain the posted fee using the cited fee schedule section; offer to open a dispute journey if the customer claims the withdrawal was not theirs, citing the dispute procedure; offer a temporary card control only if the customer reports suspected misuse, citing the card-controls procedure. Those are suggestions. The agent chooses what to say.

Do not let the model invent a fee waiver because the customer is upset or because similar calls often receive goodwill. If the published policy does not contain a waiver path for this product and this fact pattern, the copilot must not propose one as if it were policy. If a discretionary goodwill path exists, it must cite the actual discretionary procedure and the approvals that procedure requires. Guessing a waiver trains agents to promise money the bank did not authorise.

If the call shows possible harm or distress, do not bury that under a generic next action for a fee. Hand the agent the relevant procedure for vulnerable customer detection as a cite, and keep the commercial action secondary until the agent has followed that procedure.

Repeat complaints about the same product failure are still this customer's case first. Patterns across the book belong in complaint root cause synthesis after the call, not as a live suggestion that names other customers.

Nothing writes until the agent confirms

Proposal and execution are different steps. The copilot may pre-fill a dispute form, a case note, or a card-control request. It must not submit them.

Confirmation is explicit: the agent accepts, edits, or rejects. A pause on the line, or the customer saying yes to the agent, is not confirmation to the model. The agent is the only principal who can authorise a write.

A card block is the failure mode to design around. If the copilot infers fraud from two cities in one day and posts a block because the next action sounded urgent, you have executed without the agent. The customer may be standing at a till. The agent may have already established a legitimate travel pattern. Urgent suggestions stay on screen as suggestions. The block waits for the agent's confirm.

The same gate applies to fee reversals, limit changes, contact-detail updates, and case closures. A drafted SMS or email is still a write when it leaves the bank. Queue it until the agent sends.

After confirmation, log the cite set the agent saw, the proposal, the agent's decision, and the resulting transaction or case ID. That trail is how you coach quality: not whether the model was fluent, but whether the action matched entitled sources.

Treat these failures as incidents, not model quirks

Inventing a fee waiver. The model states a goodwill reversal as fact. The agent, under time pressure, repeats it. Operations then holds a promise with no policy behind it. Refuse uncited concessions. Require the discretionary procedure ID before a money movement can even be proposed. Sample calls where value moved and check the cite, not the model's tone.

Showing another customer's notes. A fuzzy name match or a shared device ID pulls the wrong case. The agent may not notice mid-call. Bind retrieval to the authenticated customer key. Suppress cross-customer similar-case panels. Run entitlement checks on every snippet. Treat a wrong-customer display as a privacy event with the same severity as an agent opening the wrong desktop.

Executing a card block the agent did not confirm. The model equates suggestion with safety and calls the control API. Separate read tools from write tools. Write tools require an agent-scoped confirm step. Do not default irreversible controls to on, even when the transcript mentions fraud.

Weaker but still costly defects: citing a retired product version; summarising policy so loosely the agent cannot find the clause; stacking three next actions so the agent rubber-stamps the first. Each of those is coachable if cites and confirmations are logged.

If you cannot enforce entitlement, citation, and confirm-before-write on the stack you have, do not put the copilot on live calls. A slower manual lookup is better than a fast, uncited, or unconfirmed action.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first