Scaling AI in Legal: Building Uber's Redlining Agent

Products

AdvertisingLearn more about advertising on Uber. Reach consumers as they go anywhere and get anything.

Resources for driving and delivering with Uber

Experiences and information for people on the move

Ordering meals for delivery is just the beginning with Uber Eats

Putting stores within reach of a world of customers

Transforming the way companies move and feed their people

Moving care forward together with medical providers

Expanding the reach of public transportation

Doing the right thing for cities and communities globally

Product, how-to, and policy content—and more

Sr. Legal Director, Product Legal (Mobility & Platform)

The most durable lesson wasn’t about the model or architecture; it was about bringing an agent successfully into lawyers’ day-to-day work. We started from the business problem: a steady stream of contract negotiations involving substantial repeatable redline work. We met lawyers where they already work, inside Microsoft Word®, so LRA could flag risky redlines and suggest edits within their existing workflow. We then iterated closely with lawyers on what the agent should do, piloting it with our Legal team in 2025 and folding their feedback back into the product.

In this blog, we share what we learned bringing that first generation into practice: framing the problem, earning lawyers’ trust, and improving the agent through their feedback. We close with how the first-generation system worked and how we would approach the problem today as agent technology has evolved.

On March 9, 2026, LRA 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.

Figure 1: Legal Redlining Agent in action.

At Uber, thousands of contracts are negotiated every year. Behind each one is a legal team reviewing and negotiating these contracts. This process can be time-consuming, repetitive, and often a bottleneck for deals, onboarding, and launches. It’s high-stakes, detail-oriented work where precision matters and delays ripple across sales, onboarding, and launches.

Yet, buried inside this high-stakes process was something surprisingly structured: similar clauses, repeatable redlines across clients, and standing legal reasoning patterns. In other words, there was a clear system.

Since the legal organization’s work is mission-critical to Uber, we saw an opportunity to automate repeatable parts and free up lawyers’ time for complex judgment calls, all without sacrificing quality or consistency.

Figure 2: Contract review lifecycle and average support times for enterprise deals.

The Legal Redlining Agent is an AI-powered smart assistant integrated directly into Microsoft Word as an add-in, where lawyers already work. It reviews client edits, understands intent, recommends policy-aligned responses, generates structured comments, flags risks, and continuously learns from feedback.

Since launching with our Legal team, we’ve seen an over 20% reduction in average contract review time and 91% accuracy in AI-generated decisions. We’ve also received feedback like, “It saved me real time; especially with comment suggestions.”

The add-in analyzes a Microsoft Word document and identifies any redlines from external parties. Using AI, it then processes these changes, attempting to understand the client’s intent and the legal implications. It compares the proposed changes against our team’s legal policies and guidelines.

Based on this analysis, the add-in generates a series of suggestions, which includes recommended actions, proposed comments back to the client that justify these recommendations with legal reasoning, and an assessment of the risk level associated with each change. Uber lawyers then review each suggestion, deciding whether to accept, reject, or modify it before final incorporation into the client response.

Figure 3: High-level workflow of the Legal Redlining Add-in / Agent.

The system we just described didn’t emerge fully formed. Getting here required four major iterations, each teaching us hard lessons about what Legal AI actually requires.

Along the way, we used Uber’s GenAI Gateway, which allowed us to focus entirely on refining the product logic, working closely with subject matter experts.

Our initial approach to the problem focused on developing a foundational RAG (Retrieval Augmented Generation) system. The Legal team provided existing playbooks and examples of negotiation turns. Our hypothesis was that by ingesting these playbooks to identify semantically relevant sections, and then feeding these sections along with proposed counterparty changes to an LLM (Large Language Model), the system would generate sound decisions.

Figure 4: RAG (Retrieval Augmented Generation) flow.

Recognizing the limitations of a playbook-only approach, we understood the need for the agent to be more adaptable and to learn continuously from real-world interactions. This led to the development of a self-learning loop powered by direct lawyer feedback.

Initially, our feedback mechanism was simple: we saved the lawyer’s decision (accept/reject/modify), the original text, the redline, and a thumbs-down signal. This provided a basic error signal but lacked important nuances.

To deepen the system’s understanding, we evolved the feedback loop to capture the lawyer’s expected action and specific comments. When we introduced the ability for the AI to draft modifications, we further expanded this to collect the final modified text used by the lawyer. This granular data proved to be a turning point. It enabled us to map the counterparty’s intent directly to the lawyer’s precise, improved language. The agent started getting much more accurate, adapting to the team’s preferred style and negotiation postures.

We also started surfacing relevant past feedback and rules directly within the suggestion interface. This gave lawyers transparency into why a suggestion was generated, building trust and allowing them to see exactly what influenced the AI’s output.

