Building Legal AI Agents Without Seeing Client Data: Legora's Jacob Lauritzen

Legora CTO Jacob Lauritzen joins swyx and Basil Chatha to discuss building AI tools for lawyers. He describes the company's Stockholm origins as a persistent underdog story: entering the US required its team to become more comfortable telling customers what it had built.

Legora began as a ChatGPT-style interface with a Swedish law search tool. Legal research meant finding relevant earlier cases and precedent; the product has since expanded into drafting, editing Word documents, organizing files and conducting more complex analysis.

One expansion is tabular review, which extracts information across large collections of agreements. Another is orchestration: lists organize work, while intake and portals help lawyers, clients and agents collaborate. Lauritzen sees the opportunity as both doing legal work and improving how that work moves between people.

The team describes its transition from an assistant to a more capable agent. Lauritzen places that change roughly a year before the interview; the hosts note how quickly the field has moved. Legora was in Y Combinator's 2024 batch, while Lauritzen had participated in 2023 separately.

Legora uses different models for different tasks. Users can choose the agent's primary model, while individual tools may route subtasks elsewhere. Lauritzen says the team resisted adding a selector, but some customers wanted the control and access to new models even when the additional capability might not be necessary for a given task.

The hosts frame a domain-specific agent provider as an intermediary that follows the model landscape for its users. A lawyer should not have to decide which model tier is right for every contract. Lauritzen wants to balance quality, cost and speed, although he acknowledges that some users still want to experiment themselves.

Lauritzen estimates that current systems can handle roughly 60% of legal work well, leaving cost and latency as important constraints on that portion. More complex analysis still needs greater capability, in his view, and better systems may also expand the work lawyers choose to undertake. He offers the figure as an estimate, not a measured industry benchmark.

Delegating retrieval to subagents is one area he says has improved. Legora tracks model performance across legal practice areas and tasks in a heat map. New releases often improve overall, he says, but can also regress on particular tasks, making it useful to test them rather than assume every change is an improvement.

For evaluation, the team constructs scenarios that resemble legal projects. A simulated due-diligence data room might contain 10,000 files and require a report identifying particular red flags without introducing irrelevant claims. The team can evaluate the quality of the analysis separately from the clarity and completeness of the drafted report.

The dedicated evaluation team combines engineers and lawyers; Lauritzen says it then had about three of each. It can also draw on a larger pool of legal engineers, typically lawyers with large-firm experience and an interest in technology, who use the product and talk to customers. They help shape both product development and evaluation.

Earlier, the team often benefited simply from exposing steadily improving models through a better product and harness. Lauritzen recalls one citation problem where a subsequent model release raised performance on that particular problem from about 70% to 99% without a change by his team. He does not present that as a general citation accuracy rate.

Product design also requires a view of how legal work might be organized in five or ten years. Lauritzen imagines reducing long email chains and document-version exchanges while retaining audit logs, retention controls and other requirements of regulated work. Proactive agents might eventually surface tasks for lawyers to review rather than wait for every instruction.

Lauritzen explicitly qualifies his forecast: no one knows exactly what the profession will become. He expects lawyers to spend more time on strategic judgment, risk and client relationships, and less on tedious document searches. The outcome depends on both technical progress and how firms redesign their work.

Asked about partnerships, Lauritzen observes that professional-services firms historically depend on human expertise, making ownership structures a way to retain valuable people. He wonders whether firms could build more durable assets by codifying their methods, precedent and judgment in systems that others at the firm can use.

That idea raises an incentive problem. Partners who are rewarded for bringing in clients may have little reason to spend time building an asset that benefits the firm after they leave. Lauritzen does not claim to have solved the business model; he sees the incentives around durable institutional knowledge as an open question.

The hosts press him on whether junior lawyers and paralegals disappear. Lauritzen says that is not what he is seeing: firms still need a next generation, and capable junior staff may become more productive and valuable with better tools. The conversation distinguishes individual tasks that can be automated from a settled prediction about whole occupations.

