Legora’s AI Legal Push: Build One Contract Review Queue

By Lazar Milicevic · Published October 29, 2026 · 8 min read

A supplier agreement lands in your inbox. Someone downloads it, hunts for the right project folder, wonders whether it's the latest version, pings a reviewer, and chases a reply a week later. A summary from a chat window removes one of those steps. The rest of the queue is still sitting there.

OpenAI published a customer story on October 28, 2026 about Legora, a legal AI company. Read it for the structure, not the pricing. The useful part is how the work is organized around a process.

What the Legora story actually says (and what it doesn't)

OpenAI's story, Legora is building the agentic operating system for legal work, lists the products as API, Codex and ChatGPT. It describes a mid-market company based in Stockholm, founded in 2023. Legora's own legal team built a playbook from the NDAs it had historically signed, and it uses that playbook to take a first pass at incoming NDAs and flag terms outside acceptable parameters.

The headline numbers, all company-reported:

• The General Counsel estimates NDA review used to take about 20% of the legal team's capacity and now takes under 1%. OpenAI summarizes that as a 95%+ reduction.
• Legora's CEO cites one Fortune 100 customer that cut contract turnaround by 90%, saved more than $20 million on external litigation and diligence, and gained 9.5 hours per lawyer per week.
• Tabular Review can analyze thousands of contracts across multiple questions in minutes.

Treat these as vendor claims. They come from one internal team and one unnamed customer, and I found no independent audit. The story names the products API, Codex and ChatGPT, but I haven't seen it name a specific model behind the NDA workflow, so don't read the results as a statement about any particular model.

The story also doesn't give a cost per contract or an independently verified accuracy rate, and it isn't a deployment recipe. The connection to email-driven approvals at a small business is mine, and I'll label it as such. Legora itself is built for law firms and in-house legal teams, and it uses a consumption-based pricing model. I'm not suggesting you buy it. I'm suggesting you borrow the shape of the idea.

The word that matters is "operating"

Legora launched what it calls the Legora aOS on May 7, 2026, described as a single connected system for the flow of information, communication and execution of legal work, from matter intake through to client delivery.

The CEO's framing of the problem, from a funding letter, is the part that transfers to any small business: playbooks and sign-offs live in people's heads and across too many disconnected tools, so every piece of work depends on someone coordinating it by hand.

That sentence describes a five-person company as accurately as a law firm. Your contract terms live in one person's memory. Gmail doesn't talk to the CRM. The CRM doesn't talk to the document folder. The approval happens in a chat thread nobody can find in March.

If you're already losing two to four hours a day to email, invoicing, lead follow-up and reporting, another isolated chat window becomes one more place to check. You tried ChatGPT and it didn't integrate with anything. Hiring someone to shuttle information between tools is expensive, and off-the-shelf software rarely matches how your business actually handles agreements.

The distinction worth keeping: a summary answers a question. A queue moves work. Legora's pitch is the second thing.

The approval boundary is the design

Legora states its own boundary: the Agent handles execution and the lawyer makes the calls that matter. The Legora Agent is described as planning, executing, reviewing and delivering work, and pausing where human judgment is required. OpenAI's story says the same about M&A diligence: agents surface information across the deal set while lawyers review and interpret.

Copy that boundary before you copy anything else. For a small business, it translates to three rules:

1. The system never approves. It drafts, extracts, flags and routes. A named human decides.
2. Uncertainty stays visible. A missing date produces a question, not a guess. An ambiguous passage stays marked ambiguous.
3. A new version resets approval. A revised agreement gets a fresh review. It never inherits the sign-off from the older file.

These rules matter because mistakes have different costs. A wrong extracted date that gets silently "fixed" by the model is worse than a visible "not found," because the reviewer will trust the packet.

The workflow I would prototype

This is a proposed implementation, not a claim about Legora's internals. One dedicated review queue, one document type (supplier agreements), one reviewer role.

The pipeline:

1. A supplier agreement arrives and enters the queue.
2. The system preserves the original file untouched and creates a record: source, arrival time, document version.
3. An LLM drafts a review packet: parties named, dates it can locate, relevant passages, and questions for the reviewer. Each extracted detail points back to the passage it came from.
4. The system creates a task, assigns the reviewer, and sends a link.
5. A human checks the packet and decides what happens next.

Step 4 is the handoff the summary-only approach skips: document received, packet drafted, owner assigned.

Here's a minimal record schema for step 2. Plain structured storage is enough; a database table, a spreadsheet, or JSON files in a folder all work for a prototype.

# review_record.yaml
doc_id: "SUP-0007"
original_file: "originals/acme-supply-agreement-v2.pdf"  # never modified
source: "email: procurement@acme.example"
received_at: "2026-10-29T09:14:00Z"
version: 2
supersedes: "SUP-0004"          # triggers fresh review, approval not inherited
status: "awaiting_review"       # received | packet_drafted | awaiting_review | decided
reviewer: "dana"
decision: null                  # only a human sets this

And the packet the model fills in, with evidence attached to every field:

# review_packet.yaml
parties:
  - value: "Acme Components Ltd."
    evidence: "p.1, preamble: 'between Acme Components Ltd. and ...'"
dates:
  - label: "effective date"
    value: "not found"
    evidence: null
  - label: "term end"
    value: "2027-12-31"
    evidence: "p.4, §6.1: 'This Agreement expires on December 31, 2027.'"
open_questions:
  - "Effective date not found. Is it on a signature page we weren't given?"
  - "§9 liability language is unclear on who bears shipping loss."

The field that does the most work is evidence. If the model can't point to text, the field says "not found." A reviewer can verify a quote in seconds; they can't verify a vibe.

Keep extraction separate from interpretation

The instruction that makes this safe is simple: when a detail cannot be found, return "not found." Don't infer, don't assume a standard value, don't fill the gap with something plausible.

Here's a prompt skeleton that enforces it:

EXTRACTION_PROMPT = """
You are extracting facts from a supplier agreement. You are NOT reviewing it.

Return JSON with these fields only:
- parties: list of {value, evidence}
- dates: list of {label, value, evidence}
- open_questions: list of strings

Rules:
1. `evidence` must be an exact quote from the document with its page/section.
2. If a field cannot be located, set value to "not found" and evidence to null.
3. Do not infer dates, parties, or terms that are not written in the text.
4. Do not say whether the agreement is acceptable. Do not recommend signing.
5. If a passage is ambiguous, add it to open_questions. Do not resolve it.
"""

Rule 4 is the approval boundary written into the prompt. Rule 5 keeps uncertainty visible. Neither replaces the human check; they make that check cheaper.

If you later want playbook-style flagging, the way Legora's legal team compares incoming NDAs against terms they've historically accepted, keep it as a second, separate pass. Build the playbook from agreements you've actually signed, and have it output "outside your usual terms: yes/no, here's the clause," never "approved." Extraction first, comparison second, decision always human.

Test it on five documents before you connect anything

Don't wire up your inbox yet. Start narrow.

1. Pick five agreements you're authorized to process with the tools you plan to test.
2. Include one revised version of an earlier document and one with missing information (a missing effective date, a missing signature page).
3. Run all five through the identical process.
4. Check every extracted field against the source. Record each correction.
5. Time the whole thing: packet generation, your corrections, and the reviewer's read.

What you're looking for is not "did it get most fields right." You're looking for whether the workflow exposes uncertainty or quietly fills the gaps. The missing-information document is the real test. If the model returns a confident effective date that isn't in the file, your prompt or your tooling isn't ready.

Only after that, connect the output to a task queue. Start with the narrowest useful automation: draft creation and reviewer notification. Then measure total handling time, including corrections and review. Faster generation helps only if the complete job gets easier.

Five documents are an initial check, not proof of production reliability. Don't extrapolate from them, and don't borrow Legora's 95% figure as your expectation. That number came from a legal team's own NDA playbook, built on its own historical agreements, and it's a vendor-reported estimate.

Where the plumbing comes in

I'm a senior engineer who builds AI automations that connect the everyday tools a small team already uses, such as email, document storage and task tracking. In a workflow like this one, the model call is the smallest part. Most of the effort goes into the handoffs between those tools, which is where small teams actually lose the time. If you want to talk through how this could look for your own paperwork, the starting point is bizflowai.io.

My take

The valuable idea in Legora's direction is organizing work around a specialized process, not just pointing a model at a document. The model matters, but so do the document version, the reviewer, and the approval record. Legora is building that for lawyers, with a company-reported record behind it that I can't independently verify. Your version is smaller: one queue, one document type, one boundary where the machine stops and a person decides.

Build a system where every document has a known status and every decision has an owner. That's a result you can inspect, and you can inspect it this week with five files.

Want more like this?

I write about practical AI automation and building systems that actually ship.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn: Lazar Milicevic, senior engineer building AI automations.

Visit bizflowai.io for more on practical AI automation for solopreneurs and small teams.