Uber's Legal Redlining Agent: How AI Cuts Contract Review Time by 20% in Word

Overview

Uber's Legal Redlining Agent (LRA) is an AI system that assists lawyers in reviewing contract redlines — tracked changes from counterparties — directly inside Microsoft Word. Instead of a standalone tool that uploads contracts and returns reports, LRA operates as a Word add-in that reads each redline, identifies the affected clause, and proposes an action (accept, reject, or modify) with a risk level and a draft response for the counterparty. Lawyers review each suggestion, edit if needed, and confirm before the response becomes part of the official contract reply.

Uber disclosed the system's development in October 2026. The first generation began in early 2024 and entered internal legal team trials in 2025. Uber negotiates thousands of contracts per year; a typical enterprise contract scenario averages five rounds, each taking 2–10 hours of lawyer time. After deployment, Uber reported an average contract review time reduction of over 20% and an AI decision accuracy of 91%. The article notes that the methodology behind these numbers (sample size, accuracy definition, baseline, evaluation period) was not disclosed, so they should be treated as internal metrics rather than generalizable legal AI benchmarks.

One Redline Flow

When a redline appears in Word, LRA reads the revision from the side panel, locates the clause being modified, and runs a parallel analysis: it identifies the counterparty's intent, assesses legal risk, retrieves applicable company rules and historical handling records, then produces a recommendation. If modification is advised, the system also drafts an alternative clause and generates a review comment for the counterparty. The lawyer decides to adopt, reject, or rewrite the suggestion; only the confirmed version enters the formal contract response.

Contract negotiation is not a simple classification task with a single correct answer. The same clause may be handled differently depending on client, region, deal size, and negotiation stage. LRA handles the repeatable, retrievable, and generatable portions; final judgment remains with the responsible lawyer.

Time savings come not only from the accept/reject decision. Uber emphasizes that lawyers need a draft counter-proposal text they can continue editing — involving contract definitions, obligations, and exceptions — and an explanation suitable for sending to the counterparty that matches the team's negotiation style. Delivering both is what moved LRA into the real workflow.

Four Iterations (Four Failures)

Uber divides the first-generation LRA build into four major iterations. Following these iterations reveals why each component exists.

1. RAG Hits a Wall

The initial approach was straightforward: legal provided a negotiation playbook and historical examples; the system retrieved semantically relevant snippets and fed them to an LLM along with the counterparty's edit to make a decision. Three problems emerged quickly:

Query–knowledge asymmetry: Early flow first identified counterparty intent, then searched the playbook. The query expressed the purpose of the edit, while the playbook stored policy statements and historical examples. Semantic search often mistook "looks similar" for "applicable to this negotiation."

Playbook coverage gaps: When no relevant playbook entry was found, the model still generated a complete answer, but it fell back on generic language ability rather than Uber's actual position. Uncovered scenarios produced near-random results.

Correct conclusion ≠ usable response: Tone is part of negotiation strategy. Overly defensive language stalls talks; overly accommodating language weakens position. A generic model cannot reproduce the team's nuanced tone from a playbook alone.

The problem was no longer just retrieval accuracy. The system had to disentangle what the counterparty wants to change, whether the company allows it, and how to respond this time.

2. Feedback Cannot Be Just a Thumbs-Down

Uber started recording lawyer feedback. Initially they saved only the lawyer's action (accept/reject/modify), the original text, the counterparty's edit, and a thumbs-down signal. This told the system "the suggestion was wrong" but not why.

The team later enriched each interaction record with:

Original clause
+ Counterparty redline
+ Counterparty intent
+ AI risk & decision
+ Lawyer final action
+ Final adopted text
+ Lawyer's rationale

Now the system remembers not just that an answer was wrong, but in what context the lawyer changed it to what.

At runtime, LRA queries a feedback index that has accumulated thousands of interactions. It first performs a metadata-filtered similarity search, narrowing to about 20 candidates , then passes those to an LLM for a second filtering round to verify that candidate cases truly match the current parties' intents. Only a handful of cases enter the context to assist decision and comment generation.

