summary

Executive Summary

Three things determine whether a legal AI agent is effective. The model underneath it, the harness built around it (for example, legal-specific agents like CoCounsel, Lexis+ with Protégé, Harvey, Legora, and NetDocuments’ own assistant, or general-purpose ones like ChatGPT or Claude), and the context it can reach while it works — the documents, the search that finds them, the knowledge graph connecting documents together, and whatever else the firm surfaces about the matter. A number of quality benchmarks (like Vals’s VLAIR and Harvey’s BigLaw Bench) already exist to measure the first two factors in isolation or all three holistically. But to the best of our knowledge, none isolates the impact and economics of the context layer itself — what changes, in both answer quality and cost, when the model and harness are held fixed and only the context varies. 

That gap matters because each factor — model, harness, and context — evolves separately over time and presents different strategic opportunities to firms. Models improve with the progress of foundational model lab companies. Harnesses are an extremely competitive space, and firms often use multiple at once or swap between them over time as the landscape changes. Context is the layer that is built once and carries forward across every model upgrade and every agent a firm adopts. It is one of the few places where a firm’s own investment compounds instead of resetting. 

With that in mind, we built a benchmark based on the simplest principle: hold the model and the harness constant, make modifications only to the context layer, and measure what changed in terms of accuracy and cost. Our benchmark is deliberately neutral about how context is supposed to get better, since richer metadata, sharper retrieval, custom skills, and a knowledge graph are all candidates. 

Accuracy alone would be the wrong scorecard, because accuracy can nearly always be bought with more spending: a bigger model, more reasoning, more retrieval. Any honest measure of a context layer therefore needs to weigh the quality it produces against what that quality costs to obtain. The unit we settled on is the cost of a correct answer. The change in that figure is what we call the Context Value Ratio (CVR). When we evaluated our Legal Context Graph against this benchmark, the results were decisive. For example:

This efficiency presents firms with a choice. They can take the savings, reinvest them in better answers, or do both. A firm satisfied with current accuracy can realise the savings directly. For a 2,000-person firm asking four million questions a year, that translates to approximately $940,000 in annual savings at unchanged quality. A firm that wants better accuracy can reinvest some of that efficiency. In the benchmark we discuss an example where raising the model’s reasoning effort from medium to high improved accuracy by 7% while still costing 18% less than the baseline. In practical terms, that is 216,000 additional correct answers a year. These are not easy gains: the answers a system has yet to get right are by definition the difficult ones.

And while those numbers are the headline, this report focuses deeply on the methodology behind them: how and what to measure about legal context, what a gain in answer quality is worth against what it costs, and where further investment returns the most. The aim is to provide legal departments and law firms with a reusable framework to assess the impact of their own context layer over time. 

01 – How it works

How the LCEB — and the framework behind it — works

The fundamental design of the Legal Context Engineering Benchmark is a controlled comparison with a single variable. One agent, meaning a fixed model inside a fixed harness, answers the same set of questions twice. On the first pass the agent has only the tools an agent ordinarily has: a search across the matter’s documents and the ability to retrieve their text for further investigation. On the second pass it has those same tools and can additionally reach the enhanced context layer under test (for example, a knowledge graph, better metadata filters, semantic search). Because the model, the instructions, and the questions are all held constant across the two passes, whatever difference emerges in answer quality or in cost is likely driven directly by context engineering. 

Note that holding other variables constant is more difficult than it sounds. A tool description that steers an agent in a way that overfits the test data set, an altered system message that directs the agent to behave differently, a search parameter tuned for one side and left alone on the other: each of these introduces a second variable, and any result that follows is no longer a measurement of context. Our internal testing harness therefore compares the two tool surfaces before a run begins, and cannot proceed if they differ in any respect other than the availability of the Legal Context Graph itself. 

The current version of our benchmark runs on ten real matters, five transactional and five litigation, assembled from public regulatory filings and court dockets that either in whole or in part autumn outside the training data cut-off of the models we tested with (this helps ensure agents are not answering from their training data and are forced instead to rely solely on the content of the test matter). Together the ten matters hold 874 documents and roughly 60 million characters: registration statements and proxies that run to hundreds of thousands of characters apiece, alongside dockets of motions, orders, deposition transcripts and correspondence. Nothing in the corpus of documents was synthetically generated, which is a deliberate design choice we made. Time and time again in our testing, we saw that a synthetically generated matter that looked realistic from afar lacked internal logic or — worse yet — converged on an unrealistic simplicity upon closer inspection. 

Each matter in the LCEB carries at least twenty-five questions — three hundred across the ten — and every one of them is a question a legal professional would have reason to ask. They are deliberately spread across a range of difficulty and type, and each is labelled with the type it belongs to. 

Questions are drafted from the source documents by fanning out a series of strong models to read every document in a matter in full, often an enormously token-inefficient and expensive endeavour. The agents then propose question-and-answer pairs from what is encountered in these deep dives. Each pair is authored in three parts: the question itself, a reference answer setting out what the record actually supports (including citations), and a short list of the specific things a complete answer must contain, which becomes the scoring rubric for that question. 

