Teaching software to read 40 hours of legal documents a week.

The problem

Every commercial dispute the firm takes on arrives with a mountain of discovery: contracts, invoices, email exports, deposition transcripts, corporate filings. Before any attorney can build an argument, someone has to answer basic questions about each document — what is it, who are the parties, what dates and amounts matter, which case issues does it touch.

That someone was a team of four paralegals spending a combined ~40 hours per week on first-pass review. At roughly 3 minutes per document, a single 5,000-document production took most of a month to triage. Two things made it worse:

• Deadlines don't negotiate. Discovery responses are court-scheduled. When productions arrived late (they always do), the firm paid overtime or outsourced review at $45–60/hour.
• Fatigue errors compound. A misclassified document doesn't just waste time — a missed date or party name can surface mid-deposition. The firm had two near-misses in the year before they called us.

The brief came down to one sentence: get the firm's best people off work a careful intern could do — without accepting an intern's error rate.

The approach

The instinct with projects like this is to build one giant “do everything” prompt. We didn't, for a simple reason: you can't measure — or fix — a monolith. Instead we decomposed first-pass review into four narrow jobs and gave each to a specialized agent:

1. Classifier — assigns each document one of 14 types the firm's workflow already used (contract, invoice, correspondence, filing…). Narrow job, near-perfect accuracy.
2. Extractor — pulls typed fields per document class: parties, effective dates, amounts, governing law, signature blocks. Every field carries a confidence score.
3. Cross-checker — validates extractions against each other and against the case record. If an invoice references a contract number, does that contract exist in the production? Dates in impossible orders get flagged.
4. Summarizer — writes the two-sentence summary and issue tags that populate the review interface, so attorneys scan instead of open.

The exception queue is the real product

The single most important design decision wasn't a model choice. It was accepting that the system would be wrong sometimes and building for it. Any document where classification confidence, a required field, or a cross-check fell below threshold went to a human review queue — a purpose-built UI where a paralegal confirms or corrects in seconds, with the suspect field highlighted in the source document.

Two effects. First, the paralegals stopped being replaced and started being editors — which is why adoption took days, not months. Second, every correction became labeled training data: the thresholds and few-shot examples were tuned from real corrections during the pilot, which is how accuracy climbed from 89% at week four to 96.4% at handoff.

Stack notes

Pipeline in TypeScript on a private VPC; queue-based orchestration so a 5,000-document production just means a longer queue, not a different system. PostgreSQL with pgvector for the case record and similarity lookups. Model calls through a gateway with zero-retention agreements; classification runs on a small fast model, extraction and cross-checking on a frontier model — that split alone cut inference cost ~70% versus running everything on the large model.

The rollout

We shipped in phases, each one earning the next. The firm saw working software at the end of every week — our standard practice, but it mattered more than usual here because trust was the whole game.

The results

Measured over the first 90 days in production, against the firm's own baseline from the prior year:

The number the firm cares about most isn't in the table: the four paralegals now spend their week on privilege review and deposition preparation — higher-value work the firm previously turned away for capacity reasons.