The best first use of an AI agent in lending is usually not the credit decision. It is the manual work surrounding that decision: collecting borrower documents, reading financial statements, moving figures into a spreading template, finding missing information, and routing exceptions to the right reviewer.

That distinction matters. A well-designed agent can make an operations team faster without becoming an unaccountable decision maker. The system handles repetitive preparation, records what it did, and gives a person a clear review queue for the work that needs judgment.

Start with the queue, not the model

Many lending teams begin by asking which AI model they should buy. The better starting question is simpler: where does a file wait for a person?

A borrower may upload statements through a portal. An operations analyst checks whether the package is complete, identifies each document, reads the values, enters them into another system, and flags anything unusual. The underwriter then waits for that preparation to finish. When a document is blurry, a number does not reconcile, or the entity name differs across files, the package moves backward through email or a task queue.

This is a good agent workflow because the inputs, expected outputs, and exceptions can be defined. The agent does not need unlimited authority. It needs access to a specific file set, a clear output schema, and rules for when to stop and ask for review.

Three lending workflows worth testing first

1. Borrower intake and document triage

An intake agent can watch an approved upload location, classify each file, associate it with the correct application, and compare the package against a required-document checklist. It can identify a missing tax return or an unreadable page before an analyst begins the full review.

The useful output is not a generic summary. It is a structured package manifest: which documents arrived, which period each document covers, what is missing, and what could not be read confidently. Every conclusion should point back to the source file and page.

This removes status checking without hiding uncertainty. Low-confidence classifications and conflicting borrower identifiers should go to a person instead of being forced into a best guess.

2. Financial spreading

Financial spreading is a strong candidate when analysts repeatedly transfer values from statements into a standard template. An agent can extract the reporting period, map line items into the lender's chart, preserve the source reference, and run basic reconciliation checks.

In one current Sennu engagement, we are building a financial spreading agent for a lender marketplace. It parses uploaded financial documents, spreads the data, and flags issues for lender review with less manual intervention. The important part is the last step: exceptions remain visible to the reviewer rather than being buried inside a polished output.

A production spreading workflow should retain the original value, normalized value, source page, mapping rule, confidence, and any validation result. That record makes review faster and gives the team evidence when a mapping needs to change.

3. Exception routing and follow-up preparation

Once documents have been classified and spread, the agent can prepare the next action. It might route a reconciliation problem to an analyst, prepare a request for a missing schedule, or surface two conflicting values side by side.

The system should not send every borrower communication on its own on day one. Start by drafting the request and placing it in a review queue. The team can measure acceptance, edits, and false alarms before expanding the agent's authority.

Keep credit decisions behind a stronger boundary

Operational automation and automated credit decisioning carry different risks. The Consumer Financial Protection Bureau has stated that creditors using complex algorithms still need to provide applicants with specific and accurate reasons for adverse actions. A model's complexity is not an exemption from that obligation. The CFPB's official circular on complex algorithms and adverse action notices is direct on this point.

That is one reason to begin with preparation and workflow assistance. The agent can organize evidence and flag exceptions while the lender keeps its established decision controls in place. Any later move into scoring, recommendations, or decisions needs separate legal, compliance, validation, and governance review.

Model governance should also match the actual risk and use. In April 2026, the Federal Reserve, OCC, and FDIC issued revised interagency guidance on model risk management, emphasizing a risk-based approach tailored to an institution's model use, size, complexity, and risk profile. The practical lesson is not that every document classifier needs the same process as a credit model. It is that the team should explicitly classify the use, its impact, and the controls it requires.

What the production workflow needs

A demo can turn one clean PDF into a neat table. Production needs to handle the other 20 percent: scans, rotated pages, duplicate uploads, changed templates, conflicting entity names, missing periods, and handwritten notes.

Before launch, define these parts of the workflow:

  1. Source boundary. Name the folders, document types, systems, and borrower records the agent may access.
  2. Output contract. Specify the fields, allowed values, source citations, and validations required downstream.
  3. Exception policy. Decide which conditions stop processing, lower confidence, or require human approval.
  4. Permission model. Give the agent only the access needed for the assigned job. Preserve the permissions of the underlying system.
  5. Audit record. Log the input version, extracted values, transformations, tool actions, reviewer edits, and final disposition.
  6. Evaluation set. Test against representative historical packages, including the difficult cases the team remembers.
  7. Rollback path. Make it possible to pause the workflow and return to the prior process without losing work.

The NIST AI Risk Management Framework provides a useful general structure for this work: govern, map, measure, and manage. It is voluntary and not lending-specific, but it gives delivery, risk, legal, and operations teams a shared vocabulary for deciding how a system should be evaluated and monitored.

Measure the operating result

Do not judge the pilot by whether the output looks impressive in a meeting. Compare it with the current queue.

Useful measures include the time from upload to a review-ready package, analyst minutes per package, the percentage of fields accepted without edits, exception precision, missing-document detection, and the age of work waiting in each queue. Track overrides as learning data, not as reviewer failure.

Run the agent beside the existing process first. When the team understands where it succeeds and where it escalates, let it own a narrow step. Expand only after the audit trail and exception handling are as dependable as the happy path.

The result should feel less like adding a chatbot and more like removing a queue. Analysts spend less time moving information between systems, while underwriters receive a clearer package with the source evidence still attached. That is where an AI agent starts becoming part of lending operations instead of another pilot on the side.