Single AI Agent vs Multi-Agent Teams for Law Firms
What “agent team” actually means when a vendor says it
The vocabulary is moving fast, so here’s the plain version. A single agent is one AI assistant that can take multiple steps and use tools — read a file, query your practice management system, write a draft, save it back. A multi-agent system splits that work across several specialized agents that pass results to each other: a “retrieval” agent pulls documents, an “analysis” agent extracts the key terms, a “drafting” agent writes, a “reviewer” agent critiques the draft.
This is a real product trend, not just a conference talking point. Contract-lifecycle vendors such as Agiloft have shipped named, multi-step contract agents rather than generic “AI features,” and several practice-management and research platforms are moving the same direction. Before you rely on any specific capability, read the vendor’s own product documentation and release notes — marketing pages and trade-press summaries drift quickly, and the configuration details that matter for supervision are rarely in either.
Where the handoffs break
The honest failure mode of multi-agent systems is error laundering. Agent A produces a summary that’s mostly right, with one bad date buried in it. Agent B receives that summary as input and treats it as ground truth — it has no access to the underlying deposition transcript, only A’s paraphrase. Agent C polishes B’s output into confident, well-formatted prose. By the time a human reads it, the original uncertainty has been written out of the document. Nobody flagged it, because each agent did its job competently on the input it was given.
The second failure mode is cost and latency sprawl — more agents means more model calls, longer runs, and more places a run can stall halfway through, leaving you unsure what was and wasn’t written back to your DMS.
The third is supervision. Under the ABA’s Model Rule 1.1 Comment 8 on technology competence, and ABA Formal Opinion 512 on generative AI tools (July 2024), the duties of competence, confidentiality and supervision don’t thin out because the work passed through more automated hands. Verify your own state bar’s position — ethics opinions on generative AI vary meaningfully by jurisdiction, and some are more specific than the ABA’s. Operationally, the practical test is simple: if you can’t explain to a judge or a client which step produced a wrong sentence, your architecture is too opaque.
Every handoff between agents is a place where “probably” quietly becomes “is.”
One agent with skills, or several agents with roles
What it is: one assistant (Claude, or whatever you’ve standardized on) connected to your systems, running a packaged skill that defines how a job gets done the same way every time.
Strengths: one context, one audit trail, one place to fix a bad instruction. Cheaper per run. Easy to spot-check — you can read the full transcript.
Limits: very long jobs exceed what one run holds, and the failure is quiet rather than loud. Hand one agent a 400-document production and it will compress early documents into increasingly lossy summaries to keep going — the output still looks coherent, but detail from the first hundred files is simply gone, with no error to catch.
Best for: drafting, summarizing, abstracting, review of a bounded set — the bulk of small-firm work.
What it is: separate agents with distinct roles, orchestrated by code or a workflow tool, passing structured output between them.
Strengths: handles volume and genuinely different sub-jobs. Each agent can have narrower permissions. Failures isolate to one stage.
Limits: more surface area, more cost, harder to debug, and more vendors touching client files. Errors compound silently unless each handoff is logged and inspectable.
Best for: high-volume pipelines — mass intake, large document populations, nightly batch work.
A useful middle path that gets overlooked: deterministic orchestration with agentic steps. Use ordinary workflow plumbing — n8n, Make, or custom code — to move items through the pipeline, and call an AI agent only at the steps that actually require judgment. The routing, retries, and record-keeping stay boring and inspectable. If you’re weighing the platforms that do this, our comparison of Copilot Studio, n8n, and the Claude Agent SDK for law firms covers the trade-offs.
A worked example: the demand package pipeline
Take a PI firm assembling a demand package. The naive multi-agent design is four agents chatting. The design we’d argue for:
-
Deterministic intake of the file
Code — not an agent — lists every PDF in the matter, OCRs what needs it, and records page counts. No judgment required, so no model required. -
Agent step 1: per-document extraction
One agent, one skill, run once per document: pull provider, date of service, diagnosis, billed amount, and the page cite for each. Output is structured, with a confidence flag and a page number on every field. -
Human checkpoint on exceptions only
A paralegal reviews only the low-confidence rows and anything with no page cite. Everything else flows through. -
Agent step 2: chronology and draft
A second run — same agent, different skill — builds the chronology from the verified structured data, not from another agent’s prose. Source citations carry through. -
Attorney sign-off
The lawyer reviews the draft against the cited pages. This step does not get automated, ever.
Notice what makes it work: the agents never pass each other free text. They pass structured data with page cites, and a human sees the exceptions. That’s the same discipline that makes agentic discovery triage survive contact with a real case.
What firms are actually running right now
The honest answer to what small firms are actually running, as of early 2026, breaks into four layers: (1) general assistants — ChatGPT, Claude, Copilot, Gemini — used for drafting and first-pass summarizing; (2) AI features inside tools you already pay for, like practice-management assistants and research platforms; (3) point solutions aimed at one job, such as contract review or deposition summarizing; and (4) a smaller but growing group building custom agents wired into their own systems. That last group often uses MCP, an open protocol originated at Anthropic for giving an assistant governed access to firm data and tools — though direct API integrations or a vendor’s own native connectors are perfectly viable alternatives, and frequently the faster route if your DMS already ships one.
What firms are actually using it for, day to day, is less exotic than the marketing: summarizing records, first-draft correspondence, document review triage, intake qualification, and turning piles of PDFs into structured data. Multi-agent orchestration sits mostly in layer four and in vendor roadmaps — not in the average small firm’s daily routine.
Picking the few workflows worth automating
The Pareto heuristic lawyers quote — that a small share of inputs drives most of the output — is a decent planning lens here, and we’d state it as opinion, not measurement: a handful of repeated workflows probably consume most of your firm’s non-billable administrative time. Agent-ify those. The one-off, bespoke matter is where your judgment earns the fee; don’t spend six weeks of build time on it.
How to model whether it pays back, using your own figures:
- Start with one workflow — the single one you run most often — not a portfolio.
- Estimate hours spent on it per month, multiply by the loaded cost of whoever does it, then haircut by the share an agent realistically removes. Review time is real and does not go to zero.
- Compare that against build or licence cost plus the ongoing time your team spends supervising and spot-checking.
- Treat every output that leaves the firm as requiring a named human reviewer — budget that time rather than assuming it away.
Industry-wide savings figures and lawyer-income benchmarks tell you nothing about whether this specific workflow pays back at your firm. Run the arithmetic on your own numbers.
So which do you build?
Start single. One agent, one skill, one workflow, read-mostly access, human sign-off. Run it for a month and read the transcripts. You’ll learn more from that than from any architecture diagram.
Split into multiple agents only when you hit a specific wall: the job genuinely exceeds one run’s context, or the sub-tasks need different permissions, or volume demands parallelism. When you do split, make the handoff a structured artifact you can open and read — a table, a JSON record, a cited extract — never a paragraph of prose from another model. And decide up front which of the three oversight models applies to each stage.
And be willing to conclude that no agent is the answer. Plenty of the work firms try to agent-ify is deterministic: if a document type is X, file it in folder Y. A rule, a template, or a decent off-the-shelf product will do that more reliably and cheaper than any agent, single or multi.
Where is your firm losing billable hours?
Get a free automation audit: we map your intake-to-invoice workflow and show you exactly what's worth automating — before you spend a dollar.
Get a free automation audit