You’re asked to “use AI agents”—but what actually needs fixing first?
The request usually lands as a slogan: “use AI agents to speed up underwriting.” Then the same week you still have queues, follow-ups, and policy questions piling up. That’s because cycle time rarely comes from one slow model decision; it comes from small handoffs—collecting missing docs, re-keying data between systems, chasing clarifications, and writing the same rationale in three places.
Before you pick an “agent,” pick the bottleneck you can name in plain language. If you can’t point to a step, an owner, an input, and an output, you won’t be able to test anything or explain outcomes to audit. The hard part is unglamorous: mapping what happens today, including exceptions, and admitting where rules live in email threads instead of policy.
Start by replaying a handful of recent files end-to-end and marking every moment a human waited on something. Those waits tell you what actually needs fixing—and what an agent would have to touch to matter.
Where does your underwriting time really go when you replay the last 20 files?
Those waits look obvious in the moment, but they blur together until you force a replay. Pull the last 20 files that represent your real mix (easy, messy, near-decline, exceptions) and rebuild the timeline from first touch to decision. Don’t estimate. Use what you can observe: email timestamps, task queues, LOS notes, document upload times, and rework loops.
As you replay, tag each delay with a plain label: “missing doc,” “identity/KYC follow-up,” “income calc clarification,” “policy interpretation,” “re-key between systems,” “narrative write-up,” “second review,” “waiting on vendor result.” Then separate “work time” from “elapsed time.” Ten minutes of income math can create two days of elapsed time if it triggers a borrower ping and a manager sign-off.
You’ll hit a constraint fast: your systems often don’t capture why something stalled, only that it did. That’s still useful—because it tells you where an agent can assist, where it can delegate, and where full automation would be reckless.
The first fork in the road: assistance, delegation, or full automation?
When a stall shows up in your replay, the temptation is to say “automate it.” In practice, you’re choosing how much the agent is allowed to change the file versus just speeding up the human who already owns the decision.
Assistance keeps the underwriter in the driver’s seat: the agent drafts the rationale, summarizes bank statements, or pre-fills fields, but nothing posts to systems without a click. This works well when the pain is writing and re-keying, and when you need tight control over wording and sources. The cost is that you may not cut elapsed time if the real delay is waiting on a borrower or a second review.
Delegation lets the agent complete bounded tasks—order a report, send a missing-doc request, create a case note—based on clear rules and templates. Full automation means the agent moves the file to “approve/decline” without human sign-off. That last step fails fast if you can’t point to evidence: what inputs it used, which policy it applied, and why it ignored the alternatives.
If an auditor asked “why,” which steps would you struggle to evidence?
That last step fails fast because the “why” has to survive outside your team. When an auditor asks why an income calc changed, why a condition was waived, or why a thin-file applicant was treated as “standard,” the weak spots aren’t the final decision—they’re the micro-decisions in the middle. People make them in Slack, in a phone call, or in a mental checklist, then paste a clean story into the LOS later.
Walk through a recent exception and ask three questions at each step: what was the input, what rule or policy text did it map to, and where is the proof stored? The steps that break are familiar: “we used the newer paystub,” “we ignored that alert as a false positive,” “we accepted an alternative doc,” “we escalated because it felt off.” Each one is defensible, but only if you can point to the artifact and the policy version that allowed it.
Agents amplify this gap because they move faster than your documentation habits. If you can’t log sources, prompts, outputs, and overrides in a way audit can replay, you’ll end up slowing the process down to rebuild the trail after the fact—which is exactly what a safe pilot has to avoid.
Pilot choices that don’t bet the bank: which tasks are high-leverage and low-regret?
If your trail is hard to replay, the safest pilot is one that improves speed without changing the decision. Start where underwriters lose time but audit risk stays contained: document intake and normalization (rename, classify, extract key fields with citations), bank-statement and paystub summaries tied to page references, and rationale drafting that pulls from your policy library and the file’s artifacts. If the output is wrong, the underwriter can spot it before it posts anywhere.
If elapsed time is driven by back-and-forth, pilot delegation with tight bounds: generate missing-doc checklists from a template, draft borrower messages, and open a task for a human to send. Avoid pilots where the agent “fixes” data across systems, waives conditions, or picks an override path. Those are where policy drift hides.
Pick two use cases that touch every file, not edge cases, then define a stop rule: one unexplained variance in calculated income, one unlogged source, or one message sent from the wrong template ends the test.
Guardrails you can defend: where humans sign off, what the agent can’t touch, and how exceptions flow
That stop rule only works if you decide, in advance, where the agent must hand control back. In a typical file, the risky moments aren’t the summaries; they’re the points where something gets posted, waived, or messaged to a customer. Put a human sign-off on any action that changes eligibility, pricing, conditions, or the data used to justify them. Keep “approve/decline,” overrides, and exception dispositions human-owned until you can replay outcomes with the same confidence you have today.
Then lock down what the agent can’t touch. No write access to the system of record by default. No free-form email sending. No ability to select vendors, switch policy versions, or merge identities. Treat credentials like you would for an intern: least privilege, time-bound access, and a clear list of allowed actions.
Exceptions need a simple path: when confidence is low or inputs conflict, the agent opens a task with the artifacts attached, cites the policy text it tried to apply, and stops. If you can’t see that handoff in your logs, you won’t be able to defend it.
After week two, what do you measure—and what would make you stop?
If you can’t see that handoff in your logs, you won’t be able to defend it—so start measuring from the log outward. By week two, you should know: median time-to-decision and time-in-queue, touches per file (including rework loops), and how often humans had to correct the agent’s extracted fields, summaries, or drafted rationales. Track exception rate and “why” quality: can a reviewer trace each output to a specific artifact and policy version without asking the underwriter to explain it live?
Define stop conditions that protect customers and your control environment. Stop if the agent produces one untraceable claim, uses an outdated policy snippet, sends a borrower message from the wrong template, or changes a field that later alters eligibility or pricing without a recorded human sign-off. Also stop if teams start working around logging because it slows them down; that’s a sign the pilot design, not the staff, needs fixing.
If the numbers improve but the evidence trail gets weaker, you didn’t speed underwriting up—you just pushed audit and remediation work downstream.
