Before we wrote a line of extraction code for Maestro, we spent time inside origination workflows at a few different lender organizations. Not demoing software to them. Sitting with processors as they worked through loan files, asking what was hard, watching where time went.
What we heard changed some of our initial assumptions about what the product needed to do. The technology pitch for AI in mortgage often leads with vision: end-to-end automation, AI underwriting, decision intelligence. The practitioners we talked to had a very different list. Their requests were specific, bounded, and focused almost entirely on the part of the job they found least valuable.
What they kept telling us
The request we heard most often was not about credit analysis or risk scoring. It was about document organization. "Stop making me find things." A processor working 15 active files does not spend most of their day thinking about credit quality. They spend it opening PDFs, locating the right page, reading a number, entering it somewhere, then doing that again across a dozen document types per file. The intellectual load of that task is low. The time cost is not.
The second request: tell me what is missing before I start. The standard workflow involves receiving a borrower's document submission, opening the folder, and beginning review, only to discover mid-stream that a document is absent or a bank statement is missing the second month of a required three-month range. That discovery triggers a borrower contact, which adds days. Processors want the gap list before the review begins, not after.
The third request, which we heard from loan officers more than processors: show me the numbers side by side. When a loan officer is doing a pre-qualification assessment, they want to see gross income from the W-2, gross income as reported on the 1003, and the paystub year-to-date figure, in one view. Verifying that these three sources are consistent is a quick analytical step, but it requires navigating to three separate documents. A structured extraction that presents those fields together makes the consistency check a seconds-long glance rather than a five-minute exercise.
What they did not ask for
Nobody asked us to make the credit decision for them. We want to be direct about this because it is a meaningful design constraint. The loan officers we spoke with, without exception, described their role as the expert who reviews the file and makes the call. They were not looking for a system to tell them whether to approve a loan. They were looking for a system that handled the parts of the job that did not require their expertise, so they could spend more time on the parts that did.
This shapes how Maestro is built. The output of our pre-underwriting pass is a structured report with extracted fields, confidence scores, and flagged items. It does not contain a recommendation to approve or decline. That is intentional, and it reflects what the people closest to the work actually asked for. Not because we are being conservative about the technology, but because that is what is useful.
Similarly, we did not hear requests for chatbot interfaces or natural-language query on loan files. Those features are visually appealing in demos. In practice, a processor who knows they need to find the three-month bank statement date range does not benefit from asking a chat interface whether the bank statements are present. They benefit from a status table that shows all documents in the submission, their dates, and whether the date range is complete. The specific tool matters more than the interface paradigm.
The trust question: what makes a loan officer accept output from a tool
Every lender we spoke with had tried at least one technology product that promised to reduce manual work in origination. The experience with previous tools shaped how they approached our conversations. They were not hostile, but they were cautious about specifics. What we heard consistently was: show me the source.
When Maestro extracts an income figure, the report cites the specific document it came from, the page number, and the field label. A loan officer reviewing that output can look at the extraction and verify it against the original document in under a minute. That citation practice is not a feature we added reluctantly as a compliance measure. It is what loan officers specifically asked for. "I need to be able to check your work" was a recurring sentiment in these conversations.
This is also the right design from a regulatory standpoint. ECOA requires lenders to make credit decisions based on sound, verifiable analysis. A lender who relies on extracted data to inform an underwriting decision needs to be able to trace that data back to its source document. Our extraction architecture is built around that requirement because the people we spoke with told us it mattered to them, not only because it matters legally.
The integration friction problem
One consistent piece of feedback we heard across lender conversations was about integration cost. Every lending team is working inside an existing LOS, whether that is Encompass, Calyx Point, or a regional bank's proprietary system. New tooling that requires a team to work outside their LOS for any extended period adds friction and increases the chance of transcription errors at the boundary between systems.
The feedback we took from this is that Maestro's output needs to be consumable in the ways that already exist in lender workflows: a structured report they can print or attach to a file, an API response that an integration layer can write into their LOS, a data export they can load into their own processing. We are not trying to be the system of record. We are trying to be a reliable source of structured data that feeds into whatever system the lender already trusts.
For smaller brokerages that do not have an enterprise LOS, the PDF report output is often sufficient. For regional banks with dedicated operations teams, the API matters more. Building both paths was not our original plan. It became the plan after we understood how different the operational context is across the lender types we were talking to.
Why the list is shorter than vendors assume
Mortgage technology vendors often pitch a long list of capabilities because that is how enterprise software is sold. More features imply more value. The practitioners we spoke with had the opposite preference. They wanted fewer things, done reliably. One processor put it plainly: "I do not need it to do more. I need it to not be wrong."
That framing stuck with us. The value of document extraction in origination is not in the ceiling of what it can attempt. It is in the floor of reliability on the things it does. A system that correctly extracts income from 94 out of every 100 W-2s but handles edge cases unpredictably is not useful in production. A system that correctly extracts income from the vast majority, flags the remaining cases clearly, and gives the processor a clean path to handle the exceptions manually is operationally useful.
The willingness to be bounded, to say clearly what the system is and is not good at, was the part of our approach that seemed to resonate most with the people we talked to. They had seen a lot of overpromising. They were more interested in a tool that knew its limits than one that claimed not to have any.
Building from that feedback is where Maestro started. The conversations shaped not just what we built but how we describe it. Practitioners at lenders do not need another AI story. They need a specific tool that works on real files, tells them what it found, and is honest about where it needs human review. That is the product we are building.