# You Staffed a Desk, Not a Tool: What Happens to the Underwriter When the Agent Does the File

*October 15, 2026 · 5 min read · Pranay Shetty*

> The hard part of a mortgage AI deployment is not the model. It is the org chart. When an agent clears most of the routine work, the processor and underwriter roles change shape, the exception queue becomes the real job, and someone has to own the confidence floor as a policy decision. What we have seen change on the floor, and why the oversight role is a control an examiner expects to see named.

## The Question That Comes After the Demo

The demo lands. The agent reads the file, clears the conditions, calculates the income, and the operations leader in the room sees the cycle time fall. Then comes the question that decides whether the deployment works: what happens to my team? It is the right question, and the answer most vendors give, that nobody loses a job and everyone just gets more productive, is both unconvincing and not quite true. The work changes shape. Pretending it does not is how a deployment stalls three months in, when the people who were supposed to oversee the agent either do not trust it or trust it too much, and either failure is worse than the queue they started with.

I spend most of my time with heads of mortgage operations and chief compliance officers, and the pattern is consistent: the technology is the easy half. The org design is the half that decides the outcome, and almost nobody plans for it before go-live. The floor you have was built around queues of work that a human picks up, processes, and puts down. When an agent holds the goal and works the file continuously, the queues change from "work waiting to be done" to "exceptions waiting for a decision," and a person who was good at the first job is not automatically set up for the second.

## The Processor and the Underwriter Do Not Disappear. They Move Up.

The clearest change is at the processor level. A processor's day was built around moving a file forward: requesting the document, noticing it arrived, checking it, updating the system, chasing the next one. The agent does the moving. What is left for the processor is the part that was always underneath the busywork, the judgment about files that do not fit the pattern, and the relationship work with borrowers and loan officers that a file in trouble needs. The processors who thrive after a deployment are the ones who were already good at the judgment and were spending most of their day on the clerical layer on top of it. The deployment gives them their actual skill back.

The underwriter's change is subtler and more important. The underwriter does not stop underwriting. The underwriter stops re-deriving the routine file and starts spending their attention on the files the agent escalated, which are, by design, the hard ones. This is a better use of an underwriter and also a more demanding one, because the easy files that used to break up the day are gone. The day is now a sequence of the files that needed a person, each one arriving with the agent's work already done and the open question named. That is a more intense job than the old one, and staffing it as if it were the same job, same ratios, same expectations, is a mistake. The right ratio of underwriters to volume changes, and so does the profile of the underwriter you hire.

There is a trap on the underwriter side that I flag in every deployment conversation, because it is the one that quietly breaks the control. When an agent is right most of the time, the human reviewing its work drifts toward rubber-stamping. The override rate falls, not because the agent got better, but because the reviewer stopped actually reviewing. A human-in-the-loop control that has become a human-shaped formality is not a control at all, and it will not survive an exam. So the oversight role has to be designed to stay awake: review load that leaves time to actually look, sampling that checks the agent's cleared work and not just its escalations, and a culture that treats catching the agent's error as the job rather than a failure to move fast.

## Somebody Has to Own the Confidence Floor

The single most important org-design decision in a mortgage AI deployment is who owns the confidence floor. The floor is the threshold below which the agent stops and escalates instead of acting, and it is not a technical setting. It is a policy decision about how much risk the institution will let the machine carry on each kind of work, and it belongs to a named person with the authority to set risk policy, not to whoever configured the system.

The floor is where throughput and safety trade against each other directly. Lower it and the agent clears more work alone, which looks like a win on the dashboard and means more of the agent's own uncertainty is reaching the loan unreviewed. Raise it and the agent escalates more, which costs reviewer time and protects the file. That trade is a business-and-risk decision, so it has to sit with someone accountable for both, usually the head of operations and the chief compliance officer together, reviewed on a schedule, with the setting documented and the reasoning recorded. A floor that drifts down because someone wanted the automation rate to look better, with no one accountable for the change, is the governance failure that a confident error eventually makes visible.

## Why the Regulator Cares About Your Org Chart

This is not only an efficiency question. The oversight structure is a control, and it is one supervisors expect to see designed on purpose. [SR 11-7](https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm), the interagency model-risk guidance, is explicit that effective model risk management depends on a governance structure with clear roles, and on what it calls effective challenge: critical review by people with the authority, the competence, and the incentive to question a model's output. An underwriter rubber-stamping an agent is the absence of effective challenge, stated in the guidance's own terms. When an examiner asks how your institution governs the AI agent, the answer is not the model documentation. It is the org chart: who reviews what, who owns the floor, who has the standing to tell the agent no and the incentive to use it.

The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) puts the same point in its Govern function, which asks an organization to define accountability structures so that the people responsible for an AI system's risks are named and given authority before the system is in production, not after an incident. Both frameworks are telling you the same thing: the human oversight of the agent is part of the system, not a courtesy around it, and it has to be designed, staffed, and documented like any other control. A deployment that ships the model and leaves the oversight to sort itself out has shipped half a control and called it done.

## What We Actually Do Before Go-Live

The org work starts before the agent touches a live file. In the deployments we run, we map the current roles against the work the agent will take and the work that will remain, and we name the oversight roles explicitly: who owns each exception type, who owns the floor, who runs the sampling over the agent's cleared work. We do not present this as headcount reduction, because framing it that way guarantees the team will root for the deployment to fail. We present it as the same people doing the part of their job they were trained for, with the clerical layer removed and a new oversight responsibility added, and we are honest that the oversight responsibility is real work that has to be staffed.

We also stage the trust. The floor starts high, so the agent escalates generously and the team sees it ask for help on the files a human would also have stopped on. As the monitoring shows where the agent is reliable, the floor comes down on specific task types, by decision of the people who own it, with the change recorded. Trust earned this way holds under an exam, because every loosening is a documented decision with evidence behind it rather than a dial someone turned to make a number look better.

The honest version of the answer to "what happens to my team" is that the team gets smaller at the clerical layer and more skilled at the judgment layer, the underwriter's day gets harder and more valuable, and a new oversight function has to be built and staffed on purpose. At Sei we treat that oversight function as part of what we deliver rather than something the customer figures out after we leave, because the agent and the people who govern it are one system, and the control an examiner looks for is the one the org chart describes. Staff a desk, not a tool, and plan the desk before the agent sits down at it.

---

_Source: [https://seiright.com/blog/mortgage-ai-org-design-underwriter-role-exception-oversight-sr-11-7](https://seiright.com/blog/mortgage-ai-org-design-underwriter-role-exception-oversight-sr-11-7) · Sei AI_