Building AI for Lawyers - Jacob Lauritzen, CTO of Legora

In this episode, we chat with Jacob Lauritzen, CTO of Legora, following the announcement of their $550M Series E at an $8.8B valuation a couple weeks ago. We talk about what it takes to build AI agents for lawyers and what other people building agents can learn from that work. Legora started in a Stockholm basement with a simple product: ChatGPT, Swedish law, and a search tool. Jacob had already been through YC with his own startup when he helped Max Junestrand with the application for Leya (now Legora). He later joined as head of engineering and is now CTO. Today the agent drafts and edits Word documents, reviews thousands of contracts at once, and coordinates work between lawyers, their clients, and other agents. The company passed $100 million in ARR in April, less than 18 months after launch, and now has more than 1,800 customers. It raised $550 million in March at a $5.55 billion valuation, then another $550 million in October at an $8.8 billion valuation. Its latest acquisition, Wexler, was its fifth just this year. We asked Jacob how you evaluate agents when you can't see your customers' data, which tasks still need better models, how legal engineers and forward deployed engineers split the work, and why the billable hour as a business model is being upended. Watch the full conversation on YouTube → Open video on YouTube ↗ What changed for the billable hour? When Jacob first read Leya's YC application, he had one piece of feedback: people had tried building legal tech a million times, and it never worked. If lawyers bill by the hour, getting faster means earning less. Why would they buy a tool that does that? What changed, he says, is the pressure on firms. In the US, routine work like small reviews is already shifting to flat project fees. Some firms do it for free to hold on to the client. The money moves to M&A, litigation, and time spent with clients. We asked whether that means firms will stop needing paralegals and junior lawyers. Jacob says that's not what Legora is seeing. A good junior is worth more today than two years ago because they get so much more done, just as in engineering. Jump to the billing model discussion → Evals without access to customer data Most teams improve their agents by reading traces. Legora can't read any. Almost everything users upload is confidential, and much of it belongs to the firm's clients, not the firm. So the evals team has to recreate the kinds of work customers do. Three engineers and three lawyers build RL environments to simulate the work their customers do. One example is a 10,000-file data room where the agent runs due diligence and has to produce a report that catches the right red flags. The team plots the results on a heat map by practice area and task. A new model often gets better at some kinds of legal work and worse at others. The team draws on a pool of about 100 legal engineers: lawyers who spent three or four years in big law, often with a CS degree. In production, Legora classifies failures into 10 to 20 known failure modes and runs cheap LLM-based checks behind feature flags. Those restrictions also determine which infrastructure Legora can use. Everything runs on Azure because when Legora started, law firms wouldn't accept AWS or GCP, and Microsoft was already an approved vendor through 365. Jump to evals without traces → Where smarter models still matter Legora resisted a model picker for a long time before giving in. Jacob's view is that a lawyer shouldn't have to decide whether a contract is a Sonnet-high or an Opus-mid task. It's Legora's job to find the best available tradeoff between quality, cost, latency, governance, and regional availability. He estimates that models already handle about 60% of legal work really well. For those tasks it's a cost and latency problem now. Complex analysis and editing across million-token contracts still need more intelligence. Legora has started post-training open-weight models for narrow tasks like legal research, with no plans to train its own frontier model. For drafting, Jacob finds Fable and Opus too verbose. Astra is more concise. To address hallucinations, everything the agent writes gets a citation that highlights a bounding box in the source PDF, multiple layers down. Jump to the model discussion → A few building blocks, many products Six months into the job, Jacob showed the team a slide of the 300 Spartans and declared that Legora would stay at 20 engineers forever. It now has 100, and he says that still feels too small. His job now is to build a system where the team can ship just a few things and customers feel like they're getting a lot. The team builds around a few primitives: projects that hold files, the agent, Tabular Review, and lists. Lists are a flexible Notion-style database with triggers and automations. Agents can create and read lists, and changes to a list can start an agent. Intake is a Slack bot that turns a request into a ticket on a list. Tabular Review is the one the industry copied, down to the name. Each row is a document, each column is a question. Drop in 10,000 employment contracts and ask for the termination period, the IP assignment clause, and the severance terms. It supports up to a million cells, but starts with just 10 rows so you can fix your prompts before running the rest. Legal engineers configure new products on these primitives without writing code. Even Wexler's fact intelligence product runs on the same building blocks. Jump to the primitives discussion → Legal engineers first, forward deployed engineers second Legora hired its first forward deployed engineer about nine months ago in New York: Di Qi, a two-time YC founder who worked on search at Meta. Legal engineers configure the product the way a power user would and don't write code. Forward deployed engineers write code into production, build integrations into a firm's CRM or document management system, and push what they learn back into the core product. They still don't touch client data. When a big, engaged client signs, Legora assigns legal engineers to work with them and adds an FDE if the project needs one. Within a year, Jacob expects to have a rotating group of FDEs who sit with a client for a couple of months, build what they need, and move on. Jump to the forward deployed discussion → Where this goes In two years, Jacob thinks big enterprises will use Legora through tools like Claude Cowork, while law firms work inside Legora directly. He doesn't expect the labs to cut Legora off the way they've done to coding companies. For a $400 million M&A deal, he thinks people will still want Legora. Jump to the predictions → Show notes Legora — the collaborative AI platform for lawyers, where Jacob is CTO. Jacob Lauritzen — Jacob on LinkedIn. Legora's Series E announcement — $550 million at an $8.8 billion valuation, with ARR above $200 million. "Agents need more than a chat" — Jacob's talk at AI Engineer Europe 2026. "Connect AI to Billions of Legal Documents" — Jacob's AI Engineer talk with Simon Eskildsen of turbopuffer. How Legora runs 2,000 parallel agent evals on Modal Sandboxes — the infrastructure behind Legora's eval runs. Legora acquires Qura — the Stockholm legal research startup Legora bought in April. Legora is acquiring Wexler — the London startup that extracts and verifies facts across large litigation document sets. Claude for Legal — Anthropic's legal connectors and plugins, the backdrop to whether the labs will come for legal. AIE Europe Debrief + Agent Labs Thesis — Swyx on the agent lab playbook he brings up at the start. Timestamps • 0:00 Cold open • 0:40 Meet Jacob Lauritzen, CTO of Legora • 1:05 Starting out as underdogs in a Stockholm basement • 1:54 How Legora grew from ChatGPT with Swedish law into a legal agent • 4:12 The switch from assistant to agent • 5:23 Which models Legora uses and why it added a model picker • 7:48 Are today’s models good enough for lawyers? • 8:20 What agents couldn’t do nine months ago • 9:18 Testing the agent in simulated worlds and a 10,000-file data room • 10:07 The evals team and Legora’s 100 legal engineers • 11:03 When evals didn’t seem worth it and one release took citations from 70% to 99% • 12:18 What legal practice could look like in five to ten years • 14:18 Will the law firm partnership model survive? • 16:40 What happens to paralegals and junior lawyers? • 18:00 The billable hour and why earlier legal tech fell short • 19:39 Where the money goes now • 22:44 How Legora used its own product for acquisition diligence • 23:59 How Swedish and American law firms differ • 26:12 Product metrics when you can’t read the traces • 27:41 Paraphrasing traces and narrowing failures down to 10 or 20 types • 28:42 Why data privacy led Legora to run everything on Azure • 30:04 Open-weight models and model arbitrage • 30:55 Transcription models and why Legora doesn’t use ElevenLabs • 33:33 The agent, Tabular Review, projects, and the Word add-in • 34:24 How a lawyer uses Tabular Review • 35:51 Why a spreadsheet works and what you learn from the first 10 rows • 37:53 How the legal intake bot works in Slack • 39:11 How agents create lists and lists start agents • 40:15 Building products on those same pieces and acquiring Wexler • 42:37 What forward-deployed engineers do at Legora • 43:52 How legal engineers and forward-deployed engineers onboard a big client • 46:43 What’s next for the forward-deployed team over the coming year • 47:24 Why Legora resisted building APIs • 49:26 Can the agent be the API? • 50:12 The 300 Spartans slide and the plan to stay at 20 engineers • 51:32 The bets nobody asked Legora to make • 53:05 Post-training open-weight models for legal research • 54:05 Search, retrieval, and late interaction • 54:51 What makes a good legal agent harness and why drafting