By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
Latent SpaceBuilding Legal Agents When You Can't See the Data — Jacob Lauritzen, CTO of Legora
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
CHAPTERS
- 0:00 – 0:40
Cold open: job displacement debate and why citations matter
The hosts open with a provocative take that paralegals and junior lawyers are “gone,” and Jacob pushes back with what Legora is actually seeing in practice. He also previews how a model update dramatically improved citation behavior without the team changing anything.
- •The host argues much legal work doesn’t need “Mythos-level intelligence,” implying junior roles could disappear
- •Jacob says that’s not what Legora is seeing in reality
- •Jacob describes a citation issue that jumped from roughly 70% to 99% after a model release
- •The host frames Legora as the kind of tool you’d want for very large, high-stakes transactions
- 0:40 – 1:54
Meeting Jacob Lauritzen and Legora’s “underdog” culture
Jacob introduces himself (including the origin of his Danish surname) and explains how Legora’s European roots shaped the company. He describes starting as an underestimated team in a Stockholm basement and learning to be bolder as they expanded into the US.
- •Jacob explains the meaning and origin of “Lauritzen” as a patronymic surname
- •He describes Legora’s early positioning as an underdog competing against larger US players
- •Jacob says the team’s default posture is humble because they had to fight for credibility
- •As Legora entered the US, they had to learn to more openly communicate confidence and ambition
- 1:54 – 4:12
From “ChatGPT + Swedish law search” to a broader legal work platform
Jacob walks through Legora’s product evolution, starting with a simple research agent and expanding into drafting, editing, organizing files, and complex analysis. He frames the platform as both doing legal work and orchestrating how legal work gets done.
- •Legora began as a ChatGPT-like interface combined with Swedish law search for legal research
- •Jacob describes legal research as finding precedent cases and relevant prior decisions
- •The product expanded to drafting, editing Word files, organizing files, and running analyses
- •Legora adds workflow/orchestration features like Lists, Intake, and Portal for collaboration
- 4:12 – 5:20
The assistant-to-agent shift and what “agent” means at Legora
Jacob pinpoints a shift from “assistant” to “agent” about a year prior, in a period before “agents” became mainstream. The discussion frames Legora as ChatGPT-like for lawyers, but enhanced with domain-specific tools embedded in the UI.
- •Jacob describes a deliberate switch from assistant behavior to agent behavior
- •The timeline discussion references YC timing and the era before agents “took off”
- •The host characterizes the core UI as “ChatGPT for lawyers,” plus specialized tools in the sidebar
- •The conversation sets up later deep dives into Tabular Review, Intake, and other modules
- 5:20 – 7:48
Model routing, the model picker, and why lawyers don’t want to think about models
They discuss using multiple models depending on task, and why giving users a model picker is controversial but sometimes demanded. Jacob and the host emphasize that lawyers mostly want the system to choose the best option, since model selection isn’t their job.
- •Jacob says Legora uses different models by task and sometimes by tool
- •Legora includes a model selector for the agent’s primary model, though Jacob isn’t sure it will remain
- •The host argues domain wrappers should abstract model choice away from end users
- •They note some users still want to try new models and accept burning credits faster
- 7:48 – 9:25
Are models good enough yet? Evals, regressions, and what improved in nine months
Jacob describes current model capability as a distribution: a majority of work is already handled well, while complex analysis still needs more intelligence. He explains how Legora tracks model performance across practice areas and tasks, and notes that releases can improve some areas while regressing others.
- •Jacob estimates a large portion of legal work is done well today, with remaining gaps in complex analysis
- •He describes sub-agent delegation as a key capability that improved significantly
- •Legora maintains a heat map of model performance across practice areas and task types
- •Jacob notes model releases can regress some tasks even when they improve others
- 9:25 – 12:09
Simulated eval “worlds,” the evals team, and leveraging 100 legal engineers
Jacob explains how Legora evaluates agents using project-like simulated environments, such as due diligence in a large data room, and grades outputs like reports and red-flag detection. He details an evals team combining engineers and lawyers, plus a larger pool of “legal engineers” who act as force multipliers for product and evaluation work.
- •Evals are structured as project “worlds,” such as a due diligence with a very large data room
- •They break tasks into components like drafting the final report and finding red flags
- •The evals team includes both engineers and lawyers working together
- •Jacob describes “legal engineers” as ex–Big Law lawyers with strong tech backgrounds, used heavily in product shaping and evals
- 12:09 – 22:44
Where legal economics changes: partnership incentives, junior roles, and the billable hour
Jacob predicts lawyers will become more productive and spend more time on judgment and client work, while less time goes to tedious document trawling. They debate how this affects junior roles and the pyramid, then unpack why billable hours historically resisted efficiency—and why pricing is already shifting toward fixed/project fees for some work.
- •Jacob forecasts higher lawyer productivity and more focus on strategic judgment and client relationships
- •He analyzes why partnerships exist in professional services: aligning ownership with human capital
- •Jacob argues firms need durable “intangible capital” by codifying firm-specific ways of working into systems
- •They discuss billing shifts: some work moving to flat/project fees, and even some work done for free to maintain relationships
- 22:44 – 26:12
Dogfooding Legora in M&A diligence and how client behavior differs by region
Jacob explains how Legora uses its own tools to conduct parts of acquisition diligence, while still bringing in counsel for strategic risk assessment—especially across jurisdictions. He also contrasts American and European customers: US firms move faster and often want custom builds and integrations, while European firms more often prefer off-the-shelf workflows.
- •Jacob says Legora frequently uses its own product for diligence work in acquisitions
- •They still use outside counsel for strategic assessments and jurisdiction-specific issues like payroll
- •Jacob declines to share specific red-flag examples but confirms they’ve paused deals based on findings
- •He contrasts US appetite for deep custom integrations with Europe’s preference for off-the-shelf adoption
- 26:12 – 28:42
Measuring product success when you can’t read traces: privacy constraints and safe signals
Jacob outlines standard enterprise product metrics (usage, renewal, engagement) plus lightweight online eval signals used for rollouts. He emphasizes a core challenge: Legora generally can’t inspect user traces or customer data because it belongs to law firms’ clients, forcing the team to approximate behaviors via eval sets and classify failures into broad types.
- •Legora tracks usage metrics like engagement and renewals, and uses online eval signals for feature flags
- •Jacob says they largely cannot inspect traces due to confidentiality and client-owned data
- •They discuss paraphrasing/abstraction as a spectrum, and choosing the safest approach
- •Jacob describes classifying failures into roughly 10–20 known modes to get actionable signal without seeing data
- 28:42 – 33:32
Privacy-driven infrastructure choices, model arbitrage, and speech/transcription trade-offs
Jacob explains Legora’s infrastructure runs on Azure, originally because many law firms rejected AWS and trusted Microsoft due to existing 365 security approvals. They then discuss “model arbitrage”—optimizing across model cost, latency, governance, and availability—and why transcription quality is still not “good enough” in legal contexts, including vendor constraints from strict data processing agreements.
- •Jacob says Legora chose Azure because many firms wouldn’t accept AWS or other vendors at the time
- •He notes on-prem interest has largely faded as firms accepted cloud as safe (and often safer)
- •They discuss routing tasks across frontier and open-weight models based on cost/latency/governance trade-offs
- •Jacob highlights transcription use cases (including uploaded hearings) and notes vendor limitations due to strict DPAs
- 33:32 – 42:37
Product deep dive: Agent, Tabular Review, Word add-in, Intake, and the Lists primitive
They walk through Legora’s major product surfaces, focusing on Tabular Review for bulk extraction across thousands of documents and Intake for Slack-based request routing. Jacob explains why a spreadsheet form factor works, how users validate by running the first 10 rows, and how Lists act like a flexible database that lets agents trigger workflows and build new products—including litigation-oriented “fact intelligence” from the Wexler acquisition.
- •Tabular Review is used for large-scale diligence: each row is a document, each column is a question to extract
- •The agent can automatically spin up a Tabular Review, analyze results, flag red flags, and draft memos
- •The spreadsheet format supports citations to source documents and collaborative review, including marking cells reviewed
- •Intake in Slack creates tasks in Lists; Lists can trigger agents and agents can create/read Lists, enabling automation and modular product building
- 42:37 – 53:05
Forward-deployed engineering, onboarding big clients, and why Legora resisted broad APIs
Jacob describes how legal engineers and forward-deployed engineers help clients get value quickly, with clear separation: legal engineers configure without code, while forward-deployed engineers ship production integrations. He explains why Legora delayed expanding its API surface—moving fast as a small team made versioned APIs costly—and explores whether “the agent could be the API,” balanced against determinism, cost, and latency concerns.
- •Jacob says forward-deployed engineers are “true engineers” who write production code, unlike legal engineers
- •Onboarding varies by client; teams map existing workflows into Legora and build integrations when needed
- •Forward-deployed engineers may be onboarded like client employees (e.g., given a laptop) but still avoid touching client data
- •Jacob explains API reluctance: rapid product iteration made API maintenance too expensive early on, and he considers whether triggering the agent could replace some API needs
- 53:05 – 58:35
Post-training open-weight models, search as the core bottleneck, and citation-backed hallucination control
Jacob explains Legora hadn’t fine-tuned models historically, but is now post-training open-weight models for bounded tasks where it matters—especially legal research as a fan-out retrieval problem. They discuss search architecture choices, harness/scaffolding around drafting and editing, dealing with verbosity in drafting, and a citation system that links claims back to highlighted source evidence; Jacob notes lawyers’ verification habits vary, similar to code review.
- •Jacob says Legora is beginning post-training for narrow tasks, not trying to build a general frontier model replacement
- •Legal research is highlighted as a key target: fast, cheap, low-latency retrieval and reasoning
- •They discuss harness elements like file editing workflows, analysis pipelines, and how drafting depends on finding the right precedents
- •Jacob describes a citation system with clickable links that highlight exact source passages, while acknowledging many users won’t verify everything
- 58:35 – 1:07:21
Long-document limits, getting anonymized examples, embedding strategy, and the platform outlook
Jacob notes long-document reasoning and consistent edits across massive contracts remain difficult, forcing teams to switch between chunking/orchestration and “put everything in context” approaches as models evolve. They discuss asking customers for anonymized examples to reproduce failures, the limits of buying data, and the importance of not relying on default embeddings—while also needing multilingual support. The episode closes with questions about whether lawyers will work inside Legora or via general assistants, vendor risk from model labs, early thoughts on law-school adoption, and hiring locations.
- •Jacob says long-document reasoning and consistent cross-document edits are still hard for models today
- •They discuss requesting anonymized customer examples to debug issues that can’t be inspected directly
- •The host and Jacob argue against “default embeddings,” while Jacob flags multilingual needs as a key constraint
- •Jacob predicts both workflows will exist: enterprises may use general assistants plus tools, while law firms may prefer using Legora directly; they close with discussion of law-school programs and hiring in New York, Stockholm, and London
