Agentic Contract Review Is Here: 3 Infrastructure Questions Before You Deploy

In July 2026, Spellbook announced early access to Autonomous Contract Management — an agentic AI system that connects directly to a firm's document management infrastructure, retrieves contracts without manual upload, and executes redline tasks across entire document sets without per-step attorney prompting. General availability is expected within months. For managing partners and CIOs who have spent the last two years watching vendors promise "AI transformation" while delivering glorified search boxes, ACM is worth paying attention to: it is the clearest public demonstration that agentic legal AI has moved from architecture diagrams into production workflows.

The relevant question is no longer whether agentic contract review works. Spellbook's announcement — combined with the broader trajectory of Harvey, CoCounsel, Lexis+ Protege, and Legora all racing toward autonomous multi-step workflows — makes that debate obsolete. The relevant question is what your firm actually controls when an AI agent reaches into your document management system, retrieves client files, and begins rewriting them. That question has three parts, and the answers should drive every evaluation conversation your firm has for the next eighteen months.

What Agentic Legal AI Actually Means in Production

The term "agentic" has been diluted by marketing to the point of near-uselessness, so it is worth being precise about what Spellbook's ACM architecture actually represents — because the architecture determines the risk profile.

A traditional AI contract review tool is essentially a stateless function: attorney uploads document, attorney submits prompt, model returns output. The attorney controls each step. The surface area for unintended data exposure or erroneous action is bounded by what the attorney manually submitted.

An agentic system is structurally different. It maintains persistent connections to document repositories. It makes autonomous retrieval decisions — determining which documents to pull and when. It chains multiple reasoning and execution steps without human checkpoints between them. It may write outputs back to systems of record. The attorney sets the objective; the agent determines the path.

Spellbook's ACM operationalizes this in the contract context: define a playbook or redline standard, point the agent at a matter folder or contract repository, and the system retrieves, analyzes, and redlines without the associate having to process each document in sequence. For a firm running 200 NDAs through standardization or managing a data room with 400 target company contracts in an M&A deal, the throughput difference is not incremental — it is categorical.

This is also what makes the infrastructure question non-trivial. When an agent is operating autonomously across a document corpus, the answers to "what did it access," "what did it transmit," and "who authorized that" need to be answerable by the firm, not just the vendor.

The Three Infrastructure Questions That Actually Matter

Question One: Where Does the Agentic Scaffolding Live?

The LLM is only one component of an agentic system, and arguably not the most sensitive one. The scaffolding — the orchestration layer that decides what to retrieve, how to chunk and embed documents, what tools to call, and in what sequence — is where the real architectural decisions live.

In most SaaS-delivered agentic systems, that scaffolding runs in the vendor's cloud. This means the vendor's infrastructure is making autonomous decisions about which of your client documents to access and process, even if the final LLM call goes to a model your attorneys recognize. The retrieval logic, the vector store containing embeddings of your full document corpus, the permission enforcement layer, and the action execution layer are all operating in an environment you do not control and cannot audit directly.

The practical consequence: if Spellbook's ACM, or any similar system, hosts the agentic scaffolding in their cloud, the firm's entire indexed document corpus exists in that environment. Not just the chunks transmitted to the LLM — the full embedded representation of every document the agent has ingested.

The architecture question to ask every vendor is not "where does the AI run" but "where does the agent run" — and specifically:

• Where are the document embeddings and vector indexes stored?
• Where does the retrieval and ranking logic execute?
• Where are permission decisions enforced?
• Where are agent action logs written and retained?

With private AI deployment on the firm's own infrastructure, these components run inside the firm's security perimeter. The agent scaffolding, the connectors to iManage or NetDocuments or SharePoint, the vector stores, the workflow orchestration — all of it sits on infrastructure the firm controls, audits, and can shut down unilaterally. What may leave that perimeter is a different and much smaller category: the minimal retrieved text chunks needed to answer a specific query, transmitted to a chosen LLM provider under the firm's own API agreement, not the vendor's.

That distinction — full corpus under firm control versus minimized chunks to the model — is the architectural difference that matters for privilege, confidentiality, and professional responsibility purposes.

Question Two: Who Controls the Retrieval Layer and What Gets Sent to the Model?

Retrieval-augmented generation is the mechanism behind virtually every production legal AI system that works reliably on firm documents. The system embeds documents into a vector store, retrieves semantically relevant chunks in response to a query, and sends those chunks — not the full document — to the LLM as context. This is why case search and contract review can be accurate on firm-specific content without fine-tuning the model itself.

In an agentic system, the retrieval layer becomes the critical control point because the agent is making retrieval decisions continuously and autonomously. Which chunks get retrieved determines what the model sees. What the model sees determines what actions the agent takes. The retrieval layer is effectively the agent's perception system — and whoever controls it controls what the agent knows and does.

For firms evaluating ACM or similar systems, the retrieval layer raises three specific questions:

1. What is the scope of document ingestion? Some systems ingest everything in a connected repository by default. Others require explicit matter-by-matter authorization. The difference between "the agent has access to your entire iManage instance" and "the agent has access to documents explicitly authorized for this matter" is not a minor configuration detail — it is the boundary between matter-specific AI assistance and something that looks a lot like an unsupervised data aggregation system sitting inside your DMS.

