The client says my AI agent broke their website. How do I show what it actually changed?
Show the per-change timeline from the work record: every step the agent ran on the site, each with its saved result and time, in order. Review the receipt and actual deliverable before accepting a handover.
Website breakage arguments are lost in the fog between "your agent was in there Tuesday" and "the checkout broke Tuesday." The record cuts the fog because it is per-change, not per-session. Each step the agent executed saved its result at the time it ran (AER-1 receipt, IETF Internet-draft-zambo-aer1-21): the deploy, the edit, the configuration change, in sequence, with their outputs. Reading the timeline, the broken behaviour either follows one of those steps or it does not, and both answers are useful.
Build the reply as a timeline plus an exclusion list. The timeline: the steps on the client's systems, in order, each linked to its receipt. The exclusion list: the systems and files the agent had no steps on at all, stated as plainly as the inclusions. Then the repair: if one of your steps caused the break, say so in the same message and fix it as a new recorded step; credibility bought by owning the true item is what makes the false items deniable.
Where the agent ran unrecorded, be honest about the weaker ground: server logs, deploy histories, and file timestamps are the fallback evidence, and assembling them is the expensive afternoon this record exists to prevent. Sites your agents can touch are exactly the work that should run recorded from the first step.
Template: the per-change incident reply
Subject: Change timeline for [site], [date range]. 1. Steps on your systems, in order: [time, step, saved result, receipt link]. 2. Systems and files with no agent steps in the period: [list]. 3. The step where the reported breakage first appears: [step, or "no agent step precedes it"]. 4. Our repair: [fix as a new step, with its record] or [the change that did cause it originated outside the agent's steps; the evidence is item 1 and 2]. Attach: the job's handover link for the full record.
Worked example
The timeline's source object is shaped like the public step records in this section: https://zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51 shows five steps readable in order with their states. An incident reply built from a record like this replaces a week of log archaeology with one reading.
Frequently asked questions
The breakage came from a step my agent ran. Does the record hurt me?
It tells you first and precisely, which is worth more than it costs. Owning the exact step, fixing it on the record, and showing the rest of the timeline clean is the response that keeps clients; fog protects no one for long.
The client will not read a technical record. How do I present it?
Send the template, not the raw record: three sections, plain words, with the handover linked for anyone who wants the detail. Timelines persuade non-technical readers because sequence is intuitive even when systems are not.
Can the record prove the agent did NOT touch a file?
Within the recorded system, the step list is the complete account of what ran through it, so an untouched file is one with no step on it. Work the agent did outside the record is outside the claim, which is why client systems work belongs inside it.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai