An auto refinance application touches a credit pull, document review, lender submission and customer messages, and each one lives in its own system with its own login. That's where the days go.
At TechFabric our team builds software for lenders, auto refinance companies and other companies in the financial services area supporting loan originations, refinancing, repossessions, remarketing and asset dispositions.
The steps themselves are well understood, and the delay comes from each step living in a different system with its own login, format and rules. A step can be automated only once whatever does the work can reach the systems around it.
MCP, the Model Context Protocol, gives an agent that reach, and applied to auto refinance it points to where we'd start.
Why integration stalls AI in lending
Lenders know this from the inside.
An agent in an auto refinance flow has to pull a credit report, read a payoff letter and check a lender's rate sheet. Without a standard protocol, each of those becomes custom glue code that someone writes and maintains.
What each agent does with MCP
In a refinance shop we'd split the work into specialist agents, each with a narrow set of tools.
- A credit agent calls the bureau tool and returns the result to the deal record.
- A document agent reads the payoff letter, registration and proof of income, and writes extracted fields to a governed table.
- An offer agent combines the extracted fields and the credit result with current rate sheets to produce a preliminary offer.
- A submission agent sends the package to lenders, and a second pass reads each lender's response, including a kickback for a mismatched odometer or an expired payoff.
- A customer agent sends SMS or runs a voice call with the borrower, using the deal's current status. We covered that piece in voice agents on Databricks for auto refinance.
We'd want the offer agent to read the current rate sheet and the customer agent to know when a lender last replied.
Governance and security on Databricks
MCP answers how an agent reaches a system. It says nothing about whether it should. That second question is why we'd build on Databricks. According to Databricks, it supports managed MCP servers, external connections and custom deployments, all governed through Unity Catalog, which enforces permissions, lineage and auditability across each agent interaction.
For a lender that has practical consequences. Databricks says Unity Catalog enforces permissions, lineage and auditability across every agent interaction, which is what we'd lean on for a compliance review.
Orchestrating the workflow
Databricks describes the Supervisor Agent in Agent Bricks as letting several specialized agents work under one supervisory layer; check its current release status in the Databricks docs before planning around it.
Workflows that keep learning
In lending, the live signal is a lender's reply and the learning is what the replies teach you. Log each lender decision next to the package that produced it, in a Delta table, and you can see which lenders reject which kinds of deal. We'd have the submission agent use that log to pick which lender to try first. Without that log, the same mismatched odometer gets kicked back again next week.
Start with one lender response
We'd pick the step where the most rework hides and put one agent on it first. For most refinance shops that's processing lender responses, because the replies are unstructured, the rework is expensive and the outcome is measurable. Expose one MCP server, give the agent one narrow tool set under Unity Catalog, log every call, and compare its reading of the replies against what your processors did last month. Add the credit pull and document extraction once that comparison holds.
Frequently asked questions
Does MCP replace our existing integrations with lenders and bureaus?
No. MCP wraps those integrations so an agent can call them in a consistent way. The connections to the lender portals and bureaus still exist underneath, and you decide which of them to expose as tools first.
How does Databricks extend MCP?
It adds the governance MCP leaves out. According to Databricks, managed MCP servers, external connections and custom deployments are all governed through Unity Catalog. Without that layer you'd build the permission checks and call records yourself. For a lender, that record is also what a compliance review would ask to see.
Should the SMS and voice agents be part of the same workflow?
Yes, but with their own narrow permissions. They need deal status and the borrower's contact details, and they don't need the credit report. Keeping them separate also makes it easier to review what a customer was actually told.
Where do these workflows not fit?
They don't fit a step where a regulation requires a person to decide. There the agent prepares the file and a person approves it, with the approval logged like any other action.
What does the supervisor agent add over calling each agent separately?
According to Databricks, the Supervisor Agent in Agent Bricks lets several specialized agents work under one supervisory layer. It delegates tasks across Genie Spaces, MCP servers and Unity Catalog functions, then combines what each returns. For a refinance deal, that means one place that knows where the file stands. We'd add it after the first agent's comparison against last month's processor work holds, so the first agent can be checked on its own.