Relevant rules and historical feedback are also displayed in the suggestion UI. Lawyers see not only the system's conclusion but also which materials influenced it — a detail that determines whether lawyers trust AI-generated text enough to bring it into real negotiations.

Uber balances agree/disagree examples and applies exponential decay to historical feedback. The current half-life is set to 365 days , so newer handling records are more likely to appear in subsequent prompts. This does not label old cases as "wrong"; it reduces the probability of the system reusing outdated positions.

Uber calls this a self-learning mechanism, but the "learning" occurs mainly in retrieval results and few-shot context; there is no public record of continuous model fine-tuning. Lawyer edits do not automatically change model weights; they change what evidence the model sees on the next call.

3. Tone Handed to Lawyers

Even after adding feedback, tone issues persisted. Uber added a dedicated model call at the end of the pipeline to adjust the negotiation response. This node does not perform multi-step reflection. It assumes the draft may be too defensive or too accommodating and rewrites it according to legal-team-defined goals, style, and opening examples. Uber's rationale: directly assuming the draft has problems eliminates a "should we modify?" judgment step and avoids latency and token cost from loops. The exact contribution of this step was not separately quantified.

Prompt maintenance also changed: engineers maintain structure; lawyers directly maintain specific goals, expression style, and opening examples. Target tone is specified concretely: direct, first-person, no small talk. According to Uber, the legal team tuned outputs to match their habits within days.

Domain content that directly affects output is now maintained by the legal team. Engineering owns boundaries, format, and runtime quality; lawyers decide which expressions represent the team.

4. Clauses Must Be Production-Ready

Accepting or rejecting a redline only solves the judgment problem. The more time-consuming work is often writing an alternative clause that keeps the negotiation moving. Simple text generation fails here: models may invent terms not in the contract or deviate from already-defined concepts. The team reshaped the MODIFY path into an agent workflow: first reference historical feedback and rules, then generate a compromise clause, rather than letting the model rewrite freely without grounding.

This change made LRA deliver not just a judgment but a text segment lawyers can continue editing. Once a clause is model-generated, version relationships become critical: which contract version is being modified, which existing definitions are referenced, whether the generated text obeys matched rules, and which version becomes the final fact after lawyer edits. Uber did not elaborate on these implementation details, but they are unavoidable engineering boundaries when extending the public chain.

Architecture Division

LRA uses a thin-client model. The Word add-in (React + TypeScript) handles document interaction and user input; a Python backend orchestrates AI. When a lawyer triggers analysis, the backend uses LangGraph to run intent identification, risk assessment, and policy lookup in parallel. OpenSearch stores rules and historical feedback; Redis holds session state; Uber's GenAI Gateway handles model access.

