ServicesWorkProcessBlogContactBook a call
← All postsMay 8, 2026 · case study · retrieval

Contract review inside the tenant: an agent that flags, never signs

The problem

A mid-market manufacturer's procurement team pushed every NDA, MSA, and vendor order through a two-person legal function. Turnaround was often two days, not because the contracts were hard but because they queued. The team had a written playbook for what "acceptable" looked like on each clause; applying it was manual every time.

The design principle

Two hard constraints set the shape. First, contract text never leaves the client's tenant — legal would not accept documents transiting a third party. Second, the agent flags and drafts; it never negotiates, never sends anything to a counterparty, and never approves. A lawyer reads every output.

Architecture

The system runs entirely in the client's cloud, with no data egress for document content.

  • A custom runtime in their account orchestrates each review.
  • Model routing. A local, OpenAI-compatible model runs the first pass over full contract text — clause extraction and red-flag detection — so the raw document stays in-tenant. Only a structured, de-identified summary of detected deviations goes to Claude through a gateway (prompt-only, no retention) to write the plain-language explanation and draft fallback language.
  • MCP servers for the contract-lifecycle-management system and an internal clause library of pre-approved and fallback wording.
  • OpenTelemetry tracing for every review: which clauses were extracted, which rules fired, which model saw what.

The playbook and the clause library

The client's playbook — position, acceptable range, and fallback for each clause type — was encoded as rules the first-pass model checks against. The clause library holds the wording legal has already blessed. When the agent proposes fallback language, it pulls from that library rather than inventing terms, and marks anything it had to compose.

What a review produces

For each contract: a list of deviations from the playbook, each with the offending text, the rule it breaks, a severity, and a suggested redline drawn from the clause library; a one-paragraph summary; and a recommended route — sign, negotiate, or escalate. It lands in the CLM system as a draft review attached to the record. A lawyer accepts, edits, or rejects it. Turnaround to a lawyer's desk went from about two days to about two hours; the lawyer's own review time dropped too, because the reading was already done.

Guardrails

The agent cannot change a contract, cannot alter its status in the CLM system beyond posting a draft review, and cannot contact a vendor. The local model is the only component that sees raw document text. Every review is a proposal with a trace. False flags ran about one in six at launch and came down as legal corrected the playbook rules — those corrections are the main way the system improved.

What it costs to run

Local-model inference on the client's own GPU capacity plus a small amount of gateway traffic for the summaries — well under a dollar per review in marginal cost. The return was throughput: the same two-person function cleared roughly three times the volume without growing.

How we rolled it out

We back-tested against about 200 contracts the team had already reviewed, and compared the agent's flags to what legal had actually caught — it surfaced about 94% of the known deviations. Then it went live in flag-only mode with counsel reading every output. The clause library and the playbook rules grew from their edits over the first quarter.

This is the kind of system we build

If a review queue is your bottleneck and the documents can't leave your network, this pattern fits. Book a call, or see Security & Guardrails.

Publishing note: a representative composite of in-tenant document-review work, not a single named client. Contract counts and catch rates are illustrative. Nothing here is legal advice.

Book a callMore posts