How to find the errors hiding behind correct answers, and what LexAgentHallu asks

The paper I want to walk through today is LexAgentHallu: A Hierarchical Benchmark for Profiling Hallucinations in Legal Agents, released as arXiv 2609.09754. Its claim can be put in one sentence, which is that hallucinations in legal agents cannot be seen from final answers alone and must be measured by where and how far they drift along multi-step trajectories. The original is linked under the title.

What interests me more is the direction of the question, because most legal AI evaluation asks whether the answer was right, while this work asks how it became right. From a systems perspective, the next question is obvious, and it stays with me: if a correct answer rests on broken grounds, should that answer be allowed into operation.

Why checking only the final answer can mislead you

Hello, this is Patrick. When people picture legal work, many imagine a single ruling document, yet real legal work rarely ends on one page, because someone has to find the relevant provisions, compare precedents, and organize the facts before any conclusion earns trust. Evaluation, oddly, is often simpler than that work, since it looks at the last sentence and stamps pass or fail.

So why is that kind of evaluation risky for legal agents. The reason is that an agent passes through several tools before it answers, so a small slip can enter at any joint. It calls a search tool, pulls citations, and stitches reasoning together, and each of those steps can introduce its own drift. But if the final sentence happens to resemble the right answer, the slip leaves no record, so it looks correct and we are fooled.

People learn in a similar way, which is why a good teacher asks to see the steps again when a student gets the right answer with the wrong working. A wrong method that happened to land on the right number can cause a much larger failure on the next problem, so the early luck does not stay harmless. Legal agents behave the same way, because if an agent misreads a provision but still reaches a similar conclusion, that misreading can produce a completely different conclusion in the next case.

This is where I would be careful not to over-read the scoreboard, since I think the more important result is not what was right but how much of it was right. This paper starts from exactly that worry. In law, that worry cuts deeper, because a correct conclusion built on wrong grounds can be more dangerous than an openly wrong one, since it invites trust it has not earned.

What earlier legal benchmarks could not see

The question itself has changed, whereas it used to sound like this: does the model know the law, does it remember the provisions, can it name the precedent. Evaluation therefore took the shape of single-turn QA, where a question came in, an answer came out, and the story ended there.

Agents changed that picture, though I want to state that plainly without dressing it up. An agent does not answer at once but starts work, since it searches, opens documents, calls tools, and builds intermediate conclusions as it moves. That motion cannot be caught by single-turn QA, because the final answer alone says nothing about what happened in the middle.

Here an interesting question appears, which is whether what earlier evaluation missed was really a lack of knowledge, or a problem in how the work was done. The diagnosis in this paper leans toward the second, because procedural failures exist on their own, including tool call and reasoning errors, and they tangle with substantive errors until they grow into fabricated holdings and miscited authority.

From an operations point of view, that difference is large. A model that lacks knowledge can be taught more, but an agent with shaky procedure can stumble in the same place even after more study, since misreading search results, swapping the call order, or skipping one line of reasoning is closer to a habit problem than a knowledge problem. I see that distinction as the first gift of this paper, because it tells us where to look when things break.

Why building 3,414 cases took four rounds of human review

So how can anyone build problems that measure such trajectories. The reported scale is 3,414 instances across 17 legal categories and 6 task types, which looks plain when listed as numbers, but the way they were made matters more. The authors built them through a four-stage pipeline with experts in the loop, so each case carries human judgment about where failure can live.

Why not generate them in bulk by machine. The reason is that plausible but wrong legal material is far too easy to produce, since a citation number that never existed can still read smoothly in a fluent sentence. If a benchmark filled up with clean-looking but hollow items, the benchmark itself would carry hallucinations. So human eyes had to enter several times, selecting and refining at each stage of construction.

I paused a little here, because a count of 3,414 does not look huge when benchmarks with tens of thousands of items are now common. Yet in a domain where wrong grounds lead to real harm, density can matter more than volume. When each case marks the location and kind of failure, a few thousand trajectories can say more than ten thousand right-or-wrong labels, much as a teacher learns more from a notebook full of worked steps than from an answer sheet.

