Legora builds legal agents without ever seeing the data they process

Legora, the Swedish legaltech, has a problem that most AI product teams don't face: it cannot read a single real usage session of its own agent. The data belongs to clients of law firms, protected by professional confidentiality, and not even the engineering team has access to it. Jacob Lauritzen, the company's CTO, detailed how he works around this restriction in a nearly hour-and-ten-minute interview with the Latent Space podcast, published on November 2, 2026.

Legora was born in a basement in Stockholm with ChatGPT, Swedish legislation, and a search tool. Today, a lawyer uses the product to draft and edit Word documents, review 10,000 contracts in a single table (the Tabular Review feature, which became such a strong reference that the name was copied by competitors), and run full due diligence. Legora itself used the product to evaluate its own acquisitions.

Testing without being able to see

If you can't read the production trace, how do you know whether the agent is working? Legora's solution is to not rely on production to find problems. A team of three engineers and three lawyers builds test environments modeled on clients' real work, something similar to the simulated "worlds" used in reinforcement learning.

One of these environments is a simulated data room with 10,000 files, used to test due diligence scenarios without touching a single real document. It's a legal version of a pattern that already exists in ML engineering: when the production environment is expensive, dangerous, or, in this case, legally inaccessible, you build a substitute faithful enough to expose the same failures.

In short: Legora traded "observing production" for "simulating production," and put domain experts (lawyers, not just engineers) inside the very cycle that creates the test scenarios.

Paraphrased traces: a metric without content

The second piece of the puzzle is what Lauritzen called paraphrasing traces. Instead of reading the real content of a session (which would be a breach of confidentiality), the team works with rewritten, depersonalized versions of execution logs, enough to classify the type of failure without exposing the original data.

This is how the team managed to reduce the universe of problems to somewhere between 10 and 20 recurring categories, according to Lauritzen's account in the episode. For anyone building observability for agents in production, this is a concrete piece of infrastructure: an automatic redaction and rewriting pipeline that runs before any human or dashboard touches the log, similar to what teams handling sensitive data in Brazil already do with request payload in tools like Sentry or Datadog to avoid leaking a CPF (Brazil's individual taxpayer ID), medical records, or, in the legal case, the content of a confidential case file.

The jump from 70% to 99% that no one at Legora caused

One of the most revealing points in the conversation is a citation problem (the agent pointing to the right source within a contract or case file) that had been stuck at 70% accuracy. After a single model release, with no change to Legora's code, the metric jumped to 99%.

This episode illustrates a trade-off that every team building a product on top of a third-party model knows, but rarely sees quantified: part of your product's evolution is out of your control, sitting on the roadmap of the lab that trains the model. That's good when the jump is positive and free. It's risky when it means your technical edge can be absorbed by the next version of the base model, a point the episode itself raises when discussing whether model labs will one day cut legal tools the same way they've already restricted coding tools.

Infrastructure: Azure, embeddings, and the bet against giant context

Legora runs its entire operation on Azure, a decision described as a direct consequence of clients' data privacy requirements, the same law firms that won't let the company read their traces. It's the kind of constraint any Brazilian team dealing with LGPD (Brazil's data protection law) in a regulated sector (healthcare, legal, financial) will recognize: the choice of cloud is often dictated by contract and compliance before it's dictated by performance or cost.

Another technical detail worth the time of anyone building RAG: Lauritzen recommends not using default embeddings for search in the legal domain. The practical takeaway is that generic embeddings, trained on everyday language, lose the nuance of contractual terminology and legal precedent, requiring fine-tuning or a more sophisticated retrieval architecture, such as late interaction, mentioned in the episode.

There's also a direct debate about how to handle a million-token contract: put everything in one giant context window, or chunk it with MapReduce and aggregate afterward? The position discussed in the episode is that drafting a long contract is, at bottom, a search problem, not a window-size problem. For anyone deciding the architecture of a long-document pipeline, it's a reminder that a bigger context doesn't replace a good retrieval mechanism.

Small team, an API that doesn't exist, and the limit of the hype

Lauritzen used a slide with the 300 Spartans to argue, for years, that 20 engineers would always be enough. Legora now has 100 engineers and, according to him, the team is still too lean. It's a useful counterpoint to the current narrative that AI agents let a tiny engineering team sustain a giant product: in the practice of those actually building this, demand for specialized engineering (the so-called "legal engineers" and "forward-deployed engineers" described in the episode) grew along with the product's sophistication, it didn't shrink.

The company also resisted, for a long time, building a traditional API, even debating whether the agent itself could be the API. For integration teams expecting a conventional REST endpoint from agentic products like this one, here's the warning: the interface may be the agent talking, not an API contract in the classic sense.

What changes for those building here

None of these techniques are exclusive to law. Any AI product that processes data under confidentiality in Brazil (medical records, bank statements, court cases under judicial secrecy) hits the same limit: you can't debug by looking at the real data. Legora's answers, a simulated environment with domain-expert participation, anonymized and paraphrased traces, and proxy metrics instead of raw content, form a replicable engineering pattern, but one with a cost: it requires building and maintaining an anonymization pipeline, generating representative synthetic data, and accepting that part of your quality signal will always be indirect.