Finally, we cross cheque answers and rubrics via deterministic validations (for example, do the citations in the answer actually map to text in the document corpus), as well as via spot checks by a human subject matter expert. 

The answers outputted by agents over the two test runs — for example, once with the Legal Context Graph enabled and once without it — are then graded by a strong model, which sees the question, the criteria that apply to it, the outputted answer in full, and the trace of tool calls the agent made in producing it. 

A run records two things: whether the answer was right, and what it cost to produce. Every call the agent makes is counted, and its tokens are sorted into three kinds — fresh input, cached input, and output — because each is billed at a different rate. Those rates are the published prices for the model doing the answering, current as of publication. What comes out is a figure in dollars. 

Note that because the model is held fixed within a comparison, the comparison can be repeated on a different model and the results read side by side. We did so across all three members of the GPT-5.6 family, so that only capability changes and the pricing structure stays comparable: 

All three share a February 16, 2026 knowledge cut-off, so training exposure to the corpus is identical between them. All three ran against the same ten matters, the same 300 questions, the same rubrics, the same live document backend, and the same grader configuration. The only thing that differs between the three scorecards we present later (in Section 2) is which model answered the questions. 

Two properties make this additional comparison worth performing. First, it tests whether a context layer is a crutch for weak models or an accelerant for strong ones — a distinction that decides whether the investment survives the next model upgrade. Second, CVR divides two costs measured on the same model, so the model’s price appears in both the numerator and the denominator and cancels out. What survives the cancellation is the precise thing we want to compare: how much each model’s use of the context layer changes what a correct answer costs it. This is why the three ratios can be read side by side even though the dollar amounts behind them cannot. 

02 – the unit of measurement

What a correct answer costs

Cost variation between one agent and another running on the same model used to be small enough to ignore in most cases. When an agent answered in a single pass it read modestly and wrote modestly; now it plans, calls tools, reads, retries, and checks its work, and that has become the largest variable cost of running the system. This trend is only accelerating. METR, measuring on software and research tasks rather than legal ones, finds that the length of task a frontier agent completes unaided at a 50% success rate now runs to several hours, and has been doubling roughly every four months. 

That makes cost something to be measured, as well as raising the question of what unit to measure it in. Cost per query, or per task, is the easiest figure to compute and among the least informative, because what a legal professional truly cares about is a correct answer. Cost per correct answer is therefore the barometer we selected: the total spent on a run divided by the credit-weighted number of correct answers within it, which yields a single figure in dollars where lower is better. 

What that figure prices is the cost of answering: every model call the agent makes while responding to a question or performing a task. Building the context in the first place is a separate cost, paid once per matter rather than once per question, and it belongs in the fully-loaded view discussed in Section 4. 

Then:

The Context Value Ratio is how many times cheaper a correct answer becomes. At 2.0, the context layer makes a right answer cost half as much. Above 1.0 it earns its cost; at 1.0 it breaks even; below 1.0 it costs more than it returns. 

The ratio measures a change, which is the question a firm weighing an investment has: from where we are, does this pay? What it cannot say is where a firm stands to begin with. That is why beside the CVR figure we always look at the quality score: how much of a complete answer the agent delivers, averaged over every question, from 0 to 100. 

Both numbers are absolutely essential, because a price can always be improved by curtailing effort rather than by improving, and the least costly way to reduce the cost of a right answer is to stop attempting the questions that are hard to answer. Consider two systems put to the same hundred questions: 

System B’s answers cost a third less each, and System B is the one no firm would want, having left sixty questions in a hundred unanswered. Price alone cannot tell them apart. 

The same caution applies to comparing two different systems – or across different document sets – because a price is easiest to improve when there is room left in your benchmark: a system answering six questions in ten has inexpensive gains available throughout, while one already answering nine in ten must spend heavily for each remaining point. The ratio is most trustworthy read against a firm’s own prior baseline — same matters, same questions, with the context layer and without it. 

That is the whole of the method. What it produces is the set of scorecards below. Let’s dig in. 

03 – Putting it into practice

What the savings are worth to a firm

A ratio like the Context Value Ratio is helpful in theory but what really matters for law firms and legal departments is how to put it into practice: either to improve their business or to level up their legal service delivery. This section covers exactly that. 

Consider a large firm — 2,000 professionals with access to a legal AI assistant — and ask what the Legal Context Graph is worth to them over a year. Three configurations bear on the question, and we measured all three on the frontier model across the same 300 questions: 

The first two rows are the benchmark result of Section 2, expressed per question: the context layer holds quality and halves the price. The third row is central to what this section is about. Having reduced the cost of a question by nearly half using the Legal Context Graph, a firm need not realise that savings as literal cash. It may instead “reinvest” part of those savings on agent harness configurations that raise accuracy — a larger model, a longer reasoning budget, broader retrieval. For the purposes of this example we take the simplest of these: raising the reasoning effort of the model from medium to high, which permits the same agent to deliberate longer on each question, reasoning at greater length, verifying more and reading further. 