The diagram below (reconstructed from Uber's public components and data flows) shows logical relationships only; exact node order and service boundaries were not disclosed.

┌──────────────── Microsoft Word ────────────────┐
│ React + TypeScript Add-in                       │
│ Read revisions, locate clauses, show suggestions, apply modifications │
└───────────────────┬────────────────────────────┘
                    │ Current document, redline, lawyer actions
                    ▼
┌──────────────── Python Backend ───────────────────┐
│                  LangGraph Workflow                │
│                                                    │
│  Intent Identification ─┐                          │
│  Risk Assessment      ─┼─> Decision: ACCEPT / REJECT / MODIFY  │
│  Policy Lookup        ─┘                          │
│                                                    │
│                                    ├─> Comment Generation   │
│                                    ├─> Clause Modification  │
│                                    └─> Tone Adjustment      │
└──────────────┬─────────────────────┬───────────┘
               │                     │
               ▼                     ▼
┌──────────── OpenSearch ───────┐   ┌── Redis ──┐
│ Rules Index                    │   │ Session   │
│ Feedback Index                 │   │ State     │
│ nomic-embed-text-v15           │   │ Follow-up │
└──────────────┬────────────────┘   └────────────┘
               │ Rules, historical cases, lawyer final texts & rationales
               └──────────────> Back to backend context

None of these components are unusual; the difference lies in what each stores. The model handles identification, judgment, and generation; LangGraph, backend, and Redis maintain flow and session; Word holds the current contract; OpenSearch holds rules and historical handling. Redis also supports lawyer follow-up questions around the current document.

The article references "AI Agent Core Architecture Explained" which discusses division among model, runtime, and business systems. LRA provides a concrete example: the real separation is not about service count but about who owns current facts, who advances the process, and who only supplies candidate judgments.

Word Is Not a Shell

Uber did not build a separate web portal; they embedded the product in the Word environment lawyers already use. The add-in (React + TypeScript) uses the Office JavaScript API to read revisions, apply modifications, and highlight the clause under review.

Placing the entry point in Word first eliminates copy-pasting between systems. More importantly, Word holds the current state of this task. Lawyers work on a specific contract, a specific version, a specific revision — not a decontextualized text snippet. The agent's suggestions must land precisely on the corresponding clause. Document position, revision author, deleted content, surrounding definitions, and current version all affect subsequent judgments.

The article references "How Agents Understand Business" which breaks business understanding into objects, state, rules, permissions, and actions. LRA grounds these: objects are contracts and clauses; state is current version and redlines; rule index stores company positions; lawyers retain final decision authority. The action only truly occurs when the modification is written back to Word. Missing any piece risks the system understanding the text but modifying the wrong contract.

At the engineering level, the Office JavaScript API introduced three concrete problems:

API round-trips are slow; the team uses caching to reduce Word interactions.

Revision API crashes on certain document structures; loading logic added exception handling.

Deleted text may return empty strings , forcing the add-in to maintain its own text state to correctly display diffs.

These issues are unrelated to model capability but directly affect trustworthiness. If the system misses a deleted obligation, even perfect backend retrieval and reasoning are reviewing an incomplete contract.

The thin client does not mean the frontend only displays. The add-in must manage Word document state and write-back actions; the backend handles expensive retrieval, judgment, and generation; both sides minimize round-trips.

Decomposition Enables Debugging

Uber uses LangGraph to orchestrate the backend, running intent identification, risk assessment, and policy lookup in parallel. Parallelism reduces latency, and graph decomposition breaks a single "contract review" into distinct questions. To pinpoint failures, these nodes can be further split. Uber did not publish corresponding failure fields; the third column in the table below is an engineering inference based on the public chain.

Intent Identification — Question: What rights does the counterparty want to add, what obligations to reduce? Typical failure: sees only textual changes, misses true intent.

Risk Assessment — Question: What impact does the change have on Uber? Typical failure: risk level disconnected from concrete legal consequences.

Policy Lookup — Question: Is there an explicit rule or acceptable concession? Typical failure: misses rules, or applies similar rule to wrong scenario.

Decision — Question: Accept, reject, or modify? Typical failure: correct evidence but wrong action choice.

Clause Modification — Question: How to form a negotiable text? Typical failure: introduces new definitions, alters original responsibility boundaries.

Comment Generation — Question: How to explain position to counterparty? Typical failure: vague reasoning, or exposes unnecessary internal judgment.

Tone Adjustment — Question: How to match team communication style? Typical failure: improves tone but inadvertently changes legal meaning.

If everything is stuffed into one prompt, the system may produce a plausible-looking answer but errors become hard to locate. Decomposing into nodes lets the team determine whether the problem lies in document reading, retrieval, decision, clause generation, or tone handling, and then adjust the corresponding data and evaluation.

This is also the difference between a contract agent and a general QA system. General QA allows the model to compose the final text directly; a contract system cares whether each step's evidence is traceable, whether generation actions are constrained, and whether the final text preserves the original legal stance.

Two Types of Evidence

LRA maintains two primary indices in OpenSearch.

Rule Index stores the company's legal policies, positions, acceptable concessions, and expected response examples. Lawyers can select frequently edited text in the original template and create rules for it. When a relevant redline is detected, the system performs semantic search on the modified sentence; high-confidence hits bring the rule into context and impose a hard constraint on model output. A final LLM check verifies that the result adheres to the matched rules.

Feedback Index stores historical negotiation records: context at the time, counterparty intent, AI analysis, lawyer's final action, actual adopted text, and rationale. Feedback mainly covers negotiable space, letting the system know how the team traded off in similar scenarios.

Both enter the model context via vector retrieval, but they cannot have the same authority.

Rules express the organization's currently maintained policies and bottom lines. When matched, they constrain or override free judgment.

Historical Feedback represents a real handling from a specific transaction. It provides similar experience but cannot automatically upgrade to policy.

Current Model Judgment infers intent, risk, and candidate text. It forms the suggestion but may still be corrected by rules and lawyers.

Lawyer Adjudication is the final call for the current contract. It determines the formal text and becomes new feedback.

Uber calls this a hybrid decision engine and describes the rule side as a deterministic rule engine. However, from the full chain, it is not a traditional decision table driven solely by precise conditions. Rule triggering still includes semantic vector search, and final adherence checking also uses an LLM. The determinism mainly comes from "rules have higher decision priority," not from every step escaping probabilistic models. Public materials contain no "80% pipeline, 20% agent" ratios, so workload or decision share cannot be inferred.

Template as Anchor

The retrieval system works because of a key business condition: negotiations usually start from the same source contract.

The system splits the contract by semicolons, periods, or line breaks. When a redline appears later, it can return to the corresponding sentence in the original template and use that original sentence to look up rules and historical feedback. When lawyers provide feedback, the system also uses that original sentence as the indexing anchor.

Thus query and index content come from the same source sentence, making vector representations more symmetric. Even after several rounds of modification, the original clause helps the system constrain the retrieval scope to nearby positions; semantic search absorbs minor wording variations.

The feedback index has another signal: counterparty intent. Uber vectorizes not only by original text but also by the counterparty's negotiation purpose. This finds cases where "wording differs but demand is the same."

The two retrieval keys each补 a shortcoming:

Original template sentence: answers "which part of the contract is at issue"

Counterparty negotiation intent: answers "what does the counterparty actually want to change"

Metadata filtering: answers "which customers, business lines, and contract scopes are comparable"

Retrieving only by original text misses same demands under different phrasing; retrieving only by abstract intent may mix cases from different clauses and business lines. Template anchor, intent vector, and metadata filtering together form the basic precision of this feedback retrieval.

Switching to free-format contracts, unfamiliar templates, or one-off deals removes the stable anchor of the original sentence, and retrieval difficulty rises significantly. Clause classification, document structure recovery, definition reference resolution, or legal ontology importance would increase accordingly. Uber lists ontology and knowledge graphs as future exploration, not as shipped capabilities in the first-generation LRA.

Time weighting solves only part of the problem. A 365-day half-life reduces the chance of old cases reappearing, but cannot judge whether a case remains applicable. Last week's concession might belong to a special deal; a year-old company policy might still be valid. If feedback lacks business line, region, contract template, customer type, policy version, and exception reason, the system only knows someone handled it that way once, not whether it can be reused this time. Uber did not fully disclose these fields. This is a problem derived from extending the current architecture: the system must not only remember a decision but also know under what conditions it becomes invalid.

Which Layer Is Wrong?

Uber reports 91% AI decision accuracy. The system also runs continuous LLM-as-a-judge evaluation, monitoring two metrics: retrieval context quality ( document_quality_metric) and model adherence to company rules ( rule_adherence_metric).

These two metrics explain the architecture's operation better than a single accuracy number.

A final decision error could stem from: rules not found, or found but not followed; counterparty intent misidentified; alternative clause introducing new obligations; or even a correct backend suggestion written back to the wrong position in Word. All manifest as "lawyer changed AI's suggestion," but the fixes are completely different.

Looking only at final accuracy, the team still wouldn't know which layer to fix. Following the actual chain and splitting it reveals fault locations more clearly:

Document Reading — Are redlines, deleted text, definitions, and current version complete?

Intent Identification — Did it identify the rights/obligations the counterparty truly wants to change?

Rule Retrieval — Were the rules that should have been hit found? Any false hits?

Feedback Retrieval — Do cases match current intent, clause position, and applicable scope?

Decision — Does accept/reject/modify align with current policy?

Clause Generation — Does it introduce non-existent definitions, amounts, obligations, or exceptions?

Tone Adjustment — Does it preserve legal stance while only changing expression?

Human Adjudication — Why did the lawyer keep, rewrite, or overturn the suggestion?

Document Write-back — Did the modification land on the target clause and target version?

Chip Huyen's "Agents" also observes systems by planning, tool execution, and efficiency failure modes. In contract review, overall accuracy suits trend-watching; deciding whether the next version should touch retrieval, rules, prompts, workflow, or Word integration still requires layered metrics.

Don't Mix Up the Chain

Once the full chain runs, the system continuously maintains three correspondence sets.

Contract and version: Which version's redline is read, which clause the lawyer is viewing, which version the final text writes back to.

Suggestion and evidence: Which rule the current suggestion hit, which historical cases it referenced, how the model went from intent and risk to accept/reject/modify.

Suggestion and adjudication: Which model suggestion the lawyer edited, why, and whether the final adopted text can be found in future similar scenarios.

Losing any one correspondence creates a subtle error: Word, retrieval, model, and feedback library all return success, but the assembled result is not the same contract, same rule, or same adjudication.

The article references "Output Result ≠ Task Completion" which distinguishes model output, tool return, action effect, and goal completion. In contract review, generating an alternative clause is only model output; writing it back to the correct contract and version, then having the lawyer confirm it as the formal reply, completes the task. The system must also record why this modification was allowed, which rule version and which historical handlings it relied on.

Human intervention is not just a confirm button at the end. After the lawyer edits, whether downstream nodes read the old text or the new text depends on whether the runtime saved the input version and intermediate state. Uber uses LangGraph and Redis but did not disclose concrete implementation of human pause, resume, and conflict handling. This remains architectural inference, not confirmed capability.

Looking back at the four iterations, LRA did not upgrade along buzzwords like "RAG, Agent, Multi-Agent." It simply separated mixed responsibilities step by step.

Playbook cannot represent real decisions → lawyer final texts and rationales enter feedback.

Historical experience cannot represent company bottom lines → rules and feedback are separated.

Engineers don't decide negotiation tone → tone content handed to legal team.

Model-generated alternative clauses cannot become contract directly → lawyers still rewrite and confirm.

LRA's results depend on repeatable contracts, stable templates, and continuous high-quality lawyer feedback. Uber did not publish the detailed methodology behind the 91% accuracy, nor did it prove that unfamiliar templates and brand-new deals achieve similar results. Claude Code, OpenCode, Skills, legal ontology, and knowledge graphs remain future explorations.

Returning to the full chain, LRA is a contract review system with clear division of labor: Word manages the current document, rule library manages company positions, feedback library stores past handlings, model provides candidate suggestions, lawyer decides what to adopt this time.

The model matters, of course. Whether the system can run long-term ultimately rests on three mundane things: contract versions don't get mixed, rules and historical cases don't get mixed, and the lawyer's final adopted text isn't lost.

References

Uber, Scaling AI in Legal: Building Uber's Redlining Agent (https://www.uber.com/us/en/blog/building-ubers-redlining-agent/)

Jon Udell / Simon Willison, Agent in the loop (https://simonwillison.net/2026/Jun/28/jon-udell/)

Chip Huyen, Agents (https://huyenchip.com/2025/01/07/agents.html)

Anthropic, Building effective agents (https://www.anthropic.com/research/building-effective-agents)

LangChain, Making it easier to build human-in-the-loop agents with interrupt (https://www.langchain.com/blog/making-it-easier-to-build-human-in-the-loop-agents-with-interrupt)