AI agents do not just run software. They participate in the work. Traditional software executed a defined workflow, but an agent interprets a goal and selects its own execution path within set parameters. That shift breaks a lot of the contract language we have been using for years, because use restrictions written for fixed functions do not cover the cascade of actions an agent can take once it has been pointed at an objective.
This How to Contract webinar was hosted by Laura Frederick and featured Olga Mack, former General Counsel and CEO of TermScout, and John Pavolotsky, a partner at Stoel Rives who co-chairs the firm's AI, Privacy and Cybersecurity group. Olga brought the customer-side read, drawn from her work analyzing thousands of commercial agreements. John brought the provider-side read, drawn from more than two decades of technology transactions work. The split made the discussion useful in a way single-perspective panels rarely are.
The session worked through three AI agent provisions, all of them generated by an AI model to look polished, and pulled them apart for what they leave undefined. Along the way the speakers covered the alignments you need before drafting, the difference between misuse and malfunction and autonomous but unintended conduct, why commercially reasonable efforts is a choice rather than a default, how to turn oversight obligations into something that can actually be actioned, and where governance language belongs in the deal.
Here are our top ten takeaways from the speakers' comments during the webinar:
Agents participate in the work, so the old language does not fit. Traditional software executes defined workflows. An agent interprets a goal and selects its own execution path within set parameters. That is a structural difference, not a cosmetic one, and it is why use restrictions written for fixed functions leave gaps. When you read an agent provision, ask whether it governs the initial instruction or the cascade of actions the agent takes after it.
Map the autonomy before you draft. You cannot allocate accountability until you know what the agent can do without a human in the loop. Build the autonomy map, the system access map, the decision authority boundaries, and the monitoring check first. If you skip this, even strong drafting will not save you, because you will be allocating risk you have not actually identified.
Validate your assumptions with the technical teams. Lawyers tend to walk into a technology deal with assumptions about the product, and some of them are wrong. The contracting work happens before you draft, when you sit with operations, product, and security to confirm what is real. Treat that conversation as part of the drafting process, not a preliminary to it.
Sit with the discomfort that slop language creates. AI-drafted provisions read well, which is the trap. Whether you like the clause is beside the point. The trained instinct telling you something is vague is the signal worth following. Slow down on the words that sound fine and ask what they actually leave undefined.
Responsibility should track visibility, not just control. It is hard to be accountable for what you cannot control and impossible to be accountable for what you cannot see. A clause making the customer solely responsible for all outputs fails on both counts when output is undefined and the customer has no guaranteed window into how the agent generated it. Tie sole responsibility to transparency and safeguard obligations.
Separate misuse, malfunction, and autonomous but unintended conduct. The three are different risks with different owners. Misuse tends to sit with the customer and malfunction with the provider. Autonomous but unintended conduct has no natural home, so it needs predefined notification timelines, suspension triggers, and root cause processes. You need an operational incident framework, not just a breach clause.
Commercially reasonable efforts is a choice, not a default. The standard is vague, and that vagueness will be interpreted years from now, not as of the day you signed. If you want the flexibility, keep it and know why. If you want structure, convert the discretion by tying the standard to documented safeguards, testing before material updates, and effort levels matched to defined risk tiers.
Logs are worthless if nobody actions them. Negotiating log delivery and audit rights is only half the job. You also need someone on security or operations, or a third party, who can tell you whether the logs show compliance. And push for a defined log schema, because access to logs is very different from access to logs that contain what you need.
Build oversight as an SLA, not a sentence. Oversight obligations without defined mechanisms create exposure gaps you will feel daily for the life of the contract. A clause that promises monitoring without saying how often, at what detail, or with what trigger is not protection, it is a placeholder. The practices worth borrowing are risk-tiered action categories, monitoring frequency tied to tier, defined log content in the exhibits, and audit triggers linked to anomaly thresholds. Treat the oversight terms with the same rigor you would give a security exhibit.
Governance belongs in the deal, and edge cases belong in governance. The catastrophic, unlikely event reflects badly on both sides, which makes it a shared problem rather than a finger-pointing exercise. Normalize the edge cases, imagine the consequences, and build governance around them. Designing for the tail risk is what gives you discipline on the everyday risk.
Subscribe to Stay in the Loop
The contracting questions around AI agents are moving fast, and our weekly newsletter is how you keep pace. It carries links to upcoming How to Contract webinars along with recaps like this one. Subscribe now so the practical insights reach you whether or not you caught the session live.
