Building AI for Lawyers - Jacob Lauritzen, CTO of Legora

What it claims

Jacob Lauritzen, CTO of Legora, argues that a legal agent is mostly built from evals that can run without customer data, model routing, and a few composable primitives. Legora passed $100 million ARR in April 2026, less than 18 months after launch, and has more than 1,800 customers. In October 2026 it raised $550 million at an $8.8 billion valuation, with ARR above $200 million. Lauritzen estimates current models handle about 60% of legal work well. For that work the remaining problem is cost and latency. Complex analysis and editing across million-token contracts still need smarter models.

How it works

Evals without traces. One team of three engineers and three lawyers builds RL-style "worlds". One example is a 10,000-file data room in which the agent runs due diligence, and the output is graded on the red flags it should catch. Grading is split into finding red flags and drafting the report, so each part can be scored separately. Results go on a heat map by practice area and task. Lauritzen says model releases often improve some cells and regress others. In production, Legora runs cheap LLM-based online checks and compares feature-flag cohorts to catch regressions. It also classifies failures into 10 to 20 known failure modes, plus task types and practice areas. Paraphrasing real traces was considered, but Legora picks the safest end of that range. The show notes link a write-up on running 2,000 parallel agent evals on Modal Sandboxes.

Tabular Review. Each row is a document and each column is a question. It scales to about a million cells and is built on AG Grid. It runs the first 10 rows first so users can fix prompts before the full run. The agent can start a Tabular Review itself from a bulk upload, wait for it to finish, flag anomalies and draft a memo. Every output cites its source document.

Lists and agents. Lists are a Notion-style database with triggers and automations, which Lauritzen compares to Linear for coding agents. Intake is a Slack bot that files requests as tickets on a list.

flowchart LR
  S[Slack intake] --> A[Agent]
  A -->|creates / reads| L[List]
  L -->|change triggers| A
  L --> H[Lawyer reviews]
  H -->|marked done| S

Model and vendor choices. Primary model selection was eventually exposed as a picker. Tools such as Tabular Review use their own routed models. Sub-agent delegation for fan-out retrieval became reliable over about nine months, starting from the Sonnet 4.6 and Opus 4.6 era. For transcription, Legora uses an early Gemini model and Microsoft's MAI-Transcribe. It does not use ElevenLabs, to keep the vendor list in its data processing agreement short. Lauritzen's transcription workflow has three steps: transcribe, have an LLM extract domain keywords, then transcribe again with those keywords. Legora hosts only on Azure because early law-firm clients already approved Microsoft through 365 and rejected AWS and GCP.

Evidence

The only quantitative result is anecdotal. Citation correctness rose from about 70% to about 99% with a new model release and no change on Legora's side. Lauritzen uses this to explain why Legora delayed building heavy evals: harness work paid off more while models kept improving. Product metrics such as DAU/MAU and hours per month are described as "extremely high" without figures.

Limits

This is an interview, not a technical write-up. No eval set, benchmark score or architecture is published. The fetched text covers the transcript only to about minute 39. Later segments are known only from the episode notes and timestamps: post-training open-weight models for legal research, late-interaction retrieval, MapReduce versus one large context window, why Lauritzen advises against default embeddings, and the claim that drafts from Fable and Opus are more verbose than drafts from Astra. Revenue and valuation figures come from the company.