Hourly billing creates another tension. Lauritzen recalls initially questioning why law firms would adopt technology that makes billable work faster. He now sees competitive pressure pushing firms to change, and says some lower-complexity work is already priced as a project or flat fee rather than strictly by the hour, particularly in the United States.

Strategic work, major transactions, litigation and client relationships remain valuable in Lauritzen's account. Some firms have historically done limited work without charge to maintain relationships; reducing routine effort can change the economics of that service. He does not claim that every legal fee will fall.

The group discusses the skills needed when people supervise agents. Knowing a legal workflow, the tools and how to refine an output can be meaningful work in its own right. Lauritzen says routine bulk review may require less overnight manual extraction, leaving staff time for other responsibilities.

Legora has used its own tools in acquisition due diligence. Lauritzen says tabular review helps its team find issues early, while outside counsel still advises on strategic risks and local questions such as payroll in another jurisdiction. He says the team has found red flags that caused it to pause, but declines to disclose deal details.

In Lauritzen's experience, US customers have generally moved faster and shown more appetite for custom systems and integrations, while European customers more often start with an off-the-shelf product and provide feedback. He cautions against reading this as evidence that one group cares less about AI: he sees different routes toward a shared strategic priority.

The company tracks familiar product signals such as return usage, time in the product and renewals. It also uses online evaluations and compares feature rollouts to look for improvements or serious regressions. The unusual constraint is that it generally cannot inspect the underlying customer traces: the confidential material often belongs to a law firm's clients.

The hosts ask whether a model could paraphrase real interactions to make safe examples. Lauritzen says merely removing names may not be sufficient, so the company generally chooses a more restrictive approach. Classifying a failure into a small set of categories, task types or practice areas can yield some signal without exposing the underlying matter.

Customer data requirements also shape infrastructure. Lauritzen says Legora initially hosted on Azure in part because firms were already familiar with Microsoft as a vendor. He describes customers' attitudes to cloud infrastructure as having changed over the preceding years; his account is about those customer choices, not a guarantee that any particular deployment is secure.

For each task, the company weighs model quality against latency, price, governance and regional availability. Lauritzen says some open-weight models are useful for specific jobs, while frontier models remain appropriate for others. He is interested in post-training for narrowly defined tasks rather than assuming one model is best everywhere.

As an example of specialization, he cites an early Gemini model that worked well for certain transcription and speaker-attribution tasks. Vendor selection also depends on data-processing agreements: keeping the list of providers short can make governance simpler, even when another specialist model might be attractive.

The group cautions that speech recognition still makes consequential errors with domain-specific vocabulary. One workflow discussed is to extract likely keywords with a language model and run transcription again with that guidance. Lauritzen says errors become especially visible at scale or outside ordinary conversation.

The conversation returns to product design: the agent, tabular review, and Word and Outlook integrations are major components. In a due-diligence table, each row can represent an employment contract and each column a question, such as the notice period, an intellectual-property assignment or compensation.

An agent can start a bulk review, wait for it to finish, analyze the results and flag unusual items for a lawyer, or help draft a memo. The spreadsheet makes it easier to scan results, collaborate, mark items reviewed and follow citations to source documents. Lauritzen says the team has handled tables with up to a million cells.

Before running a question across a very large set, the product runs the first ten rows so a user can inspect and refine the query. The hosts compare this with testing a small sample before a large fan-out: quick feedback can reveal that the question is not extracting what the lawyer intended.

Intake is more than a generic Slack bot. A request can become an item on a legal team's list, where lawyers and agents work on it and mark it complete; the result can then return through Slack. The requesting employee need not change interfaces, while the legal team has a shared place to manage the work.

Lauritzen calls lists a flexible primitive, comparable to a configurable database. Triggers and automations can start agent runs; agents can read or update list fields and add documents. The same building blocks let legal engineers configure specialized workflows and dashboards without the company building every experience from scratch.

He points to the acquisition of Wexler and its litigation-focused fact intelligence as another use case. The idea is to extract dated facts and named entities from documents, then compare evidence that supports or conflicts with a claim. He presents this as an application of the platform's primitives, rather than a substitute for a lawyer's assessment.

