On 8 October 2026 Uber's engineering blog described how it built the Legal Redlining Agent (LRA), an AI assistant for its legal team. When a counterparty edits a contract (a "redline"), the agent suggests whether to accept, reject or modify each edit, writes a comment explaining Uber's position, and flags risk. A lawyer reviews every suggestion and decides.
First, what the post does not say. It gives only two results: an over 20% reduction in average contract review time, and 91% accuracy in AI-generated decisions. It does not say how the 91% was measured: what it was compared against, or on how many cases. This article separates what the post lets us confirm about the architecture from how to read those numbers.
What Uber handed to the AI
The starting point is volume. The post says thousands of contracts are negotiated at Uber every year, and calls the process "time-consuming, repetitive, and often a bottleneck for deals, onboarding, and launches."
The agent lives in Microsoft Word as an add-in. The post calls building it as a Word add-in, rather than a standalone web app, a critical design decision. It is meant to work without replacing a lawyer's judgement: it finds the counterparty's edits, reads their intent, recommends accept, reject or modify based on policy, drafts a comment stating Uber's position, and flags risk on clauses that need a closer look. Learning from lawyers' past decisions is also listed as a feature.
Timeline: the post says work began in early 2024, with a pilot in the legal team in 2025. It also says that on 9 March 2026 the agent was part of Uber Legal's winning submission for Most Innovative Legal Department of the Year at the ALM Legalweek Leaders in Tech Law Awards.
Architecture confirmed in the post (five parts and one flow)
- ▸The Word add-in (front end): built with React and TypeScript, running as a task pane beside the document. It reads the counterparty's tracked changes through the Office JavaScript API and applies or highlights edits
- ▸The Python back end: handles all the AI operations. When a lawyer starts an analysis, a LangGraph workflow runs, and independent steps such as intent detection run in parallel
- ▸The memory layer (OpenSearch): vector search retrieves the relevant rules and past feedback, using nomic-embed-text-v15 embeddings
- ▸The rules engine: non-negotiable policies are handled by a deterministic rules engine (one that gives the same result every time), not by the model's guess
- ▸Session memory (Redis): keeps conversation state so lawyers can ask follow-up questions. Model calls go through Uber's internal GenAI Gateway
- ▸1. Read: when a lawyer starts an analysis, the back end receives the counterparty's edits. Independent steps such as intent detection run in parallel, for both speed and accuracy
- ▸2. Look up: non-negotiable policies go to the rules engine. For parts open to negotiation, past lawyer decisions are retrieved as examples: a similarity search with metadata filtering narrows the pool to about 20 documents, and an AI step then filters for whether they fit the intent
- ▸3. Draft: when the decision is "modify", the agent refers to past feedback and rules to refine the clause. The post says simple generative text often hallucinates terms or drifts from a contract's defined terms
- ▸4. Adjust tone: a tone step sits at the end of the pipeline. The post's figure description mentions GPT 5.2 for tone adjustment (the text names no model for the other steps)
- ▸5. Decide: a lawyer reviews each suggestion, chooses accept, reject or modify, and it goes into the final response. The decision, edit and reasoning accumulate as material for step 2
What did not work first, and what changed
- ▸The first approach retrieved from the internal playbook (RAG). The post lists poor semantic matching, an inappropriate tone, and no way to handle situations the playbook did not cover
- ▸So Uber started storing lawyers' decisions. It records the decision, the expected action, the comments and the final modified text, and weights recent decisions more using exponential decay (a half-life that is currently 365 days and configurable). The post says the feedback store now holds thousands of previous interactions
- ▸Tone swung both ways: sometimes overly defensive and adversarial, other times inappropriately accommodating. The fix was a three-part tone prompt (objective, style, conversation starters) where engineers manage the structure and in-house lawyers write the content
- ▸For modified wording, an agentic step was added. Drafting counter-proposals from past feedback and rules reduced invented terms, according to the post
- ▸Rules are registered by lawyers against template text. They pick important or frequently modified text in a template document and attach a rule to it
Watching quality, and what was hard
- ▸Quality monitoring: the team runs continuous LLM-as-a-judge evaluations of the retrieved context. The post names two metrics: document quality (document_quality_metric) and whether the model follows company rules (rule_adherence_metric)
- ▸Problems with Word: the Office JavaScript API is slow and needs optimising in the app. The tracked-changes API has edge cases that crash on certain document structures. Deleted text in tracked changes comes back as an empty string, so the app has to keep its own copy of the text
- ▸Documents change every round, so similarity search is still needed: relying on a stored source sentence alone would stop matching as the document is revised
How to read the numbers (our view)
- ▸"Over 20% reduction" is in average contract review time. The post presents it as the change since launch with the legal team. It does not say what period it was compared with, or which kinds of contracts
- ▸"91%" is an accuracy figure with no stated method. Because we do not know how many cases were compared with what (a lawyer's final decision, for instance), do not read it as "lawyers used 91% of suggestions as they were"
- ▸"About 20" and "365 days" are settings of this system. They are not presented as right values for every company (the post says 365 days is configurable)
- ▸"Thousands" is the size of the feedback store. It is not a measure of results
What we could not confirm
- ▸How the 91% was measured, and what the 20% was compared with. The post does not say
- ▸The full model line-up. GPT 5.2 appears only in a figure description. The text does not say which model runs intent detection, filtering or drafting
- ▸How often lawyers accepted a suggestion as it was. The post gives no number
- ▸Fine operating detail. We did not inspect the images in the post, only the text and figure descriptions
- ▸Which contracts it covers. The post does not say which contract types it is used on or whether it has spread company-wide
What to take from this case (our view)
- ▸Split the work instead of handing it all to AI. Fixed policy goes to a deterministic rule; only the parts that call for judgement use past human decisions as material. Splitting by what each part does well carries over to other work
- ▸Design in where a person decides. A lawyer reviews each suggestion, and the legal team writes the content of the tone prompt. The line is that AI output is not sent out as it is
- ▸The first approach not working is written down openly. A playbook search alone was not enough, and that record saves the next team time
- ▸Read numbers together with their definition. A figure like 91%, given without a method, is safer not to copy as a target for your own team