The Agent Updated 500 Contracts. Now What?
Enterprise AI agents can now read and write your files directly. The question nobody is asking: what happens after they do?
---
A client walked into our quarterly review with visible excitement.
They'd just rolled out an AI agent with direct access to their document management system — contracts, templates, compliance checklists. The agent had spent the weekend scanning 500+ master service agreement templates and updating the liability clause language to reflect a new regulatory requirement.
"It finished in four hours. Would have taken our legal ops team six weeks."
Our first question was not "how accurate was it?"
Our first question was: "After it finished, how do you audit what it changed?"
The room got quiet in a familiar way.
---
The question they thought we were asking
They thought we were asking about accuracy. Hallucinations. Whether the agent had correctly identified the relevant clause and applied the right language.
That's a reasonable concern. It's also the wrong concern — or at least, the second concern.
The first concern is simpler and more structural: when an AI agent makes changes at scale, the organization's ability to review, catch errors, and reverse course does not scale with it.
A legal ops team updating 500 contracts over six weeks produces 500 discrete moments where a human reads what was changed. Slow, expensive, human. But each moment is a checkpoint. An error on contract #47 gets caught before contract #48 is touched.
An agent updating 500 contracts over four hours produces one moment: the moment it finishes. At that point, whatever it did is done, across all 500 files simultaneously, and your review window is already upstream of the output.
The accuracy question matters. The reversibility question comes first.
---
What "done" looks like when the agent writes files
We've written before about done-state specification — the problem of agents that loop because nobody defined what completion looks like. This is a related but different failure mode.
In the loop problem, the agent doesn't stop. In the reversibility problem, the agent stops exactly when it should — it completes the task correctly, by every technical measure — and the problem is that you can't easily undo what it did.
These are not the same thing. And most enterprise teams who are currently excited about AI agents with file access are thinking about the first problem while the second one sits unexamined.
The specific capability that's newly available — agents reading and writing Word documents, Excel files, contract databases directly — is genuinely useful. It's also the capability that collapses the review window the fastest. Because unlike an agent sending a recommendation to a human for approval, an agent writing a file has already acted. The recommendation is the action.
---
The reversibility matrix
Not all agent operations carry the same reversal cost. In deployments where we've scoped agent access, we've started using a simple framework to classify operations before they go live.
Tier 1 — reversible by default. Reading data, generating draft documents, producing summaries, flagging items for human review. These operations produce outputs that don't change the underlying record. The agent can run at full autonomy. If it gets something wrong, the human who reads the draft catches it before it becomes real.
Tier 2 — reversible with effort. Overwriting files with version history enabled, updating records in a system with a full audit log, appending to a document rather than replacing it. The agent's action is real, but there's a documented path back. These operations need a confirmation window — not a full human review of every change, but a defined process for catching systematic errors before they propagate. The 500-contract update would live here if version control was active.
Tier 3 — effectively irreversible. Sending emails. Submitting forms to external systems. Overwriting files without version history. Triggering downstream workflows in other systems. Deleting records. These operations have consequences outside the organization's control perimeter. Once the email is sent, the email is sent. The agent cannot unsend it. You cannot unsend it.
The principle is straightforward: autonomous agent authority should be proportional to how reversible the operation is.
Tier 1 operations: full autonomy is fine. Tier 2: autonomous with mandatory audit trail and a human checkpoint before scale. Tier 3: human-required confirmation, no exceptions.
The failure mode we keep seeing: organizations grant Tier 3 authority because the agent has demonstrated accuracy on Tier 1 tasks. Accuracy and reversibility are independent variables. An agent can be highly accurate and still perform irreversible operations that turn out to be wrong — because the error wasn't in the agent's logic, it was in the instructions the agent received.
---
The contract case: what the audit found
Back to the 500 contracts.
We spent a week with that client after the quarterly review. The news was not bad — the agent had been largely accurate. The new liability clause was correctly identified and correctly updated in 91% of files.
The problem was the 9%.
Of the roughly 45 contracts where the update was wrong, most were wrong in a specific way: the agent had encountered clause variants that looked like the target language but were in fact negotiated exceptions — custom language a particular counterparty had insisted on in the original deal. The agent correctly identified them as "liability clause" and correctly applied the standard language.
That was the error. Not a hallucination. Not a failure of understanding. The agent did exactly what it was told. The instructions didn't account for the cases where the "standard" clause had been deliberately made non-standard.
Now: can you find those 45 contracts in a pool of 500? Yes, if you have version history. With effort, over time, as individual counterparties notice the change and flag it.
Or in the next contract renewal cycle, when the wrong clause language creates a dispute.
This is the specific cost of irreversible operations at scale: errors don't surface immediately. They surface at the worst possible moment — when the contract is in dispute, when the audit happens, when the counterparty's lawyer is already on the phone.
---
"Undo" is an organizational problem, not a technical one
The technical undo is usually available. Version history in SharePoint, Git commits, database snapshots, audit logs. The infrastructure for reversal often exists.
What often doesn't exist is the organizational process for using it.
When something goes wrong at scale — when the agent updated 500 files and 45 of them need reverting — who makes that call? Who identifies which 45? Who has the authority to initiate the rollback? Who notifies the counterparties? Who updates the record of what happened and why?
In a human process, errors are caught at the individual level. The legal ops analyst who updates a contract catches her own mistake, fixes it, moves on. The error never becomes an incident.
In an agent process running at scale, errors are systemic. They affect a class of records simultaneously. Fixing them requires a process that most organizations have never had to build — because they've never had a single actor make changes across 500 files in four hours before.
We now include what we call a reversal protocol in every agent deployment that touches production data. Before the agent goes live, we document three things: who has authority to initiate a rollback, what the rollback procedure is for each category of operation, and what constitutes a threshold for triggering review. Not "if the agent makes an error" — every agent will make errors. "What error rate, in what category of operation, requires a human to stop and assess before the agent continues?"
That document exists before the first run. Not because we expect catastrophic failure. Because the cost of writing it before is thirty minutes, and the cost of not having it after a systematic error is measured in weeks.
---
What this means if you're deploying agents with file access
The capability is real and the excitement is warranted. An agent that can read and write enterprise documents directly compresses weeks of process time into hours. We are not arguing against it.
We are arguing for sequencing.
First, classify your operations before you grant access. Map every action the agent will take against the reversibility matrix. Not every operation the agent could theoretically take — every operation this specific agent, in this specific workflow, will actually perform. Tier 1 and Tier 2 operations can run at scale from day one. Tier 3 operations require a defined confirmation process before they go live.
Second, run at scope before you run at scale. The first deployment of any agent with write access should cover a bounded set of records — not 500 contracts, but 20. Enough to validate the logic, surface the edge cases, and find the negotiated exceptions the agent wasn't told to handle. Scale is not a reward for accuracy on the first run. It's a second deployment decision that requires its own review.
Third, build the reversal protocol before you build the agent. The question "how do we undo this if it's wrong" needs to be answered before the agent runs for the first time, not after the first systematic error. The answer should include who makes the call, what the procedure is, and what the notification path looks like. If you can't answer those questions before deployment, you're not ready to deploy at Tier 2 or Tier 3.
---
The sentence nobody wants to say in the kickoff meeting
Every agent deployment kickoff we've been in follows the same pattern: the team is excited, the use case is clear, the timeline is aggressive.
The question that changes the energy is the one about failure.
Not "what if the agent gets something wrong" — teams have usually thought about that. The specific question: "If the agent runs tonight and makes a systematic error across your full document set, what does your organization do tomorrow morning?"
The teams that have a clean answer to that question are ready to deploy. The teams that pause and look at each other — they're not. Not because their agent won't work, but because their organization isn't yet designed for what happens when it does.
The agent reading and writing your files is a real capability shift. It's also the first time in most organizations' history that a single non-human actor has had that kind of access, at that kind of speed, without a human in the approval loop.
The technical question — can the agent do this accurately — is answerable with a pilot.
The organizational question — what do we do when it doesn't — needs to be answered before the pilot runs.
---
One thing we might be wrong about
The reversibility matrix we've described assumes a relatively clear line between read operations and write operations. In practice, that line is getting blurrier.
An agent that reads a file and generates a "recommendation" that auto-populates into a tracked-changes version of the same document is doing something between Tier 1 and Tier 2. An agent that drafts an email and places it in a "pending send" queue is sitting between Tier 2 and Tier 3 — the human is nominally in the loop, but if the review queue is 200 items long, the nominal review is not a real one.
The principle we're confident in: autonomous authority should scale with reversibility, not with accuracy. An agent that is 95% accurate on Tier 3 operations is not ready for full autonomy on Tier 3 operations. Accuracy and reversibility are independent. The agent needs both.
Whether organizations can consistently build and maintain that distinction as agents become more capable — that's an open question. The answer will probably vary by industry, by regulatory context, and by how much the organization has invested in the reversal infrastructure before the first systematic error arrives.
We'd rather they invest before.
---
Working notes from B2B AI deployment in North America. Part of an ongoing series on what we keep noticing across wildly different industries — and what the industry isn't ready to say out loud.