The next issue follows naturally, since gathering many problems and classifying failures are different jobs. After collecting the cases, the authors needed a frame that sketches in advance where and how things can go wrong. That frame is the taxonomy we turn to next.

How seven broad types and twenty-seven subtypes fit together

The taxonomy in this paper has two layers, with seven broad categories on top and twenty-seven fine-grained subtypes below. Every instance carries labels from this frame, so the record says not merely that something failed but what failed and in what way, which changes how a team reads the result.

What I like about this structure is that it holds substantive errors and procedural failures together. A substantive error would be a wrong legal theory or a ground that does not exist, while a procedural failure would be a mistaken tool call or a break in reasoning. Earlier evaluation mostly watched the first kind, yet in the agent era the second kind often creates the first, because when retrieval brings back the wrong provision, the argument that follows can be smooth and still stand on sand.

Are seven categories many or few. I read them as comfortably wide, since too few would throw every failure into one basket, while too many would exhaust anyone trying to memorize the scheme. The seven broad branches show the whole terrain, while the twenty-seven leaves tell a team where to fix things on site, so they work like a map and a street address.

Still, this needs a careful reading, because a dense taxonomy does not mean every real failure fits neatly inside. Actual trajectories often show two or three subtypes overlapping. Even so, having the frame changes the conversation, since teams can stop saying it failed and start saying where it drifted. For an engineer, that one-word difference decides whether the next week is spent guessing or repairing.

When one tool call error turns into a fabricated holding

On the surface it looks simple, so it is tempting to ask why a single wrong tool call should shake the whole holding. In practice it is not that simple, because an agent run is linked like a chain, so when an early link bends, the later links harden in the bent shape.

Picture a concrete evening scene, where an agent takes on a lease dispute review. It should call a precedent search tool first, but the query drifts slightly, so an unrelated precedent comes back. Instead of doubting the material, the agent leans toward weaving the given material into an answer. In the next reasoning step, that wrong precedent becomes the premise for the legal analysis, and at the end a holding that never existed gets written in a confident sentence. What began as a small call error ends as a fabricated holding. (People outside law rarely memorize citation numbers, yet most of us know the uneasy feeling when the grounds feel hollow behind a smooth sentence.)

So where can such a chain be cut. The point this paper presses is clear, which is that the location of the failure must be marked. Fixing only the last sentence lets the same chain repeat in the next case, while knowing which tool call drifted lets a team fix the call pattern itself. The concrete links then become visible, such as query construction, citation checks, and reasoning joints.

When my team and I look at a new AI architecture, we do not look at benchmark numbers alone, but at what actually changed and what cost structure that change creates in a system. In the same spirit, chained failures in legal agents look closer to a plumbing problem than a score problem, since you have to find where the water leaks before you can repair it. That is why measuring along the trajectory matters here.

I stopped at the strange case of right answers with wrong reasons

What stayed with me was the report on cases that were right yet wrong, which the authors found while evaluating 18 proprietary and open-source agents. They describe it as a Right-Answer-Wrong-Reason effect, where correct outcomes masked flawed reasoning, so the scoreboard and the trajectory tell different stories.

Why does this matter. When evaluation looks only at outcomes, all these cases fall into the correct bin, so the model looks as if it performs well. But opening the trajectory shows hollow grounds, drifted citations, or skipped reasoning, which means it passes on the outside and fails on the inside.

How could anyone catch that in practice. The proposed way is fine-grained measurement along the path, which gauges the extent of the drift and pinpoints where along the run it happened. That removes the mask of the right answer, so agents that looked alike in an accuracy table start showing very different faces once trajectory measures are applied.

One misunderstanding should be cleared here, since this does not mean every right answer deserves suspicion. It means some right answers stand on firm grounds while others were lucky, and we should build that separation on purpose. That separation decides what can ship and what needs rework, and in law, where wrong grounds can turn into disputes, the separation itself becomes quality control.

Hallucinations gathered in clusters instead of scattering

