Legal Agents Inherit More from Coding Agents Than You Think
The talk frames Legora's work on legal agents as an inheritance pattern from coding agents. Here is my read on the framing. Coding gave the industry a playbook for agentic engineering because the feedback loop was fast and the ground truth was mechanical. Legal forces you to keep most of that playbook and rebuild the part that matters most, verification, from scratch. That swap is the whole story.
Three key takeaways
- Tool use, context staging, and runtime design carry over from coding agents to legal agents almost unchanged. Borrow them aggressively, because the engineering work has already been done.
- Verification is the part that needs a domain rebuild. There is no compiler, no test suite, no green checkmark. Verification in legal is a system of model passes, rule checks, citation validation, and structured human review.
- Human-in-the-loop is not a fallback. It is part of the product design, with queues, SLAs, and feedback loops, and it stays that way for the foreseeable future.
Coding gave us the playbook, but only for the easy half
Agentic engineering matured fast in coding because the domain was kind to it. A model writes code. The code compiles or it does not. The tests pass or they fail. The runtime behaves or it crashes. Every output has a deterministic check sitting one step downstream. That is what made coding agents the right place to figure out the rest of the stack: tool use, context windows, planning loops, retry behavior, human escalation.
What that playbook hides is that the deterministic check was doing most of the heavy lifting on quality. The agent could be wrong many times because the test suite would catch it. The model could produce ten variations because the compiler would reject nine. The system absorbed model error because the verification was free.
Legal does not have that free verification. A contract clause is correct or incorrect only relative to a body of law, a client's intent, and a counterparty's negotiating position. None of that is testable mechanically. So when you take the coding agent playbook into legal, the parts that survive are the parts that did not depend on the easy verification. The parts that break are the parts that did.
If you build agents in any non-coding domain, this is the lens that matters most. The playbook is real, but the parts of it that survive contact with your domain are smaller than they look. Spend your engineering effort accordingly.
What transfers without modification
Tool use is the first thing that ports cleanly. Coding agents taught the industry that giving the model access to a file system, a terminal, and a small set of well-scoped tools beats trying to cram everything into the prompt. Legal agents inherit this directly. Reading documents, searching precedent, querying contract repositories, calling out to research databases like Westlaw or similar systems, these are all tool calls. The engineering work of building, scoping, and testing tools transfers wholesale.
Context staging also ports. The lesson from coding was that context engineering beats prompt engineering: assemble the right files, the right snippets, the right history, before the model sees the question. In legal, the same logic applies. The model needs the right precedents, the right contract history, the right party positions, before it can answer. The mechanics are the same, even though the source material is dense legal text instead of code.
Runtime design ports too. The harness pattern, with a planning loop, a tool execution layer, a context manager, and a result formatter, holds up. The fact that the inner content is legal rather than code does not change the architecture. Teams that have shipped coding agents have most of the pieces they need to ship a legal agent, with the major exception of verification.
That is more transfer than most people expect. If you are building in legal or compliance or healthcare documentation, do not start from scratch. Start from a working coding agent runtime and replace the parts that need to be domain-specific.
What requires a rebuild
Verification is the part that has to be invented for the domain. There is no compiler that says a clause is correct. There is no test suite that catches a misstated precedent. The verification layer in a legal agent has to be built from scratch, and it is the place where most of the engineering effort ends up.
The patterns I have seen work are layered. First, a structural check: does the output cite real cases, real statutes, real clauses? A citation validator that looks up every reference against a known database catches a large fraction of model errors. Second, a consistency check: does the document contradict itself? Does it say something in clause five that undermines clause two? A second model pass focused only on internal consistency catches another layer. Third, a domain rule engine: are there hard constraints, like jurisdiction-specific requirements or mandatory clauses, that have to be present? Encode those as rules, run them, and refuse the output if they fail. Fourth, human review queues for anything that survived the first three but is still high-stakes.
The interesting part is that none of these checks is sufficient on its own. Each catches a different failure mode. The verification system is the composition, not any single layer. Teams that try to verify with one big model pass tend to fail because the model has the same blind spots as the model that produced the output. Teams that compose differentiated checks tend to succeed.
This is the place where the legal agent diverges most from the coding agent. It is also the place where the engineering work is hardest, slowest, and most valuable. Get this right and the rest of the product becomes possible. Get it wrong and the product is a liability.
Human review is the design, not the fallback
The temptation in agent design is to treat the human as a backstop. The agent does the work, the human catches mistakes when they leak through. In legal, that framing is wrong. The human is part of the system from the start.
What that looks like in practice is a review queue with structure. Every output has a confidence label. High-confidence outputs go to a sampling queue. Medium-confidence outputs go to a triage queue. Low-confidence outputs go directly to a human reviewer with the agent's reasoning attached, before being returned to the client. The reviewer's decision feeds back into the verification system, so the agent learns where its judgment was off.
This is a system, not an afterthought. It needs queues, SLAs, dashboards, and people whose job is to review. It is also the part of the product that compounds. Every reviewed case becomes training data for the next iteration of the agent, every rejection refines the verification rules, every accepted case calibrates the confidence model. The human review queue is the moat.
If you build agents in any high-stakes domain, design the review system before you design the agent. The cost of building it later is much higher than the cost of building it early, because the agent's behavior calcifies around whatever verification you initially shipped.
Context as the bottleneck
Long legal documents stress any context window. The relevant context for a single question often spans dozens of related agreements, regulatory filings, and prior decisions. The model cannot hold all of it at once, and naive truncation loses the most important parts.
The pattern that works is structured retrieval, layered. First pass, a coarse retrieval that surfaces the documents most likely to be relevant. Second pass, a fine retrieval inside those documents that surfaces the clauses and paragraphs that actually answer the question. Third pass, a deliberate context budget that decides which retrievals to include given the size limits, with the agent able to ask for more if the initial budget is insufficient.
Coding agents have a version of this with codebases, but the failure modes are different. In code, missing context usually shows up as a compilation error or a test failure. In legal, missing context shows up as an answer that is technically correct in isolation but wrong in the broader contractual or regulatory environment. The cost of context failure is higher because the failure is silent.
The engineering work is in making retrieval honest. The agent has to know when it does not have the right context, and refuse rather than guess. That is hard. It is also the difference between an agent that scales into production and one that ships warnings to the legal team every week.
Where this goes next
The first wave of value from agents came from coding, where the feedback loop was fast and the verification was free. The next wave is showing up in domains where the feedback loop is slower and the verification has to be built, but the dollar value per correct decision is much higher. Legal is one of those domains. Compliance is another. Healthcare documentation, regulatory filings, policy work, all of these follow the same pattern.
The teams that learn to translate the coding agent playbook into these domains will have a real edge. The translation is not free, but most of the architecture transfers. The hard part is verification, and verification is the place where domain expertise becomes a moat that other companies cannot copy quickly.
If you are choosing where to build, look for domains with high stakes, long documents, and no compiler. Then borrow the coding agent playbook, rebuild the verification layer for your domain, and design the human review system as a first-class part of the product. That is the recipe, and it works.
The agentic engineering job is shifting upward. The keyboard work is moving to the model. The judgment work, especially the design of verification, is becoming the bulk of what serious teams do. Legora's work is a marker of where that shift has already happened in one domain, and a useful reference for any team that is about to make the same shift in their own.
Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.
This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.
My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.
Source talk: What legal agents inherit from coding agents at Code with Claude London 2026. https://youtu.be/nho1YAEPuwA