Review contracts against a customer-specific ruleset — traffic-light red/yellow/green per clause with reasoning, first-pass review in minutes, lawyer attention on the red cases.
In short: Review contracts against a customer-specific ruleset — output is a traffic light per clause with reasoning. Stack: Claude for clause analysis and structured output, a customer-specific rule DSL for the scoring rules, Azure Document Intelligence for OCR when the original only comes as a scan. Anti-hype: the agent does first-pass review, not legally binding assessment — the latter stays with a qualified lawyer or fiduciary. The leverage sits in stable rulesets with substantial contract volume; for rare, highly individual contracts manual review remains the more honest path.
Contract reviews tie up expensive legal time for recurring clause checks. A property manager with 200 rental contracts a year needs the same check 200 times: minimum lease duration, indexation clause, termination rule, rental deposit cap under OR Article 257e (the Swiss rental deposit cap, capping deposits at three months' rent). An insurance broker reviews reinsurance contracts against standard clauses. A fiduciary reviews supplier contracts for clients. In all three cases the work is 80% pattern matching against a defined ruleset and 20% genuine legal judgement.
If the ruleset is stable, the pattern matching is calibratable — i.e. automatable, but with an approval gate. The bottleneck is not the individual review but the aggregation: reading 50 pages of contract to find the three problematic clauses is inefficient attention allocation. That's exactly the bottleneck a contract review agent addresses. What it does not replace: legal assessment in the individual case, the weighing of industry context, responsibility for the recommendation. Those stay with the human — the agent only shifts where that human spends their time.
The pipeline is linear and traceable at every stage. The incoming contract (PDF, scan, Word export) first runs through Azure Document Intelligence in the Switzerland region, if OCR is needed at all — for native PDFs with a text layer this step is skipped. In stage two, the agent segments the contract text into clauses and classifies each clause against a clause-type catalogue (minimum lease duration, indexation, termination, deposit, liability waiver, etc.). Classification happens with Claude and structured output — no free-text answers, just a clearly defined JSON schema per clause.
Stage three is rule matching against a customer-specific rule DSL: each clause type points to one or more ruleset entries that formally describe what counts as green, yellow or red. Example: deposit.max_months_rent <= 3 is green, 3 < deposit.max_months_rent <= 4 is yellow with a reference to OR Article 257e, anything above is red. Stage four is the LLM scoring per clause — the agent checks the concrete clause text against the matching ruleset entry and returns a traffic-light colour plus reasoning. Stage five is the traffic-light report: a document with the original contract, every clause colour-coded with a reasoning comment, plus a summary of the red and yellow points at the top.
Important: the agent does not decide finally. On legally novel or ambiguous clauses it explicitly escalates to "uncertain" instead of setting "green" — the human reviewer sees those cases prominently in the report. The output is therefore: attention brought forward in time and prioritised, not a finished legal opinion.
A Swiss property manager — composite, not a real client — with around 200 incoming rental contracts per year and its own ruleset for red clauses. Examples from the ruleset: rental deposit > 3 months' rent is not permitted under OR Article 257e (red); certain indexation clauses referencing the consumer price index are permitted only under conditions (yellow with note); termination notice periods under three months for residential property are not permitted (red). The incoming contracts are a mix of the manager's own standard templates and individually negotiated contracts with institutional tenants. Before the agent, a lawyer read every contract — typically 45 to 90 minutes per contract. After rollout, the agent delivers the traffic-light report in under two minutes; the lawyer only looks at the red or yellow clauses in detail. On a standard rental contract with three yellow points she's through in ten minutes; on a complex special contract with eight red points she knows immediately where to focus.
Typical effect: first-pass review in minutes instead of hours; lawyers only examine the red traffic-light clauses in detail. Yellow clauses get a quick scan — the agent's reasoning is usually enough for a fast decision. Green ones are spot-checked rather than read in detail. Important: the agent does first-pass review, not legally binding assessment — the latter stays with the human, and that's not just a legal but an ethical line. Directionally: substantial time saved on recurring contract types, simultaneously sharper attention on the real risks. How strong the effect is depends on ruleset stability, contract volume and clause standardisation; published benchmarks are rare here because rulesets are customer-specific.
No. The agent does a first-pass review — pattern matching against a defined ruleset. The legal assessment stays with the qualified lawyer or fiduciary. The advantage: the human only sees the red clauses in detail, instead of reading 50 pages to find the three problematic ones. On legally novel or ambiguous clauses the agent escalates automatically ("uncertain" instead of "green"), and those cases are prominently marked in the report. The output is therefore not a finished legal opinion but attention brought forward in time and prioritised — the lawyer still makes the legal assessment, but on the cases where experience really counts.
Typically: a lawyer, fiduciary or compliance officer at the customer who carries the professional responsibility. We maintain the DSL structure (how rules are formally written — clause types, operators, thresholds), the customer maintains the content (what the rule actually says). For smaller rulesets (<30 rules) a joint onboarding and occasional updates are enough. For larger rulesets (>100 rules) a joint review per quarter makes sense — new court decisions, new contract topics, new risks get folded in. Important: the ruleset is the customer's property and is versioned; every traffic-light report references the ruleset version used for the scoring.
If a clause doesn't match any ruleset entry, the agent classifies it as "unclear" and puts it in the yellow bucket with an explicit note. The reviewer sees the original text plus the nearest-matching ruleset entry (if any) and decides: is this a variant of a known clause — then the rule gets extended — or a genuine special case that needs manual assessment. Over time the ruleset becomes more complete; with good structure and consistent maintenance, after 6 to 12 months typically under 5% of clauses are still "unclear". That's a directional empirical pattern, not a promise — how quickly the ruleset matures depends heavily on maintenance discipline and contract variability.
This use case sits in the AI Engineering practice and connects to neighboring knowledge and document use cases.
Practice: LLM applications in production — RAG architectures, document intelligence, evaluation, guardrails, platform choice.
Employees chat with the HR handbook, IT policies and contract templates — answers with citations, sensitive topics escalate.
Invoices, contracts and forms structured into your ERP — OCR plus LLM, post-extraction validation, review queue for the uncertain cases.
Contract review automation pays back when the ruleset is stable and contract volume is substantial. For rare, highly individual contracts, manual review remains the more honest path. In a non-binding 30-minute discovery call we'll talk through whether your contract types and ruleset justify building an agent.
Book a discovery call