Legora raised its legal agent's accurate citation rate from 70% to 99%

Legal AI faces an awkward contradiction. To improve an agent, developers benefit from reading its traces: which documents it opened, what it found, where it went wrong, and why it chose the wrong answer. But in legal practice, that data often belongs not to the firm itself but to its clients. The product team cannot simply inspect another contract and manually analyze the failure.

Legora addresses this problem with reproducible simulations. Three engineers and three lawyers create synthetic work environments resembling real client matters. One example is a repository of 10,000 files where the agent must conduct due diligence, prepare a report, and avoid missing material risks. This pattern is useful far beyond legal tech: when production data is restricted, teams need to recreate not the documents themselves, but the workflow, success criteria, and characteristic errors.

Testing without access to documents

Imagine a service that analyzes thousands of employment contracts. Each row is a separate document, while the columns contain questions such as the termination period, assignment of intellectual property rights, and compensation amount. Running the process across the entire dataset immediately is expensive and risky: a poorly worded prompt will replicate one mistake across thousands of cells.

That is why Tabular Review initially processes only 10 rows. A lawyer checks the result, refines the prompt, and only then runs the remaining documents. It may sound almost too simple, but this interface is exactly what turns an experiment with a model into a controlled production process. Users see a small sample before spending the budget and receiving a million potentially incorrect answers.

Legora evaluates quality separately across legal practice areas and task types. Results are displayed as a heat map: a new model may be better at finding court decisions but worse at editing contracts. A single score is not enough. For any team building a specialized agent, the takeaway is straightforward: compare models on specific workflows, not on their overall reputation or a single averaged benchmark.

Errors need to become a catalog

In production, Legora groups failures into 10–20 known types and runs inexpensive LLM checks behind feature flags. This does not guarantee perfect accuracy, but it makes quality observable. Instead of a vague message that “the agent sometimes makes mistakes,” the team gets a specific category: a caveat was omitted, a conclusion is not supported by a source, a citation points to the wrong passage, or the answer does not match the required format.

The citation mechanism is particularly revealing. Every conclusion produced by the agent is linked to a specific area of the source PDF so that a lawyer can open the supporting passage. According to Legora's chief technology officer, after one model update, the share of accurate citations rose from approximately 70% to 99%. However, this episode also highlights a limitation: some quality depends on the external model provider and may change with the next release. Every new version therefore needs to be tested, even if it is considered more capable.

What to bring into your own product

Do not start by choosing the “smartest” model. First, compile a list of real tasks, create a private evaluation set for them, and define acceptable errors. If the documents cannot be used, build synthetic equivalents together with domain specialists. Test not only the final answer, but also source references, processing completeness, and stability across large datasets.

For bulk operations, add a preliminary run on a small sample. For every update, break results down by task: where quality improved, where it declined, how much the additional percentage points of accuracy cost, and how latency changed. Turn known failures into separate automated checks.

Legora's central idea is not its legal specialization. It is that confidentiality does not eliminate measurability. If user traces cannot be inspected, the team must model the client's work more precisely. This costs more than simply reading logs, but it creates an asset that remains inside the company: a proprietary evaluation system, an error catalog, and a clear quality threshold that an agent must meet before entering production.