What makes AI contract review expensive, and what controls the cost?

The expensive shape is the obvious one: read every clause against every playbook term. With a hundred-odd terms and a long agreement that is a multiplication, and it is what a first build does. What controls the cost is routing — deciding cheaply which specialist needs to read what, before any expensive model runs.

Why does the naive design cost so much?

Because it multiplies.

A playbook is not one rule. Parsed properly, a real corporate playbook becomes something in the range of eighty to a hundred and fifty enriched terms — your position, your fallback, your red line, per topic. A master agreement is not one clause either.

Check every term against every clause and the work is the product of the two, not the sum. Every one of those checks is a model call. The bill scales with the multiplication, the latency scales with it, and so does the failure surface, because each call is another thing that can time out.

This is why contract review demos are cheap and contract review deployments are not. A demo runs one agreement.

What does the published work say?

Harvey has published its own rebuild of playbook review as a multi-agent system, and it is worth reading. The architecture it describes is an orchestrator managing parallel subagents, each reviewing individual playbook rules, with a branching and versioning mechanism so subagents working at once do not collide on the same document.

They publish measured outcomes too: risk classification improved by 18%, redline quality by 34%, with latency rising from 2.6 to 3.8 minutes. They describe prompt caching, streaming partial results, selecting models per task, concurrency limits, custom timeouts and targeted retries.

That is a serious piece of engineering writing and most of the category publishes nothing like it.

What does the published work leave out?

The operational half. Checked against that article directly, it does not cover infrastructure or deployment topology, message queues or job scheduling, cost per request or per contract in money terms, retry strategy beyond the sentence "we added concurrency limits and exponential backoffs to avoid overwhelming shared model infrastructure", or rollout and production observability.

That is not a criticism. A vendor publishing its own unit economics is rare for good commercial reasons, and an architecture post is not an operations post.

But it means a buyer reading the best available public writing on this subject still cannot answer the question their finance team will ask, which is what one contract costs to review and what makes that number move.

So what actually moves the number?

Three things, in order of leverage.

Routing, which is the big one. Before anything expensive runs, decide cheaply what needs to be read. In our own build, twelve category-scoring agents read the contract at once and route what they find to eleven specialist analysts. The scoring pass is cheap; the specialists are not, and most of them never run on any given agreement. Routing cut model calls by 75% against the read-everything-with-everything baseline.

Say that plainly: the cost lever is not a cheaper model. It is not calling the expensive one.

Determinism, wherever it will hold. Parsing the playbook is a parsing problem, not a reasoning problem. Your playbook is usually an Excel file. Turning it into eighty to a hundred and fifty enriched terms is deterministic and spends zero model calls. Every step you can move from inference to code is a step whose cost is fixed and whose output does not vary between runs.

Retrieval instead of reading. The contract is indexed and retrieved against the terms rather than streamed whole into every check. Retrieval decides what a specialist sees. Get that wrong and you pay twice — once for the tokens, once for the wrong answer.

Where does the cost go when it goes wrong?

Three places, and none of them appear in a demo.

Retries on long documents. A review is not one call. It is hundreds across several stages, so a provider hiccup lands mid-document. Whether the work already done survives that is an architectural decision, and if it does not, the retry pays for everything twice.

Re-review. If nothing records what was already agreed, the same agreement gets read again next quarter. That is not a model cost problem; it is a system-of-record problem, and it is the one most likely to be invisible in a per-call bill.

Escalation set by confidence score. Escalating on a middling score fills the human queue with items nobody needed to see. The reviewer time is the expensive resource in the whole system, and a bad escalation rule spends it faster than any model.

What should you ask a vendor?

Four questions, none of which need a benchmark to answer.

1. What runs before the expensive model runs? If the answer is nothing, you are buying the multiplication.
2. What proportion of the playbook terms actually invoke a specialist on a typical agreement? Routing either narrows it or it does not.
3. What happens to completed work when a provider fails mid-document?
4. What is the escalation rule? If the answer is a confidence threshold, ask what else it considers.

A vendor who has done the engineering can answer all four from memory. A vendor who has done a demo cannot.

What does this have to do with the ERP?

The cost argument and the ERP argument are the same argument seen from two ends.

Reading the agreement tells you what was promised. It does not tell you what your system recorded. Business Central carries real fields for the things a contract decides — the vendor contract documentation names Cancellation possible until and Term until among the fields on a subscription line — and nothing in the ERP checks them against the document they came from.

Review that ends at the document is a cost with no compounding return. Review that writes its findings where the business already operates is the same spend with somewhere to land.

Sources

• Rebuilding playbook review as a multi-agent system — Harvey · fetched 2026-09-14
• Vendor subscription contracts — Business Central, Microsoft Learn · ms.date 2026-05-04