AI for Law Firms in 2026: What Works, What It Costs, and Why Pilots Stall

The short answer: three workflows produce nearly all the return - intake triage, document review and summarisation, and first-draft correspondence. Each already has a human checkpoint, which is what makes them deployable. The wall firms hit is economic and structural, not technical. A 10-person firm on Clio Essentials pays roughly $9,480 a year before any AI tool, the client portal only exists above the $79 per user tier, and every automation the firm builds outside that platform has no way to keep one client's matter separate from another's.

This is a longer piece than most. If you want the costs, skip to what a firm actually pays. If you want the architecture, skip to why pilots stall.

The three workflows that return hours

Intake triage

A firm handling inbound calls, web forms and referrals applies the same filter every day: is this in our practice area, within the statute, against a solvent defendant, with a plausible recovery, and is the client someone we want? Most of that judgment runs against information the prospect already gave you.

What to automate: an agent reads the intake record, checks it against your written criteria, and routes it into take, decline, or needs more information. It drafts the decline letter for the ones you are not taking and the engagement letter for the ones you are.

Why the value is speed, not sorting. Response time is the variable that moves signed-case rates. A firm replying within the hour signs materially more of the cases it wants than a firm replying next day, because personal injury and family law prospects are calling several firms in one sitting. The sorting was never the bottleneck. The queue was.

Why it is safe: every routed matter is reviewed before anyone commits. The agent moves the queue; the attorney decides. Realistically, 60 to 80 percent of intakes route cleanly and the remainder are genuinely ambiguous and land in a human queue, which is the correct outcome.

Document review and summarisation

Medical records, discovery productions, deposition transcripts, contract sets. This is the largest consumer of associate and paralegal hours in most practices.

• Summarisation with page-level citation back to the source
• Timeline construction from dated records
• Flagging documents matching criteria you define
• Deduplication across productions

What does not work reliably: any task where a miss is invisible. If the agent fails to surface a critical record and nobody knows to look for it, you do not find out until it matters. That is the difference between narrowing what a human reads and replacing the reading, and it is the line firms cross without noticing.

The verification pattern that works: require the agent to cite the source page for every assertion, then spot-check ten percent against the original. If the citation is wrong, the summary is wrong, and you find out in minutes rather than at deposition.

First-draft correspondence and routine documents

Demand letters, status updates, client emails, standard motions, discovery responses. The firm has written a version of each hundreds of times. An agent working from your prior work product and the matter file produces a draft that is 70 to 85 percent there, and the attorney's time goes into the part that requires judgment. On a demand letter that took ninety minutes, you are now spending twenty.

Nothing leaves the firm without a signature, so the risk is contained. The trap is that your prior work product has to be accessible to the agent, per matter, without exposing every other client's file. That constraint is the whole subject of the architecture section.

What a firm actually pays

Most articles about AI for law firms never mention what the underlying stack costs. Here is the real arithmetic, because it explains why firms stall.

Note where the client portal sits. It appears at Essentials, not EasyStart. That single line item is why so many small firms have no portal: the tier that includes it costs roughly double. For a 10-user firm, annual license cost runs from about $4,680 on EasyStart to $15,480 on Complete, and monthly billing adds roughly twenty percent. Butterbase is listed as a build / fork alternative for firms that want a custom intake or client portal without Clio's per-user tier structure.

The costs that do not appear on the pricing page matter more:

• Payment processing: 2.95 percent plus $0.20 per card transaction. On $2M of collections, about $59,000 a year.
• Clio Grow add-on: $59 per user per month plus a $399 one-time setup fee.
• QuickBooks integration: around $30 per month.
• Implementation: $10,000 to $25,000 for mid-sized firms, per industry analyst benchmarks.
• Supplemental support: $2,000 or more per year for firms needing help beyond standard support.
• Setup time: roughly two weeks of work before full rollout, not instant productivity.

A 10-person firm on Essentials is spending roughly $9,480 a year on licenses, plus processing, plus amortised implementation, before a single AI tool. So when that firm evaluates an AI product at $99 per user per month, it is not comparing it to zero. It is comparing it to a stack it already resents, and the honest question being asked is what does this replace, not what does this add.

The practical implication: the first AI project should reduce a cost or a headcount need, not add a line item. Intake triage that lets a firm handle forty percent more inbound with the same staff is a much easier internal sell than a tool that makes drafting slightly nicer.

Why AI pilots stall at law firms

Not because the model is not good enough. Because of a structural gap that appears the moment a pilot tries to become a system.

A firm builds something useful - an intake agent, a document summariser - usually with Zapier or Make wired to Airtable or a spreadsheet. It works. Everyone is pleased. Then someone asks a reasonable question: can the client see this?

The answer is no. There is no way to give a client access to their own matter without giving them access to the table containing every other client's matter. Airtable has no true per-record user permissions at the confidence level this requires. Zapier moves data; it does not govern it. The automation works and it cannot leave the building.

