Building Legal Agents Without Seeing the Contracts: Legora’s Workflow and Judgment Problem

1. Guest Background

Jacob Lauritzen joins Alessio Fanelli and Shawn swyx Wang on Latent Space: The AI Engineer Podcast for an approximately 67-minute discussion of legal agents. The episode title identifies him as Legora’s CTO, although the opening transcript calls him CEO. That inconsistency remains unresolved in the supplied evidence. This article follows the title’s CTO designation and grounds his relevant experience in the product and engineering decisions he actually discusses.

Legora is a legal technology company that began in Stockholm and is expanding into the United States. Its tools cover legal research, drafting, Word editing, document organization, complex analysis, and collaboration. Lauritzen speaks from inside the organization building those systems. His account is particularly useful for understanding implementation choices and customer constraints; his broader observations about lawyers and commercial change should retain that perspective rather than become industry-wide findings.

His description of engineering growth establishes the organizational setting. He once wanted Legora to remain a team of roughly twenty engineers. At the interview, he says it has about one hundred and still feels too small for the demand. He now frames his job as making a limited set of underlying capabilities support a much larger range of customer experiences. The conversation consequently connects technical architecture with product delivery, staffing, and the difficulty of learning from confidential work.

2. What the Episode Covers

Legora began, Lauritzen says, as ChatGPT connected to a Swedish legal search tool. Lawyers could ask about precedent and comparable cases. The system subsequently acquired the ability to draft, edit Word files, organize documents, and conduct complex analyses. Alongside those execution capabilities, the company began building ways to coordinate work. His distinction between doing a task and orchestrating its surrounding workflow provides the interview’s organizing idea.

Tabular Review makes that distinction tangible. Documents occupy rows, while questions occupy columns. Lauritzen illustrates the process with ten thousand employment contracts: a reviewer might ask for termination notice periods, intellectual property assignment provisions, dismissal payments, and compensation. An agent can create the review, wait for processing, examine unusual results, and draft a client memorandum. This is an illustrative workflow, not a disclosed customer project. Likewise, his separate capacity claim concerns approximately one million cells, not one million documents.

The spreadsheet also provides a control surface. Legora initially processes the first ten rows so users can revise their questions before expanding the run. Outputs include source citations, and reviewers can mark cells as checked or risky, leave comments, and collaborate. These features matter because extraction alone does not establish that the resulting analysis is ready to deliver. The interface gives people places to inspect evidence and record the state of the work.

Intake addresses the other end of the process. A legal request arriving through Slack triggers an agent and enters a designated list. Lawyers work on it inside Legora, coordinate with colleagues and agents, mark it complete, and return the result through Slack. Lists functions as a configurable database, with triggers connecting agent runs, fields, and documents so an agent can populate fields or add new documents. Lauritzen describes Lists, Projects, the file system, and Agent as reusable building blocks. Wexler, an acquired business he discusses, supplies a litigation example: extracting facts and comparing corroborating or conflicting evidence, including hearing statements against emails.

Model selection is similarly divided by task. Legora routes subtasks to different models while also offering a primary model selector after customers requested control. Lauritzen estimates that current models already handle roughly sixty percent of existing legal work well, leaving cost and latency as major concerns for that portion. He supplies no measurement methodology; complex analysis remains an area where he wants more intelligence. His longer-term product vision replaces repeated email and Word-version exchanges with coordinated work that retains audit logs and data retention. A lawyer might eventually review what proactive agents have already done. He explicitly treats that future interface as uncertain.

3. Core Views: Reasoning, Examples, and Limits

The strongest engineering argument in the interview is that model improvement must be evaluated as a distribution of changes. Legora tracks performance across legal practice areas and tasks because, Lauritzen says, releases can improve some activities while regressing on others. Its project-style evaluations can use a ten-thousand-file diligence environment, but the final report is only one layer of assessment. Finding the right red flags is distinct from producing complete, well-worded, concise analysis without irrelevant material. A persuasive report can therefore conceal an upstream retrieval or risk-identification failure. Separating those stages makes the failure more diagnosable.

Professional expertise helps define those distinctions. Lauritzen describes a core evaluation team of approximately three engineers and three lawyers, supported by a pool of roughly one hundred legal engineers. These specialists typically have three or four years of large-firm experience; some also have computer science backgrounds. Their daily product use and customer contact connect evaluation design to legal practice. Yet that connection has a fundamental limitation: Legora generally cannot inspect customer data or execution traces. The documents may belong to a law firm’s clients, so the evaluation team must approximate what users are doing rather than simply replay their work.

Product metrics offer partial visibility into that gap. Legora considers renewals, return visits, activity, time spent, and inexpensive model-based online evaluations, and compares releases through feature flags. These can reveal whether a change appears useful or produces a sharp decline. They cannot fully reconstruct why a particular confidential analysis failed. Lauritzen gives no numerical activity rates, time savings, or return on investment. The evidence therefore supports a description of the measurement system, not a quantified business outcome. His reluctance to treat removed names or paraphrasing as automatically safe also limits how easily real work can be converted into test material.