So do these subtypes scatter in all directions. The observation reported here says the opposite, because hallucination subclasses cluster rather than scatter and form distinct groups. Some failures tend to appear together in certain tasks, while other failures gather under different conditions, which already hints at where to intervene.

Read quickly, this can sound abstract, yet from a systems view it gives a practical hint. If failures scattered at random, countermeasures would stay vague. But if failures gather, a team can aim at the gathering place, since knowing what kind often breaks where tells you where to put the guardrail.

Why do such gatherings form. Execution habits and task character shape the failures, because some tasks lean heavily on search, while others demand long reasoning. When the load-bearing point differs, the breaking point differs too. Profiles that stay invisible to outcome-level evaluation therefore appear once results are split by type.

I think the structure behind the number matters more than the number itself, since gathering means prediction becomes possible. When prediction is possible, preparation is possible, and when preparation is possible, operation is possible. For a team hoping to put a legal agent into real work, there are few findings more useful than that.

Why each framework and task leaves a different fingerprint

Pushing the earlier observation further, each agentic framework, legal task, and category shows its own profile. Under the single name of hallucination, one setup often shows a certain subtype while another setup highlights a different one, so the same label hides different habits.

This difference matters more than it seems, because when two agents earn the same score but break in different ways, the repairs must differ too. One may need cleaner tool calls, while the other may need stronger reasoning joints, much as giving the same medicine for different diagnoses rarely cures anything.

Can category differences be read the same way. The makeup of 17 legal categories points to the answer, since each category uses different shapes of grounds and different lengths of reasoning. One area demands tight provision matching, while another demands careful separation of fact patterns across precedents, so different terrain leaves different footprints.

A practical question follows for any team, which is whether you chose an evaluation suited to the task you actually plan to run. Trusting only a high overall score can lead you to pick an agent that is weak in exactly the subtype your task triggers most. Profiles by task and framework are therefore less of a luxury and more of a need, because knowing the sore spot before adoption and learning it after an incident differ greatly in operating cost.

Why measuring the path matters more than counting scores

It is time to return to measurement, where the paper introduces fine-grained metrics that quantify extent and localize each failure along the execution path. How does that differ from grading results. Grading stamps the last sentence, while trajectory measurement leaves marks along the road walked, so the two answer different questions.

To make the difference plain, picture a construction site. A finished building can look fine from outside, yet finding a pipe leak means opening the wall. Trajectory measurement opens that wall, since it shows at which step the grounds went hollow and where the citation drifted. For someone trying to fix things, a pipe map is worth more than a completion photo.

Is such measurement needed every time. For a simple QA item, outcome grading may be enough. But for an agent that calls tools many times and chains long reasoning, the story changes, because more steps mean more places to trip, and unknown tripping places guarantee a repeat fall in the same spot.

What I would watch next is how this measurement gets used, and whether it will stop at ranking models by score or grow into repair guidance that points at the fix. If it can show which subtype shrinks when a certain link is repaired, a benchmark turns from an exam sheet into a repair manual. This work takes one step in that direction, and I find that step worth following.

So what should we ask legal agents next

We return to the question set aside earlier, which is what should come next after seeing the trajectories. The paper leaves less of a leaderboard and more of a terrain map, showing which failures gather where, so future work will likely ask what to fix on top of that map.

So what is the human role. In law this question carries special weight, because when an agent offers wrong grounds in smooth prose, spotting the gap still depends heavily on human eyes. If building the benchmark itself needed four stages of expert involvement, live operation likely needs expert eyes at the final gate too.

Of course this study does not answer everything, since whether profiles seen across 18 agents will hold for other models and tasks remains to be watched, and whether frames of seven and twenty-seven keep their shape over time stays open. Law changes and tools change, so the shape of failure will change with them.

Still, one sentence remains clear, which is that when we ask about legal agents, we should move past whether they were right and ask how they became right. Once we learn to see the wrong reasons hiding behind right answers, our bar for adoption and operation changes. If I had to choose a legal agent again, I would ask for a trajectory map beside the score table. Without that map, trust is hard to grant.