What “it depends” is hiding
How operational chaos masquerades as legal complexity, and what happens when you separate the two, by Lorna Khemraz
Two kinds of uncertainty
Ask a lawyer how long it takes to review a software vendor’s standard terms. “It depends.” Ask what determines turnaround on a commercial services agreement, a data processing addendum, a supplier contract. The same answer. “It depends” is so well-worn in legal that it functions less as an answer and more as a way of closing the question without engaging with it. A reasonable person might interpret this as evasion. I think that is partly right, but the more interesting explanation is that the phrase is doing two different things at once, and the legal profession has not always been honest about the distinction.
Legal work is genuinely contextual. A liability cap that is perfectly standard in a £200K software contract becomes a real negotiation point in a transaction worth five times that.
One version of “it depends” is completely defensible. Legal work is genuinely contextual. A liability cap that is perfectly standard in a £200K software contract becomes a real negotiation point in a transaction worth five times that. An indemnification clause that works in a services context can look completely different in a manufacturing environment where defective component liability is catastrophic. Governing law matters differently depending on where a company’s operational exposure actually sits. None of that complexity is manufactured. Experienced lawyers develop a sensitivity to which variables change the answer, and that sensitivity takes years to build.
But there is a second version of “it depends” that accounts for more of its usage than most people in legal would openly acknowledge. This version is really saying something more like: “I cannot give you a reliable estimate because the work arrives in conditions that make it impossible to separate the genuine decision points from everything else that needs to be resolved before I can reach them.” That is a different kind of uncertainty, and it points at a different kind of problem.
The conditions of the work
Consider what actually happens when a software vendor’s standard terms arrive in the queue. Procurement sends an email: “can we sign this?” Four attachments. The main agreement. A supplemental terms document. An order form the vendor has already partially filled in. And a PDF printout of the email thread between procurement and the vendor’s sales rep, which someone has attached in case it is useful but which mostly contains meeting confirmations. The main agreement cross-references a Data Processing Exhibit as Exhibit B. Exhibit B in the actual document is a Security Policy. The Data Processing Exhibit is not attached. The vendor has also sent what they describe as their terms “with the concessions we’ve already agreed,” but they produced this by accepting and rejecting changes from a previous negotiating version, so the tracked changes are partially resolved and it is genuinely difficult to establish what the document’s current positions actually are. Page nine has a paragraph in a different font and a narrower margin, lifted from another template. The indemnification clause says “as further specified in Schedule 1.” Schedule 1 is a pricing table.
The lawyer who says “it depends” about turnaround is not always hedging about the legal analysis. They are accurately reporting that the conditions of inbound work are unpredictable in ways they cannot control.
None of that is a judgment call. None of it requires legal expertise. It is formatting problems, version confusion, and missing context. But it has to be resolved before the actual review can begin, and collectively it can turn a twenty-minute review into an hour of preparatory work. The lawyer who says “it depends” about turnaround is not always hedging about the legal analysis. They are accurately reporting that the conditions of inbound work are unpredictable in ways they cannot control.
Redlines are their own category of operational problem. When a counterparty sends back marked-up paper, the markup is rarely clean. Changes from a previous negotiating round get partially accepted, then another layer of changes goes on top. Comments and tracked changes are used inconsistently, so it is not always obvious whether a given annotation represents a firm position or a question. A redline will occasionally delete a clause that was never part of the original document, which means someone either sent the wrong base version or made a mistake in the markup. Figuring out what the counterparty is actually proposing, before evaluating whether it is acceptable, is itself a non-trivial task.
I find this is the thing that rarely gets said clearly in conversations about what makes legal work hard to automate. The assumption has been that the difficulty sits in the legal reasoning, and that everything else is mechanical. The evidence from actual deployments suggests this has the difficulty in the wrong place. Language models are now genuinely capable of legal reasoning on well-structured problems. The harder challenge, the one that breaks naive automation, is dealing with work that arrives in variable and inconsistent conditions.
Most of what looks like judgment is pattern-matching
Stripped of operational noise, the legal judgment layer on routine work is smaller than it appears. Most of what a lawyer does in a standard contract review is check whether the document’s positions fall within a set of known parameters. Does the liability cap meet the minimum? Does the governing law clause conflict with the team’s standard position? Are there unusual representations that the playbook does not cover? These are comparisons against explicit or implicit standards. Once the standards are written down, most of the comparison is deterministic.
The “most” matters here. There is genuine residual. Novel contract structures that the playbook has not anticipated. Counterparty behaviour that suggests an approach the standard fallbacks were not designed for. Industry-specific risk allocations that require genuine legal reasoning rather than lookup. These are real, they require experienced judgment, and they cannot be encoded away. But they are a smaller fraction of the daily workload than the surrounding operational chaos makes them appear.
A figure that has come up in conversations with in-house teams is roughly this: about half of inbound requests are categorised without much ambiguity once someone actually reads them, and the other half requires more thought. That 50/50 ratio sounds high for the “uncertain” side until you disaggregate what “uncertain” actually means. Some of it is genuine legal complexity. A lot of it is incomplete information, where the request says “please review” without specifying the commercial context, the counterparty’s threshold, or the deadline. That is not uncertain because the law is unclear. It is uncertain because the lawyer does not yet have what they need to apply the law they already know.
What agents are actually doing
An agent configured with a well-built playbook handles the pattern-matching layer without much trouble, because the playbook makes explicit what was previously implicit. “Standard fallback on liability cap is 12 months’ fees. Below 6 months, reject and counter. Below 3 months, escalate.” Once that is written down, the check is deterministic. The agent compares the document against the position, flags anything outside the bounds, and routes genuine exceptions for human review.
The comms layer of the agent, the part that manages the back-and-forth with the person who sent the original request, is doing as much work in many cases as the legal reasoning engine itself.
The operational irregularity requires a different design response. The right behaviour when the Data Processing Exhibit is missing is not to silently skip the relevant review or make assumptions about its contents. It is to ask for it, specifically. The right response to a redline layered on top of another redline is to extract the current net position of the document before applying the playbook, not to run the analysis on an input that is ambiguous. The comms layer of the agent, the part that manages the back-and-forth with the person who sent the original request, is doing as much work in many cases as the legal reasoning engine itself. And it needs to be designed accordingly: targeted clarification questions rather than generic disclaimers, structured responses rather than walls of caveat.
The objection handling task type is worth dwelling on because it illustrates the operational complexity most clearly. When a counterparty sends redlines on first-party paper, the agent has to first establish the net state of the document, then compare each proposed change against the playbook, then decide whether to accept, reject with a counter, layer a further redline on top, or flag for the supervising lawyer. The three rejection modes, reject and comment, redline over redline, and comment only, correspond to different negotiating contexts and different levels of complexity in the resulting document. Getting this right requires handling the formatting and version issues first, then applying the legal logic. The legal logic is the easier part.
What reaches the lawyer
What this produces, when it is working well, is a supervision queue that is qualitatively different from an inbox. The lawyer opens it and finds a curated set of genuine decision points: the cases where the playbook did not resolve cleanly, the counterparty positions outside standard parameters, the requests where confidence was low enough to warrant human review. The formatting problems have been dealt with. The missing context has been requested and, in most cases, supplied. The version confusion has been resolved.
The lawyer’s time becomes almost entirely “it depends” cases in the defensible sense: situations where context genuinely matters and judgment actually makes a difference. And even those cases arrive better organised than they would from a raw inbox. The relevant playbook sections are surfaced. Non-standard clauses are identified. The comparison against known positions is already drawn. The decision is still the lawyer’s. The cognitive work of reaching the decision is substantially lower.
The distinction legal professionals rarely make explicit, between judgment that is genuinely contextual and uncertainty that is operationally manufactured, is the one that matters most for understanding where agents actually help.
I think this is more interesting than the throughput argument, useful as that argument is. The claim is not just that agents make legal teams faster. It is that agents change the composition of what reaches the lawyer. The genuinely irregular work, the work that actually uses the expertise these people have spent years building, becomes a larger proportion of what they do. The operational chaos that has been masquerading as legal complexity, inflating “it depends” far beyond its honest scope, gets resolved separately, earlier in the process.
The distinction legal professionals rarely make explicit, between judgment that is genuinely contextual and uncertainty that is operationally manufactured, is the one that matters most for understanding where agents actually help. The former requires lawyers. The latter has been consuming their time at significant scale, for reasons that have more to do with how work arrives than with how hard the work itself is. Fixing that is not a small thing.
📌 Further reading
A 'Seat at the Table' for Law Departments Isn't Enough Anymore (Above the Law) — Stephanie Corey, who founded CLOC, makes the argument I find most aligned with this post: that influence gets legal into the conversation, but operational discipline determines whether the department can deliver once it is there. Her observation that "routine work slows down because every matter feels unique" is exactly the dynamic I am describing. The lawyers are capable. The judgment is there. The infrastructure underneath is what breaks.
The Intake: how agentic AI is shaping legal services — A blog focused on agentic AI education and thought leadership.
Legal AI is splitting in two, and most people miss the difference (Fortune) — Written by someone at Thomson Reuters, so read it with that in mind, but the "authoritative AI vs operational AI" framing is genuinely useful. The work I discuss in this post sits firmly on the operational side: executing contracts, processing requests, routing work. The authoritative layer, case law, regulatory research, jurisdiction-specific guidance, is a different problem with different economics.
McKinsey's CEO on 25,000 AI agents (Business Insider) — Not legal-specific, but I think this is the single most important data point about where professional services are heading. McKinsey went from a few thousand to 25,000 agents in eighteen months, and Sternfels expects parity with their 40,000 human employees by end of year. The pattern he describes, agents handling the operational and analytical work while humans focus on client relationships and strategic judgment, maps directly onto the distinction I am drawing between operational chaos and genuine legal complexity.
The AI Legal Divide: Why Three-Quarters of Legal Teams Are Racing to Catch Up (Axiom) — Axiom's survey of 600+ senior legal leaders found that only 21% of organisations have achieved what they call AI maturity, with two thirds still stuck in proof-of-concept. The gap between teams that have moved past pilot and those that have not is widening quickly, and the report makes a persuasive case that it is becoming a competitive issue rather than a technology preference.