2. What exactly is transmitted to the LLM, and under what terms? This requires a straight answer from every vendor, and the honest answer for most systems — including RAGbase Legal — is that some text does leave the firm's infrastructure to reach the LLM. The question is whether that transmission is governed by the vendor's API terms with the model provider, or by the firm's own direct API relationship. A firm with its own Azure OpenAI or Anthropic agreement, routing minimal retrieved chunks under its own data processing terms, is in a materially different position than a firm whose document content transits through a vendor's model API relationship where data handling terms are set by and for the vendor.

3. Is the retrieval logic inspectable? If an agent retrieved a confidential settlement clause from a prior matter and included it in a draft sent to opposing counsel, can the firm reconstruct exactly what was retrieved, from which document, at what timestamp, and why? In a SaaS-hosted scaffolding model, that reconstruction depends on the vendor's logging practices and their willingness to produce records. In a firm-controlled deployment, that reconstruction is a SQL query or a log file the firm already owns.

Question Three: Are Permissions and Logs Yours, or Opaque Inside the Vendor Platform?

This is the question that most evaluation frameworks skip, and it is the one that will matter most when something goes wrong.

Agentic systems need to make permission decisions: can this agent access this document for this matter for this user at this time? In a well-architected firm-controlled deployment, those decisions are enforced by logic that integrates with the firm's existing identity and access management infrastructure — the same system that governs who can open a file in iManage. The permission model is auditable by firm IT without vendor involvement.

In a vendor-hosted agentic system, the permission layer is typically managed inside the vendor platform. This creates several practical problems:

• Ethical wall enforcement may not map correctly to the firm's matter-level restrictions unless explicitly configured and verified — and verification requires the vendor's cooperation
• Departed attorney access revocation requires coordination with the vendor, not just internal IT action
• Privilege log reconstruction for a document set processed autonomously by the agent requires the vendor to produce records the firm does not independently hold
• Regulatory audit response — increasingly relevant as state bars publish AI guidance and the ABA's formal opinions on competence evolve — may be delayed or incomplete if the firm cannot independently produce its own agent activity records

The logging requirement is not paranoia. It is basic professional responsibility infrastructure. Bar associations in multiple jurisdictions have issued guidance making clear that attorneys retain supervisory obligations over AI tools used in client matters. Supervision requires visibility. Visibility requires logs. Logs need to be the firm's, not the vendor's.

How the Market Is Responding — and Where the Gaps Are

Spellbook's ACM is not an isolated product launch. It is a leading indicator of where the entire enterprise legal AI market is moving over the next 12 to 24 months. Harvey has been building toward multi-step autonomous workflows. CoCounsel's integrations with iManage and other DMS platforms set up the same retrieval-and-act architecture. Lexis+ Protege is explicitly positioned as an autonomous legal research and drafting agent. Legora's collaborative agent model extends this into multi-attorney workflows.

The pattern is consistent: agentic capability is becoming the competitive baseline, not a premium differentiator. Within 18 months, firms will not be choosing between agentic and non-agentic AI for contract work. They will be choosing between agentic systems with different architectural profiles.

None of the SaaS column entries are necessarily disqualifying for every workload. For lower-sensitivity contract types — vendor agreements, routine NDAs, standard commercial terms — the risk profile may be acceptable and the deployment simplicity may justify the tradeoff. The problem is that most agentic systems do not make it easy to route different document sensitivity levels to different infrastructure configurations. Everything tends to go through the same pipeline.

For the matters that define AmLaw 200 practices — M&A data rooms, regulatory investigations, client-sensitive IP agreements, cross-border transactions with data localization requirements — the SaaS column's answers create real exposure.

What Firms Running Sovereignty-Critical Workloads Should Build Toward

The productive framing is not "avoid agentic AI" or even "avoid SaaS agentic AI universally." It is segmentation by sensitivity and infrastructure match.

Firms that get this right in the next 18 months will operate on a tiered model:

• Tier 1 (Routine, lower sensitivity): SaaS agentic tools for standard NDA processing, vendor agreement review, boilerplate standardization — where deployment speed and ease of use justify the architectural tradeoffs
• Tier 2 (Sensitive, client-specific): Firm-controlled agentic infrastructure for matters where client confidentiality expectations, bar obligations, or client contractual requirements demand that the full corpus and agent layer remain inside the firm's perimeter
• Tier 3 (Regulated and cross-border): Dedicated infrastructure configurations where data localization requirements, regulatory mandates, or client-specific security addenda govern exactly where each component of the agentic stack can operate

This is not a distant architecture aspiration. It is what private AI deployment for agentic workflows looks like in practice: the connectors, orchestration layer, vector stores, and permission enforcement running on firm infrastructure; the LLM call transmitting only the minimal retrieved context needed for the specific task, under the firm's own API terms with the model provider of their choice. For a deeper framework on building AI capability that scales across these tiers, the AI for law firms guide covers the full architecture decision set.

The firms that will struggle are those who evaluate agentic systems purely on output quality — redline accuracy, processing speed, playbook customization — without asking where the architecture sits. Output quality is increasingly comparable across the leading systems. The differentiating variable that compounds over time is who controls the infrastructure the agent runs on.

Spellbook's Autonomous Contract Management announcement is a useful forcing function for a conversation every firm's CIO and managing partner should be having now, before the GA release triggers a wave of vendor pilots and proof-of-concept pressure. The questions to bring into those conversations are not about features. They are about where the agent scaffolding runs, who controls the retrieval layer, and whether the permission and audit infrastructure is yours to own and produce independently. Firms that establish clear answers to those three questions before signing an agentic AI agreement will be in a fundamentally stronger position — operationally, professionally, and competitively — than firms that optimize for the fastest deployment path and audit the infrastructure questions later.