Legora has developed an AI agent for lawyers whose internal traces the company itself cannot read: the underlying data belongs to law firms and their clients. Jacob Lauritzen, Chief Technology Officer of Legora, explained how the team builds, tests and operates an agent under those privacy constraints.
Company background and capabilities
Legora began in a Stockholm basement with ChatGPT, Swedish law, and a search tool. Today the product lets a lawyer draft and edit Word documents, review 10,000 contracts in a single table using Tabular Review, or run due diligence. The agent coordinates work between lawyers, clients and other agents, and Legora used it internally when conducting diligence for its own acquisitions.
Legora is hiring engineers in New York, Stockholm and London.
Model choices and why they added a model picker
Lauritzen described how Legora resisted adding a model picker for years and ultimately introduced one. The discussion does not list every model in use, but it notes that the company runs everything on Microsoft Azure for privacy reasons and avoids certain speech/transcription providers (for example, they said they do not use ElevenLabs for transcription tasks).
Lauritzen estimates that current models already handle roughly 60% of legal work well, while the remaining, more complex 40% requires smarter models or additional system-level solutions.
Testing with simulated "worlds", the evals team and 10,000-file data rooms
Legora’s testing approach pairs three engineers with three lawyers to build test environments modeled on customers’ workflows — analogous to the “worlds” used in reinforcement learning. These simulated worlds include scenarios such as a 10,000-file data room to exercise the agent’s behavior on large-scale tasks.
The company has an evals (evaluation) team and about 100 legal engineers. Lauritzen described a citation-related issue where model performance went from 70% correct to 99% after a single model release; Legora did not have to change its own code for that jump, implying the improvement came from the updated model.
Product features: Tabular Review, intake and lists
Tabular Review is a spreadsheet-style, high-scale review interface — the industry even copied the name — that can be measured in the millions of cells. It helps lawyers surface patterns and issues quickly; Legora noted that often the first ten rows already convey substantial insight.
Intake can run via Slack bots, agents can create lists of items, and those lists can in turn start other agents. The product ecosystem includes an agent, Tabular Review, project management, and a Word add-in to let lawyers work in familiar tools.
Organizational roles: legal engineers and forward-deployed engineers
Legora separates the roles of “legal engineers” and “forward-deployed engineers.” Forward-deployed engineers work directly on onboarding large clients, while legal engineers focus on product and systems development. Both teams collaborate during major client implementations.
Lauritzen recalled an early slide depicting 300 Spartans: the original plan assumed 20 engineers would be enough indefinitely. Today the company has roughly 100 engineers and he still feels understaffed.
Broader implications: practice change, billable hours and junior roles
The conversation explored what legal practice might look like in five to ten years, including the future of law firm partnerships, the billable hour, and roles for paralegals and junior lawyers. Legora’s experience suggests earlier legal tech failed largely because it didn’t integrate into daily workflows; agents that combine search, retrieval and late interaction can change how drafting and review are done.
Lauritzen emphasized that drafting a long contract is fundamentally a search problem: locating and recombining clauses and precedents, not only generating free-form text.
Privacy, anonymization and platform choices
For data privacy reasons, Legora runs everything on Azure. The company discussed collecting anonymized examples and even floated the idea of acquiring a law firm for its data, but Lauritzen cautioned against some standard shortcuts, such as defaulting to embeddings without careful consideration.
Other technical and product decisions
- Legora resisted building public APIs for a long time and debated whether the agent itself could act as an API.
- The team considered post-training open-weight models for legal research and the possibility of model arbitrage between open-weight and proprietary models.
- They explained why certain transcription models (e.g., ElevenLabs) are not used, and why concise, less chatty outputs (for example, the team prefers Astra’s terser drafting style over more verbose models like Fable or Opus) are better suited for contract drafting.
Structure of the interview
The podcast-style interview is precisely chaptered with timestamps covering: the Stockholm origin, evolution from assistant to agent, model picker decisions, model capabilities today, simulated testing and data rooms, Tabular Review usage, intake and list workflows, acquisition of Wexler, the forward-deployed engineering role, onboarding large clients, the 300 Spartans slide and the original 20-engineer plan, bets the company made, use of post-training open-weight models, citation handling, hallucination mitigation, context-window strategies, anonymized example collection, and hiring & education implications.
Conclusion
Legora demonstrates that it is feasible to build production-grade legal agents while preserving client data confidentiality by combining closed execution environments (Azure), simulated customer-like test worlds, a sizable evals and legal engineering organization, and carefully chosen product primitives such as Tabular Review and a Word add-in. These technical and organizational choices shape how legal work may be reorganized in the coming years and raise questions about partnerships, billing models and junior legal employment.
