Czar
Building Legal AI Agents: Contract Analysis on Czar for Top-Tier Law Firms
Why contract analysis at a top-tier firm is a training and evaluation problem before it is a deployment problem, and what that means for building the agent on infrastructure that never sees privileged material leave the room.
· 8 min read
A top-tier firm's contract corpus is, functionally, the firm. Decades of negotiated positions, fallback language, client-specific carve-outs, and the institutional memory of which clause killed which deal all sit in redlines and executed agreements that are privileged, often subject to outside counsel guidelines that name specific handling requirements, and in many matters covered by protective orders that make "we sent it to a third-party API" a sanctions conversation rather than an IT decision. That combination is why contract analysis has become one of the clearest cases for sealed, on-premises AI infrastructure rather than a wrapper around a hosted model. The problem is not that hosted models are bad at reading contracts. It's that the corpus needed to make an agent good at reading this firm's contracts is the one asset the firm cannot let leave the building to get there.
The agent has to learn the firm's contracts, not contract law in general
A general-purpose model can summarize an indemnification clause reasonably well out of the box. What it cannot do out of the box is know that this particular firm's real estate group always flags a specific limitation-of- liability structure as a fallback position, or that a given client's playbook treats a certain change-of-control trigger as a hard no regardless of what the counterparty's boilerplate says. That knowledge lives in the firm's own history of redlines, matter notes, and precedent language, exactly the material that cannot be shipped to a cloud provider for fine-tuning without also shipping privilege and, in matters under protective order, without potentially violating the order itself.
That's what makes this a training problem before it's a deployment problem. An agent that only reads new contracts through a stock model is a moderately useful clause-extraction tool. An agent that has actually absorbed the firm's own playbooks, fallback ladders, and historical redline patterns is a different kind of asset, closer to a very well-read junior associate who has seen every deal the practice group has done. Getting from the first to the second requires fine-tuning or retrieval grounded in privileged material, which means the training environment itself has to satisfy the same confidentiality obligations as the underlying documents. This is precisely the workload Czar is built for: fine-tuning and R&D on sensitive data that cannot touch cloud infrastructure, with the corpus, compute, and resulting model held inside one sealed enclosure rather than scattered across a vendor's training pipeline, logging stack, and API gateway.
What "contract analysis agent" actually has to do
Framed as an engineering target rather than a product pitch, a useful contract agent for a sophisticated practice needs to do several distinct things well, and they don't share a single technique.
It needs clause identification and extraction: finding and labeling the indemnification, limitation of liability, termination, assignment, and governing law provisions across a document that may not use the firm's preferred headings at all. It needs deviation detection: comparing incoming language against the firm's own precedent language or a client's playbook and surfacing where a counterparty's draft diverges, not just that it differs but roughly how much risk the divergence represents. It needs cross-document consistency checks: comparing a definitions section against how a term is actually used four schedules later, the kind of drift that is tedious for a human reviewer and mechanically well-suited to a model with the whole document in context. And it needs redline drafting: proposing fallback language pulled from the firm's own approved alternatives rather than generating novel legal language from first principles, which matters both for quality and for keeping the agent's output inside the bounds of positions the firm has actually taken before.
None of these are single-shot text generation tasks. They're closer to an agentic workflow: retrieve relevant precedent, compare against it, flag what's out of tolerance, draft within approved bounds, and hand a structured result to the reviewing attorney rather than a wall of prose. That retrieval step is where Substrate's memory and retrieval layer does the real work underneath the model. It's what lets the agent ground a judgment in the firm's actual playbook document rather than in whatever the base model absorbed from public contract templates during pretraining.
Why privilege makes this an infrastructure decision, not a prompting decision
It's tempting to treat confidentiality here as a policy problem solvable with a vendor's data-processing addendum and a promise not to train on inputs. For a firm handling matters under outside counsel guidelines or active protective orders, that framing usually doesn't hold up. Those guidelines and orders frequently specify where data may reside and who may access it, in terms that a shared multi-tenant cloud service, however well those data-processing terms read, cannot satisfy on its face. A contractual promise about training data is a different guarantee than the material never leaving a controlled environment at all, and general counsel at a firm handling matters at this level tend to draw that distinction sharply, because they are the ones who have to answer for it if a client or a court asks.
That's the practical case for running the whole pipeline, ingestion, retrieval, fine-tuning, inference, and the agent's working memory of in-progress matters, on hardware that sits inside the firm's own facility and never establishes an outbound connection to a model provider. It removes the question of whether a given clause, matter, or client name crossed a boundary it wasn't supposed to cross, because architecturally there is no boundary to cross. The corpus stays where the privilege already lives.
Evaluation without exfiltrating the evidence
A recurring shortcut in agent development is grading a draft output by sending it to a stronger hosted model and asking for a quality score. For a legal contract agent working from privileged material, that shortcut is the exfiltration path itself, whatever it's labeled as in the architecture diagram. The workable alternative is slower and more honest: review by practicing attorneys against held-out redline sets, rubric-based scoring that runs entirely on local compute, and a growing internal benchmark built from the firm's own past deviation calls. Did the agent flag the same clauses a senior associate would have flagged, propose fallback language consistent with positions the firm has actually taken? That benchmark becomes an asset in its own right over time, and like the training corpus it feeds on, it has to stay inside the same sealed environment rather than being assembled with the help of an outside grading service.
Where this leaves the build
None of this argues that a contract analysis agent is a bigger model problem. It argues that it's an infrastructure and data-governance problem wearing a model-shaped front end. The differentiation between a mediocre contract tool and one that reasons like the firm's own best associates comes from fine-tuning and retrieval grounded in decades of privileged work product, and that grounding is only available to build at all if the training and inference environment can hold that work product without ever needing to ask permission to move it. Czar is the tier in the Element 31 line built around exactly that requirement: a sealed appliance for training, fine-tuning, and R&D on sensitive data, with compute and corpus provisioned together before it ever reaches the firm's floor. Forge serves a different purpose in the lineup, an air-gapped coding copilot for engineering teams rather than a training platform, and Chassis is a separate arrangement again, hardware built to one ISV's specific deal rather than a firm's internal deployment. All three sit on Substrate, the shared platform underneath them. For a firm whose real competitive asset is the judgment embedded in its own contract history, that asset never has to leave the building to become useful to an agent. It only has to be trained where it already lives.