What makes that upgrade affordable is the context layer. Raising reasoning effort costs roughly 1.5× more per question whether or not the Graph is present. Applied to the unassisted baseline, it would raise the firm’s spending by about half. Applied on top of a question price that has already been halved, the same upgrade leaves the firm spending 18% less than it does today. The accuracy is therefore purchased with expenditure the firm had already budgeted. 

A firm consequently faces a genuine strategic choice rather than a funding request, since neither path requires spending a dollar more than it spends now. The first is to bank the saving while keeping quality held at parity, 73.9 against 75.4. The second is to reinvest it: accuracy rises from 73.9 to 79.3 while spending still falls. The magnitude of each depends on how heavily the firm works the tool, which is the one variable we cannot supply. Across 250 working days and 2,000 professionals: 

At eight questions per person per day — a realistic figure for a law firm whose professionals genuinely rely on agents as daily work companion — banking the saving returns roughly $940,000 a year, recurring, for a capability the firm has already built. On the other hand, reinvesting it yields 216,000 additional correct answers, with the firm still some $371,000 a year better off than it is today. 

The second of those merits particular attention, as it inverts the customary trade-off. Accuracy in AI systems is ordinarily achieved through more spend: a larger model, more reasoning, more retrieval, each of which costs more. Here the ordering runs the other way. The context layer reduces the price of a question first, and the accuracy is funded from the proceeds, so that a firm concludes the year both more accurate and financially further ahead — a combination rarely available. 

It matters most, moreover, exactly where a benchmark becomes hard. As a system approaches the ceiling on a question set, the answers that remain outstanding are the expensive ones: the multi-document reconciliations, the questions whose answer appears once in fifteen million characters. Those are precisely the answers that further deliberation buys. A firm that has freed up budget can afford to spend it on that tail; a firm that has not, cannot. 

04 – Over the life of a matter

When the matter keeps changing

Everything above is a snapshot: freeze the matter, build the context, ask the questions. That is where most benchmarks stop, but that is not the reality of most legal matters. Documents arrive, get revised, get superseded, and a context layer has to be built and then kept. 

The first consequence is that the Context Value Ratio is better understood as a curve than as a single number. Context is built once per matter; the value it returns accrues once per question asked or task performed. A matter that closes quickly, or that a legal team never has cause to interrogate, will not repay the investment however well the context was engineered. As the number of questions rises, the build cost amortized across them falls toward zero and the ratio approaches the answering-only figure reported above. The key question is therefore the break-even agentic volume: the number of questions answered by agents per matter at which the fully-loaded ratio — build cost together with answering cost — reaches 1.0. It is worth isolating because it converts a question a firm cannot answer, is context engineering worth it, into one it can: how heavily do we work a matter? 

Three variables set the break-even agentic volume. The first is the cost of building the context layer, driven by the choice of model and by the volume of text processed. We deliberately do not publish our own figure: across our ten matters it varied roughly sixfold on identical settings, because what moves it is the documents rather than any decision of ours, and a single number carried from our corpus to another firm’s would be misleading. This is the one input a firm must measure for itself. The second is the saving per question, which is what the benchmark measures. 

The third property warrants closer examination: variations in the techniques used to build the context layer in the first place. Some context engineering approaches, for example, derive their value from a structure that is computed in such a way that every new document added or changed invalidates what was already built and the cost recurs each time a filing lands. Other approaches attach to individual documents, so a new document adds work proportional to itself and leaves everything already built untouched. On day one these context engineering tactics can look identical and cost the same; over the life of a matter receiving documents weekly they diverge sharply. A ratio measured on a frozen corpus flatters the rebuilding design, so a firm should establish which kind it is investing in before comparing headline numbers. 

There is a fourth consideration that the two-tier result above brings into focus. The build cost and the answering cost do not have to be paid at the same model tier. Constructing a document-level index is a bounded, mechanical task — read one document, describe what is in it and where — and it is often well within the capability of an economical model. Answering a legal question across a matter is often not. A firm can therefore build its context layer with an economical model and spend the resulting savings on a far more capable model at question time. 

That asymmetry has a large effect on break-even agentic volume, because the saving per question scales with the price of the model used by the answering agent while the build cost does not. 

Note that the current version of the Legal Context Engineering Benchmark does not measure change over time, but we already have started testing expansions to the benchmark that factor in sets of matters that unfold in stages, every document carrying its real-world date. We expect to report on this data set separately in the months ahead. In the meantime, the general point holds: a context layer is not something built once but rather cultivated over time to optimise for what a law firm or legal department values. 

05 – The invitation

Why we are publishing the method

What we described in this report is not only the internal benchmark that guides the evolution of NetDocuments’ Legal Context Graph but also the methodology that underpins that benchmark — a methodology that we hope any legal department or law firm can leverage to assess investment in the context layer. 

To apply this methodology simply follow the steps outlined.

1. Hold constant your model and your harness.
2. Write down the types of questions your professionals actually ask, and have someone qualified specify what a complete answer contains.
3. Change one context engineering technique or capability at a time.
4. Price a correct answer before and after.
5. And read some of the answers yourself before believing any of the numbers.
6. Where budget permits, run the comparison at more than one model tier — it is the cheapest way to learn whether what you have built is a crutch or an accelerant.