At runtime, the agent queries this feedback store, which now contains thousands of previous interactions. The system first conducts a similarity search with metadata filtering, narrowing the pool to about 20 pertinent documents. These candidates are then passed through a second filtering layer using state-of-the-art LLMs to verify alignment with the user’s and counterparty’s intent. The agent then analyzes the most relevant examples to decide whether to accept or reject the proposed change and generates a comment for the counterparty.

We also implemented an exponential decay weighting algorithm to construct the context for future prompts. This mechanism prioritizes recent decisions, ensuring the agent adapts to shifting legal stances and mitigates concept drift, while maintaining a balanced distribution of agree and disagree examples. This dynamic, balanced few-shot prompting allows the redlining tool to learn user preferences and policy nuances in near-real-time without requiring manual model fine-tuning.

Addressing the persistent challenge of tone, we integrated an additional LLM call at the end of the processing pipeline specifically to modulate the output’s linguistic style. But we quickly discovered that getting tone right in legal negotiations is harder than it sounds.

Early outputs oscillated between two failure modes: sometimes overly defensive and adversarial; other times inappropriately accommodating and eager to please. Neither matched the measured, professional tone our lawyers use in actual negotiations.

The breakthrough came from a close collaboration with the in-house Legal team. Recognizing that tone is a critical component of legal communications, we empowered the lawyers to take direct ownership of the specific language defining the desired tone and conversational style. Our engineering team managed the anatomy, but the in-house Legal team managed the content of the three-part prompt anatomy.

Figure 7: A prompt anatomy that includes tone, style, and conversation starters.

Other techniques for reflection involve complex loops to achieve convergence on the desired behavior. We found that the presumption of bad quality doesn’t affect positive examples, but sufficiently corrects negative examples at a high reliability even with just one shot. We attribute this to the reduction in complexity, due to one less decision that the LLM needs to make in the single prompt. The lack of loops also limits ‌token usage and latency.

Figure 8: Using reflection to improve tone.

Finally, we provide a section for Uber’s in-house lawyers to give conversation starter sentences as few-shot examples.

Within days, they’d tuned it to match their voice precisely. This led to a crucial insight: prompts directly influencing output format should be crafted and managed by the application’s subject matter experts or end-users with AI teams guiding to ensure that prompting best practices are met.

Figure 9: Feedback and tone improvements influenced by subject matter experts.

While determining whether to accept or reject a change is valuable, the real time-saver for a lawyer is drafting the counter-proposal. Simple generative text often hallucinates terms or drifts from the contract’s defined terms.

To solve this, we moved beyond simple text generation to an agentic workflow. When a MODIFY decision is reached, we reference historical feedback and rules to refine the clause.

This allows the tool to help lawyers draft high-quality proposed compromise language that reflects prior legal guidance and incorporates the company’s broader risk position for each particular issue.

Lastly, we realized that lawyers frequently work with their own templates, which are often shared across teams. This insight presented two advantages:

To leverage these benefits, we developed a rules database for lawyers. This allows them to select important or frequently modified text within an original template document and associate a rule with it. A rule encapsulates Uber’s stance, any fallback positions, and an example of the desired application response. When the application detects a change, it performs a semantic vector search on the modified sentences against our rules index. If a rule matches with high confidence, it’s injected into the context window. To ensure strict adherence, a final LLM step is incorporated into the workflow to verify that the final output aligns precisely with the retrieved specifications.

Figure 10: How rules processing fits into the overall picture.

The architecture follows a thin-client pattern: the Word add-in handles document interaction and user input, while a Python back end orchestrates all AI operations. When a lawyer triggers an analysis, the back end runs a LangGraph™ workflow that parallelizes intent detection, risk assessment, and policy lookup. Vector stores (OpenSearch®) provide the memory layer, retrieving relevant rules and historical feedback to ground each decision.

A critical design decision was building the assistant as a Microsoft Word Add-in rather than a standalone web application. Lawyers live in Word, so asking them to copy-paste between tools would kill adoption.

The add-in is built on React and TypeScript, running as a task pane alongside the document. It communicates with Word through Microsoft Office’s® JavaScript API to read tracked changes, apply modifications, and highlight clauses under review.

This integration wasn’t without challenges. The Office JavaScript API has significant limitations that required creative workarounds:

These constraints shaped our architecture: a thin client that orchestrates Word operations carefully, paired with a back end that handles all the heavy AI lifting.

We optimized for both latency and accuracy by parallelizing independent graph nodes. For instance, while the Intention Node analyzes the counterparty’s meaningful intent, the Risk Level Node concurrently assesses the