Legora's legal engineers and forward-deployed engineers have different roles. Legal engineers configure workflows as expert product users and help customers adopt them; forward-deployed engineers write production code, build integrations and feed needs back into the core product. Which people join a customer project depends on its scope.

A common workflow might be configured within the product, while a complex integration or a missing primitive can require engineering work. Lauritzen says forward-deployed engineers still do not need to see confidential matter data when building a system, though customers may sometimes onboard them like employees when necessary.

The company has APIs but does not promise that every product feature is exposed through them. Lauritzen says the team delayed opening APIs because it was changing quickly and did not want to maintain old versions of a changing data model. As the company grew, it became more able to bear that maintenance cost.

He is also considering whether triggering an agent could serve some integration needs that would otherwise require a conventional API. This is an idea under exploration, not an announced product commitment. The participants note the tradeoffs: agent execution can be slower, more expensive and less deterministic than a fixed endpoint.

Lauritzen once imagined keeping the engineering team to 20 people, like a small force competing against larger rivals. He says the team had reached around 100 engineers and still felt small relative to demand. His aim is to create a few reusable primitives that support a much broader range of customer-facing capabilities.

Customer demand determines much of the roadmap, but the team sometimes makes a strategic bet ahead of an explicit request. Lauritzen cites the move toward a more autonomous agent and collaboration inside the product. Legal engineers then help firms adapt workflows to capabilities they may not have known to ask for.

At the time of the interview, Legora had not yet fine-tuned its own models, Lauritzen says. He expects selective post-training of open-weight models for bounded tasks such as parts of legal research, where a specialized model could improve the cost and latency of high-volume retrieval. He does not propose training a general frontier model to replace the main agent.

There is still substantial work to do in retrieval pipelines and agent harnesses without training a model. Lauritzen mentions possibilities such as improved embeddings and late interaction, while clarifying that the latter is not something the team currently uses. Better search, analysis, file editing and governance can all improve the final result.

Drafting a complex contract is also partly a search problem. A lawyer looks for clauses and precedent from comparable transactions, where similarity might mean industry, counterparty or deal type, then decides which parts of multiple documents belong in the new agreement. Finding the right material is not a trivial prelude to writing.

To make generated claims inspectable, Lauritzen describes citations that link to highlighted locations in source documents. A claim based on a tabular review can link to a cell and then further down to the document. Such links support verification; they do not remove the need for people to decide which claims and sources to check.

He compares review practices to code review: people differ in how closely they inspect outputs, and experienced reviewers may focus on high-risk points. Long-document reasoning remains difficult, especially when edits to definitions or ordering must stay consistent throughout a contract.

Breaking a long document into pieces can help orchestrate edits, but summarizing chunks independently can lose a point that only becomes clear across their boundary. The team changes its scaffolding as models improve and considers different search approaches depending on the material and question.

Customer feedback can sometimes provide an anonymized document and prompt that reproduce a failure, if the customer is willing to engage. The speakers also discuss acquiring legal data, but Lauritzen notes uncertainty over whether a firm's records belong to the firm or its clients. An output alone may not reveal the reasoning or quality of the process that produced it.

The hosts recommend testing embeddings against the actual retrieval workload rather than selecting a default solely from a benchmark. Lauritzen agrees and adds that multilingual performance matters for Legora's users, especially across European languages.

Looking ahead, Lauritzen expects some enterprises to access specialist legal capabilities through broader tools and APIs, while firms may use Legora directly. He sees model providers building general legal features but expects a specialist product to go deeper on demanding workflows. These are his competitive predictions, not guarantees about future products.

Asked about law schools, Lauritzen says the company wants students to learn its tools but does not claim knowledge of how curricula are changing. The conversation closes on hiring and the broader importance of legal work to organizations: finance, employment and other business decisions regularly depend on legal judgment.

Lauritzen says Legora is hiring engineers in New York, Stockholm and London, with other roles in additional locations. The hosts close by returning to the breadth of the field: legal expertise touches hiring, finance and much of organizational life, which is why Lauritzen finds the work compelling.