News in Practice
Claude for Legal and Astra for Law: what these two offerings say about their own architecture
Two model makers enter the law four months apart. What they have in common fits into a single sentence, and it is that sentence which matters.
For law firms and legal departments weighing their options on artificial intelligence.
On May 12, 2026, Anthropic released Claude for Legal. On September 17, OpenAI announced Astra for Law. Both announcements drew wide comment, and the question they raise is not the one the trade press took up.
What was announced, precisely
Claude for Legal is an open source suite released under the Apache 2.0 licence. It brings together twelve practice-area extensions and more than twenty connectors to the software the market runs on: document management, data rooms, review platforms, research. Each extension starts with an interview that learns the team's practice before producing anything. The suite is free; what is paid for is the subscription to the model that runs it.
Astra for Law is a configuration of GPT-6 Astra for legal work, paired with a search index covering United States case law, statutes, regulations, court rules and administrative decisions across more than 230 million addresses. Access runs first through a programme reserved for selected firms, with the programming interface to follow. Twenty-six partner extensions accompany the launch.
Both offerings are serious, and the figures published by OpenAI show it: on the Vals AI Legal Research Bench, a set of 200 legal research questions in American law, Astra for Law returns 54% correct answers against 38.7% for the same model with web search alone. This is not an announcement effect.
What these offerings genuinely bring
Both offerings solve a real problem. A general-purpose model asked a question of law produces plausible answers and references that are not always so. Grounding the model on a verified corpus changes the nature of the exercise: the reference cited exists, it says what it is made to say, and the practitioner can check it.
The second contribution is integration. The Claude for Legal extensions plug into document management systems, signature tools and review platforms. The Astra for Law partners cover the same ground. In both cases the idea is the same: work where the matters already are, rather than requiring that they be moved.
The question of applicable law
The two offerings do not stand in the same place on this question, and the distinction is worth making.
The Astra for Law index covers the law of the United States. The offering is aimed first at the American market, and says so. Outside that jurisdiction, its main contribution, which is grounding on verified sources, does not apply to the law the practitioner works in.
Claude for Legal proceeds differently. The extensions are adaptable text files, with no jurisdiction written into their design, and access to sources runs through open connectors. Several cover laws other than American: one of them gives access to more than 31 million documents from more than 160 jurisdictions, including consolidated European Union law and the case law of supreme and constitutional courts.
Grounding on the sources of a given law is therefore not, in itself, what distinguishes these offerings from an orchestration layer. What distinguishes them lies elsewhere.
What a model maker cannot do
Claude for Legal runs on Anthropic's models. Astra for Law runs on OpenAI's. This is self-evident, but it has a consequence that is rarely measured: control of the output is entrusted to the model that produced it.
When one of these offerings checks an analysis, proposes a review or flags a weakness in a line of reasoning, it is the same family of models that drafts and that controls. The control shares the biases of the drafting, its blind spots, and its characteristic errors.
No maker has any reason to do otherwise: it would be building against its own product.
This constraint has a second, slower effect. Whoever builds their processes on one of these offerings ties the quality of their work to one provider's trajectory. If another model becomes better in six months, they will have to wait or rebuild.
Creation, challenge, control
MAX is not a model. It is a layer that governs several, and that puts every output through three distinct operations, entrusted to different systems.
Creation. A model drafts, from the matter, from positions already taken and from the terminology in use. This is the operation everyone knows, and the only one most tools perform.
Challenge. A second model, which did not draft, takes up the output and contests it. It looks for what the first did not see: the assumption made without being verified, the characterisation adopted without being discussed, the clause whose drafting opens a reading nobody intended. That model shares neither the first's training data, nor its biases, nor its blind spots. That is precisely why it sees something else.
Control. The output is confronted with the official sources of the law that applies to the request. Do the references cited exist, do they say what they are made to say, is the state of the text invoked the one that holds at the date in question. This operation is not a model's judgement but a verification against a source.
The applicable law is that of the request, not that of the provider. A question of French law is verified against French sources, a question of Italian law against Italian sources, a question of English law against its own.
The three operations are separated because they are not of the same nature. Creating calls for producing. Challenging calls for contradicting. Controlling calls for verifying. A system that conflates the three has one model perform a piece of work and its critique.
The four-eyes principle applied to models
This principle is known to everyone who works in a regulated sector. In banking, a commitment above a certain threshold requires two signatures. In audit, a partner's file is reviewed by another partner. In compliance, whoever raises an alert is not the one who closes it.
The reason is not mistrust. It is that a controller who shares the perspective of the controlled does not see what the latter has missed.
This principle has only rarely been carried over to artificial intelligence systems, and never as a principle of architecture, for a structural reason: it requires two models independent of one another, hence an architecture belonging to no maker.
That is what separates an orchestration layer from an offering built on a single model. The first can entrust creation and challenge to systems that do not resemble each other. The second, whatever the quality of its model, has an output reread by the one that wrote it.
The three questions to ask before choosing
Three questions arise before choosing, and none of them concerns the performance figures announced.
The first: against which sources is the output verified? An index of 230 million addresses is worth nothing if it does not contain the law you practise.
The second: who controls what has been produced? If it is the model that drafted it, the control shares its blind spots. That is the question the four-eyes principle raises, and it arises here as elsewhere.
The third: what happens when a better model arrives? The answer determines whether your equipment ages or improves.
These three questions are addressed to every provider, ourselves included. Whoever asks them gets a verifiable answer from each, or finds that they get none.