The internal version of the same problem is just as awkward. A paralegal should see the matters they are staffed on. A contract attorney should see one case. A partner should see everything in their practice group. Opposing counsel, if you are sharing a document portal, should see exactly one production. Most firms handle this with folder permissions and trust, which is workable when humans open files and inadequate when an agent retrieves records, because the agent will retrieve whatever it can reach and the retrieval is invisible.

Firms often try to close the gap with system prompts: never reference information from other client matters. That is a filter, not a boundary. It shifts the distribution of outputs and works most of the time. Most of the time is not a standard you can state to a client, and any document an agent processes may itself contain instructions - an email in a discovery production, text in an uploaded PDF. A model has no reliable in-band way to distinguish instructions from data.

The test: for every rule in your system prompt, ask whether a violation would be embarrassing or disqualifying. Embarrassing rules can stay prompt-level. Disqualifying ones - cross-matter data, privilege, trust accounting - have to be architectural, enforced somewhere the agent cannot reach.

What the architecture needs to look like

Four requirements, none of them AI features.

Matter isolation enforced at the storage layer. Not application-code filtering, which is correct until the one query that forgets. The database itself refuses to return records outside the requesting user's scope.

ALTER TABLE matters ENABLE ROW LEVEL SECURITY;
ALTER TABLE matters FORCE ROW LEVEL SECURITY;

CREATE POLICY matter_read ON matters
  FOR SELECT
  USING (
    tenant_id = current_setting('app.tenant_id', true)::uuid
    AND (
      current_setting('app.role', true) = 'partner'
      OR id IN (
        SELECT matter_id FROM matter_staffing
        WHERE user_id = current_setting('app.user_id', true)::uuid
      )
    )
  );

The critical property: tenant and user context come from a verified session token, never from an argument the agent supplies. If a tool signature accepts a client_id parameter, isolation depends on the model behaving correctly, and prompt injection becomes matter traversal.

Role separation that matches how firms actually work. Partner, associate, paralegal, contract attorney, client, and sometimes opposing counsel. This is a data model decision, not a settings page. Firms that defer it end up rebuilding, because retrofitting permissions into a schema that assumed one access level means touching every query.

Audit records at run granularity. Not "the system logged it". For every agent action: which run, on whose behalf, in response to what request, touching which records, at what time. The test that matters is whether you can answer "what did the agent do on the Henderson matter on March 4th and why" without calling a developer. If not, the record will not survive a client asking, a bar complaint, or a malpractice carrier's questionnaire. Retrofitting this is worse than it sounds, because the pilot period generates no auditable history and you start the evidence clock at zero on the day you wanted to go live.

Client access that does not expose internal systems. A portal is a separate surface with its own permission model over the same records. Three separate systems that sync is the wrong architecture, because it recreates the reconciliation problem the firm was trying to escape.

A practical sequence

Pick the workflow that already has a checkpoint. Intake triage is usually right, because someone already reviews every intake. The agent slots into an existing control rather than requiring a new one. The highest-value workflow is rarely the correct first one.

Choose the pilot dataset adversarially. Ask whoever has been at the firm longest to pick the five messiest matters they can find. If the agent handles the worst cases at seventy percent, it will handle the median at ninety-five. The reverse is not true, and a demo built on clean matters tells you nothing about the tail, which is where client-facing risk lives.

Resolve your system of record before automating anything. If matter status lives in Clio and also in a spreadsheet, and they disagree, an agent will answer confidently from whichever it read. Write down, per field, which system is authoritative. This takes an afternoon and prevents the most common failure mode.

Instrument audit on day one. It feels premature during a pilot. It determines whether the pilot can ever go client-facing.

Write down what the agent does not do. Explicitly, as a list, shared with everyone who touches it. Across the firms we have watched reach production, this is the strongest single predictor - it converts an ambiguous tool into a bounded one, which is what lets people trust it enough to use and stay sceptical enough to catch failures.

Five diagnostic questions

1. Who chose the pilot matters, and what did they exclude? If the answer is "a representative sample", it is cleaner than production.
2. If the person running this took a month off, what would happen? Pilots staffed as side projects produce nothing transferable.
3. When two of our systems disagree about a matter, which one is right? If that takes more than a sentence, you have a data problem before you have an AI problem.
4. If a client asked us to explain an agent-produced document, what would we show them? Application logs are not an answer.
5. Which of our rules would end a client relationship if broken once? Those cannot live in a prompt.

A pilot with good answers to all five will probably ship. One that does not will stall on whichever question got the vaguest answer, and none of them improve by waiting for a better model.

Butterbase gives firms the layer underneath: matter isolation enforced in Postgres rather than application code, role separation modelled on how firms actually staff work, run-scoped audit records, and client portals that do not require exposing internal systems. Firms fork a production-ready intake or matter app and run it as their own, self-hosted where that is the requirement, with no per-user pricing on the portal. Related reading: Why AI Agent Pilots Stall at Service Firms and What Your Firm Actually Spends to Run on Five Tools.

Frequently asked questions