Law Firm Agent Deployment: Assessment-First Methodology
May 1, 2026
Every conversation about AI agents in law firms eventually comes to the same question: “That’s interesting, but can you actually build it?” The answer is yes — but only if you do the work before you write the first line of code or configure the first workflow.
This post is about that work. It is about the methodology we apply before building any agent for a legal practice, illustrated through a use case that one Florida real estate and foreclosure practice described to us as their biggest operational headache.
The use case is reinstatement and payoff calculation letters — the documents that tell a borrower exactly what they owe to cure a default, to the penny, with a specific good-through date. It is one of the most time-consuming, error-prone, and liability-laden documents in a high-volume foreclosure practice. And it is a problem that an agent, built correctly on a secure foundation, can dramatically improve.
We have not built this specific agent yet. What we have done is the methodology — the assessment thinking, the architecture design, the security framework — that would make building it responsibly possible. We are sharing it here because it illustrates the assessment-first approach that applies to any agent use case in a legal environment.
The Problem — What a Foreclosure Practice Actually Deals With
A foreclosure practice working on behalf of servicers — the entities that manage mortgage loans on behalf of investors like Fannie Mae and Freddie Mac — handles a high volume of individual matters simultaneously. Each matter moves through a defined legal process with court deadlines, statutory timeframes, and regulatory requirements that vary by state.
The reinstatement and payoff calculation is a document produced at a specific point in that process. When a borrower seeks to cure their default — either by catching up on missed payments (reinstatement) or paying off the loan in full (payoff) — the law firm must produce a precise calculation of what is owed. That calculation must include missed principal and interest payments, accrued late fees, attorney fees incurred to date, property inspection costs, escrow shortfalls, and corporate advances made by the servicer.
Every line item must be accurate, documented, and legally defensible. Federal law requires servicers to provide payoff statements within seven business days of request. Incorrect calculations create liability — courts have found that borrowers who receive inaccurate reinstatement figures and miss their cure window have cognizable claims. The stakes on every calculation are real.
Here is the operational problem the Florida practice described. They receive loan data from multiple servicers, and every servicer sends that data differently.
One major servicer sends a structured spreadsheet with standardized column headers. Another sends a PDF export from their proprietary loan management system, with data laid out in a format that has changed twice in the past three years. A third sends a combination of a transaction history report in one file and a fee schedule in another, neither of which cross-references the other. A fourth occasionally emails a formatted summary alongside scanned copies of paper records.
A paralegal responsible for producing reinstatement calculations must receive whichever format the servicer sends, manually read the data, identify the relevant line items, map them to the firm’s calculation template, verify the math, flag any charges that appear legally questionable — anticipated fees not yet incurred, late fees charged beyond the point when acceleration occurred — and produce the output letter for attorney review and signature.
For a firm handling 200 active matters, this process consumes significant paralegal time per week. For a firm handling 500 matters, it is a material operational constraint. And every calculation is a liability exposure until an attorney signs off.
The Assessment First — What We Would Need to Understand Before Building
Before configuring a single workflow or writing a single prompt, an assessment of this environment would need to answer eight specific questions.
1. Where does the servicer data actually live?
Servicers send data through email, through secure portals, through shared folder connections, and occasionally through direct system integrations. Before building an agent that processes this data, we need to map every intake channel and understand how data moves from the servicer into the firm’s environment.
2. What permissions govern that data?
Once servicer data enters the firm’s environment — sitting in an email attachment, in a SharePoint folder, or in a case management system — who can access it? Are permissions set at the matter level, or does broader firm access apply? An agent processing this data will inherit those permissions. If the permissions are broader than appropriate, the agent’s access is broader than appropriate.
3. What sensitive data is in scope?
Servicer loan files contain borrower personally identifiable information — names, addresses, social security numbers, financial account details. This data is subject to regulatory protection under CFPB rules and state privacy laws. The agent’s handling of this data must comply with those requirements. The assessment would document what PII is in scope and how current controls govern it.
4. What is the current audit trail?
If a calculation error is challenged — and they are, because inaccurate reinstatement figures create documented legal exposure — can the firm reconstruct how the calculation was produced and who reviewed it? Before building an agent into this process, the audit trail requirement for the output must be defined, and the assessment must confirm that the firm’s current environment can support it.
5. What tools does the firm already have?
Most law firms using Microsoft 365 have Power Automate and Copilot licenses that are either underutilized or unused. Building on existing licensed tools dramatically reduces cost, integration complexity, and the security surface area introduced by a new vendor. The assessment maps what is already in the environment before recommending anything new.
6. What does the attorney sign-off process look like today?
The agent’s role in this workflow is to assist, not to decide. The output goes to an attorney who reviews and certifies it before it goes to the client or opposing party. The assessment needs to understand the current review process so the agent is built to support it rather than bypass it.
7. Where are the highest-risk error points in the current manual process?
Not all parts of the calculation carry equal risk. Identifying the line items where human error is most likely — often the attorney fee calculations, where the firm’s own records must reconcile with the servicer’s fee records — tells us where the agent’s verification logic should be most rigorous.
8. What does a correct output actually look like?
Before building an agent that produces reinstatement letters, we need a documented standard: what goes into the letter, in what order, in what format, for each servicer type. The standardization work is not a byproduct of building the agent — it is a prerequisite.
"The standardization work is not a byproduct of building the agent. It is a prerequisite. If you cannot define what a correct output looks like, you cannot build a system that produces it reliably."
The Build — What the Architecture Would Look Like
With the assessment complete, the architecture for this agent has clear parameters: the data sources are defined, the permissions are understood and scoped, the PII handling requirements are documented, the audit trail requirements are specified, and the output standard is written down.
The build has four components.
1. Document intake and parsing.
The agent needs to handle three data formats: structured spreadsheets, PDF exports with varying layouts, and combination packages. Microsoft Azure Document Intelligence — which is available through Azure and integrates natively with Microsoft 365 — handles PDF parsing with high accuracy for structured documents like loan statements. Power Automate connects the document parsing to the firm’s intake workflow, routing each servicer’s data through the appropriate parsing model based on the identified source.
2. Data normalization.
Once parsed, the data from different servicer formats must be mapped to a standardized internal schema. Principal balance maps to the same field regardless of whether the source called it “outstanding principal,” “unpaid principal balance,” or “remaining loan amount.” This mapping layer is where the intelligence lives — and it is the layer that requires the most careful testing against real servicer data samples.
3. Calculation and verification.
With normalized data in a standard schema, the calculation follows a defined template: each line item computed according to the legal rules that govern what can and cannot be included in a reinstatement or payoff figure. The agent flags any line item that appears outside those rules — anticipated fees, late fees charged past acceleration, duplicate charges — and presents them for attorney review rather than including them automatically.
4. Output and attorney workflow.
The calculated output generates a draft letter in the firm’s standard template. The draft goes into the attorney review queue in the firm’s case management system with the supporting calculation visible alongside it. The attorney reviews, edits if needed, and certifies. The certification and the audit trail — what data the agent used, what it calculated, what it flagged — are stored in the matter file.
This architecture is built on tools most Microsoft 365 law firms already have: Copilot, Power Automate, Azure Document Intelligence, and SharePoint. No new vendors. No new integration surface area. No new data leaving the firm’s Microsoft 365 tenant.
You probably have a use case like this. Tell us what you want to automate and we will tell you what we would assess first.
Why Assessment First Is Faster, Not Slower
The argument against assessment-first is always speed. “We want to build something now. Assessment adds time before we get to the actual work.”
This argument misunderstands where the time goes in an agent build that goes wrong.
The rework cost for an agent built without proper assessment is substantial. You discover mid-build that the permissions are broader than the attorney knew, so you stop to redesign the access model. You discover that the PDF parser fails on one servicer’s format that the assessment would have identified. You discover that the output format the attorneys assumed was standard is actually inconsistent across the firm’s paralegals, which means the agent cannot produce a consistent output until you standardize the template — work that you now have to do mid-build rather than pre-build.
An assessment takes roughly ten hours of structured review time. It eliminates the false starts, the mid-build redesigns, and the post-deployment corrections that consume far more than ten hours in total.
More importantly, it eliminates the liability exposure. A reinstatement letter produced by an agent running on incorrectly scoped permissions, without a proper audit trail, on data the firm does not fully understand is not faster than one produced manually. It is faster and riskier — and in a legal context, that risk lives with the attorney who signed the output.
The assessment is not the overhead before the work. The assessment is part of the work — the part that makes the rest of it reliable.
The methodology is the same regardless of the use case. Contract review. Client intake. Due diligence document processing. Regulatory submission management. For any agent deployment in a legal practice, the starting point is the same: understand the data, understand the permissions, understand what a correct output looks like, and build on a foundation that an attorney can trust enough to sign off on.
If you have a use case in mind — foreclosure calculations, contract review, another part of your practice that is consuming paralegal time on repetitive work — the 30-minute conversation is about that use case specifically. What you want to automate, what the assessment would need to cover, and what a realistic build looks like for your environment.
No pitch. No generic demo. Just a direct conversation about your specific problem and what solving it responsibly would require.
Tell us your use case. We will tell you exactly what we would assess before building it — and whether the build makes sense.
Recent Posts
Have Any Question?
Call or email Cocha. We can help with your cybersecurity needs!
- (281) 607-0616
- info@cochatechnology.com
About the Author:
Steve Combs
Co-Founder & Managing Director, Cocha Technology
Steven is a fractional CIO/CISO with 30+ years of enterprise IT and security leadership. He has built AI governance frameworks for organizations with 1,700+ users, led enterprise Microsoft Copilot deployments, and conducted security assessments across law firms, energy companies, financial institutions, and PE-backed manufacturers.