The citation system exposes a related distinction between technical capability and human behavior. Generated material can cite a table row or cell, which can lead onward to highlighted evidence in an original PDF. This layered chain makes checking more practical. It does not by itself prove that the cited passage supports the entire inference, nor that anyone actually inspected it. The conversation acknowledges substantial variation in lawyers’ checking habits. Some concentrate on consequential passages as they would when reviewing a junior lawyer’s work. Traceability supplies a route to verification; it does not complete verification on the user’s behalf.

Drafting also depends on more than fluent generation. Lauritzen describes it as finding and assembling precedents: which comparable deals matter, which person has relevant knowledge, and which clauses should come from which documents? Similarity may involve an industry or company type rather than superficial textual resemblance. Long contracts then introduce two separate problems. Editing requires consistency across changed definitions, ordering, and earlier revisions. Retrieval can miss meaning spread across roughly two pages when no individual chunk looks relevant. Legora keeps changing its chunking and call orchestration as models change. At the interview it had not fine-tuned models; planned post-training focused on bounded tasks such as fan-out retrieval. Lauritzen still sees substantial opportunity in retrieval architecture, pipelines, and the legal agent harness.

The employment discussion warrants the same task-level precision. Lauritzen rejects the suggestion that paralegals and junior lawyers are already unnecessary and argues that strong junior practitioners can become more valuable. He provides no employment statistics. Legora’s own acquisition work offers a more concrete division of labor: its tools perform substantial diligence, while external counsel still handles cross-border risks and transaction structure. He says red flags have caused the company to stop proceeding, but withholds the cases. That supports the existence of a review-and-judgment workflow, not a measured success rate. His observations about project fees, flat rates, and free lower-end reviews in the United States likewise do not establish a general fall in legal fees.

Finally, the possibility of durable firm knowledge raises an incentive problem. Lauritzen wants methods and judgment encoded into assets that can accumulate beyond individual engagements. Partners rewarded mainly for bringing in clients, and unable to share asset returns after leaving, may have little reason to perform that work. Technical codification therefore needs an economic explanation as well. His prediction that enterprises will call Legora through general agents while firms use it directly belongs to the same forward-looking discussion. The four-hundred-million-dollar acquisition he invokes expresses the depth of work he wants the product to serve; it is not comparative evidence that a general system cannot serve it.

4. Learning and Application

A practical deployment can begin with a small, inspectable review rather than a large unattended run. Following the logic of Legora’s first-ten-row stage, define the questions, check whether fields such as notice periods or compensation mean what reviewers expect, and only then expand processing. Keep source links, risk flags, and review status available through delivery. This is an application of the episode’s workflow, not a guarantee supplied by it: an initial sample can expose poor questions while still missing unusual provisions elsewhere. Consequential conclusions need examination against their original context.

Model procurement should use a decision table that includes task quality, latency, cost, data destinations, regional availability, and supplier agreements. Lauritzen explains that Azure initially benefited from law firms’ existing acceptance of Microsoft through Microsoft 365 security reviews. Data processing agreements also constrained the number of vendors. A slightly stronger specialist service may therefore carry additional governance costs. The usable lesson is to establish an organization’s actual constraints before choosing models. Legora’s purchasing history does not demonstrate that every legal team should make the same cloud decision.

Implementation work can be divided by the kind of change required. Legal engineers configure the product, train users, and restructure workflows without writing code; forward-deployed engineers handle production code, difficult integrations, and API extensions. A team adopting this pattern can first clarify where requests arrive, who reviews results, and where completed work goes. Coding then addresses demonstrated platform gaps. Access boundaries remain separate from staffing: Lauritzen says FDEs usually cannot see customer data either, with occasional arrangements requiring onboarding like a customer employee.

Before committing to an integration, list its required operations and verify that each has an available interface. Legora had offered APIs for approximately six months and did not promise the entire web product through them. Lauritzen’s concern about old versions and changing data models explains the maintenance tradeoff. His idea of letting an agent act as part of an interface remains exploratory. For work requiring predictable execution, compare a bounded agent task with a direct API on observable completion, cost, and latency. The interview supplies no reliability result that would justify replacing interfaces wholesale.

Confidential debugging needs an explicit route for permitted evidence. Willing customers can provide documents and questions for reproduction, but anonymization is a processing step to assess, not automatic authorization. Lauritzen also questions whether buying a law firm would confer rights to its clients’ material. Even legitimate possession of inputs and final documents may leave the production process and output quality unclear. Where process evidence is missing, a fix should be described as addressing the reproduced case rather than every failure that may occur in practice.

Optimization should similarly start with a diagnosis: missing precedents, lost cross-chunk meaning, inconsistent editing, or poor output organization suggest different interventions. Test retrieval and orchestration before assuming post-training is necessary. The host’s suggestion to examine custom embeddings is qualified by Lauritzen’s multilingual requirements and the absence of comparative results. A useful experiment would compare candidates on the legal questions and languages actually served. Neither a general leaderboard position nor the word “custom” establishes the better choice.

Source

• Original episode: Building Legal Agents When You Can't See the Data — Jacob Lauritzen, CTO of Legora