AI agent case study: a lending agent that keeps loan applications moving, inside set limits

The challenge: helping three parties see what comes next

A small business loan on this platform passes between a merchant, who applies and sends documents, a funder, who reviews the deal, and a sales rep, who supports the process. Before the build, their conversations were spread across channels, timely follow-up was difficult, and the sales team had limited visibility into what each application needed next.

Each party needs something different from the same conversation. The merchant wants plain answers about the application. The funder wants talk about the deal. The rep wants to know where the pipeline stands. And the right answer depends on the stage: a new application, an approval, a decline, a missing document or a final deal each call for a different reply.

What we built: an AI agent that knows who it's talking to

The platform has three front ends, one per role, each a Next.js 14 app written in TypeScript and styled with Tailwind CSS: a merchant's view, a layer where funders interact, and a portal where reps track tasks, take escalations and watch the pipeline. Behind them, a Python and FastAPI service holds the APIs and the business rules and talks to the agent.

The agent's decision flow runs in LangGraph. Every message goes through three steps: the agent reads what's being asked and where the application stands, decides what it may do, and only then writes the reply. Google's Gemini 2.0 Flash does the language work. When a question needs something from a document or an earlier call, the agent searches the platform's PDFs and its past call transcripts, using Gemini embeddings and an Upstash Vector index. Supabase holds the applications, the activity and the platform's data.

Three engineering problems shaped it:

• Keeping roles apart. Each role has its own prompt and its own context layer, so a merchant's chat never carries a funder's details, and access rules decide what each person can see.
• Negotiating live. The agent can move a rate, a term or a loan amount during the conversation, and it has to keep that progress between messages although the API it runs on holds no state.
• Not repeating itself. In long sessions, 20 to 30% of conversations had the agent repeat an answer. Checks against repeats and controls on what it remembers brought that to about 5 to 10%.

Follow-ups are scheduled so they do not depend on a team member remembering each one. When an application is awaiting a response, APScheduler sends a reminder by SMS through Twilio or by email through Resend after 24 hours, again after 72, and again after 168.

Where the AI agent stops, and who takes over

The agent works inside written rules. These are the ones that stop it or send the conversation on:

The frustration score triggers the handoff. The agent evaluates each conversation as it progresses, and when the score indicates that personal support would help, the conversation moves to a rep with its context attached.

Results from trial usage

The scheduled follow-ups helped 10 to 18% more pending applications resume than when there was no automated follow-up. Failed payments fell through retries, clearer error messages and recovery that remembers where a payment stopped. These are figures from trial usage, not from production.

Technologies and tools

Timeline

The build took seven months.

If your own applications, claims or onboarding files stall between people, our page on AI agents for finance sets out how we scope an agent like this one and the rules it would work inside.