Your next custodian might not have an inbox, a job title, strong feelings about the office thermostat, or about someone nuking last night’s salmon in the microwave.

It might have API access. For the uninitiated, an API is a way for software systems to communicate and request actions from one another.  Think of it as a pal you gave a key to so they could feed the cat while you’re away. They can come in and use the can opener. They are not supposed to go through the medicine cabinet. The logs may help you work out which metaphorical rooms they visited, if anyone enabled the logging.

That should give anyone who drafts litigation holds a moment’s pause.

Two recent pieces in the news caught my attention. Ralph Losey’s August EDRM article, “When AI Agents Go Rogue, the Logs Become Evidence,” looks at the trail an agent leaves as it works across systems: commands, messages, access records, and the technical context around them. K&L Gates’ May 20 Litigation Minute comes at it from the preservation side. GenAI prompts, outputs, uploaded documents, and usage logs may fall within preservation obligations, and they may not be retained by default. Some disappear on a schedule. Others never exist at all unless someone turned on logging before anyone needed it.

Put the two together and you land on an uncomfortable question: does your client’s litigation hold reach the systems that are doing the work?

Isn’t this just the chatbot-history problem again?

Not quite. We’ve previously discussed chatbots as diaries. Somebody types something candid into a chat window, and months later opposing counsel finds it very interesting. A neat way to manufacture an exhibit!

Agents are different because they act. Give one a task and permission, and it may search repositories, pull files, call tools, change records, send messages, or hand the job off to another agent. Depending on the setup, each of those steps can leave records in a different system.

The human’s chat history is one chapter. What the agent wrote is part two.

What does that look like in a real dispute?

Picture a hypothetical procurement agent told to cut spending with a supplier. It reviews the contracts, pulls purchasing data, updates the vendor record, and drafts a termination notice. A manager approves the notice. Six months later, the supplier sues.

You preserve the manager’s email and the final letter. Good start.

Now suppose the case turns on whether the company considered an amendment guaranteeing minimum purchases. Did the agent retrieve it? Did a tool call fail? Was the workflow working from an outdated version? Did the manager see a warning before clicking approve?

The polished letter may tell you very little about how any of that happened. You might think the polish reflects enough light on the subject, but there’s more in deeper, possibly darker, places.

The answers, if they exist, sit in retrieval records, tool responses, approval events, and application logs that nobody put on the collection plan. The manager may remember clicking “approve” and not much else. That isn’t evasion, it may just be delegation.

So is the software a custodian now?

As a working concept, yes, and a useful one. Calling the agent a custodian forces two questions: where is the machine’s work recorded, and who can preserve it? It does not give software legal personhood or put it in a deposition chair. (Although I would pay to watch someone instruct an agent to answer only the question asked.)

Some accountable human should own the workflow, control the settings, and manage the vendor relationship. That person belongs in the preservation conversation, and that conversation needs specifics. Name the tools and workflows that touched the matter. Identify the accounts involved, human and service. Find out what records exist, where they live, and when they expire. Then test that preservation works, because a beautifully drafted hold notice doesn’t necessarily touch automated deletion.

Can’t we just take the agent’s word for what it did?

Um, no, it’s an AI. An agent’s report that it finished a task is a record of what it claimed; it doesn’t prove the task was completed. In our procurement example, “I reviewed all relevant agreements” should send someone looking for the retrieval and access logs that could help verify it. That ever-confident AI statement is not a timestamp.

And by the way, this cuts both ways. The same logs that might reveal a skipped amendment might also show the agent did what it said it did.

Does this mean keeping every machine event forever?

No. Discovery still turns on relevance, proportionality, and privilege. Rule 26 did not acquire an unlimited-storage exception because someone said “agentic.”

Nor does a missing log automatically mean sanctions. In federal court, Rule 37(e) asks, among other things, whether reasonable steps were taken to preserve the information, whether it can be restored or replaced, and whether prejudice or an intent to deprive supports a particular remedy. State rules vary, and how courts will apply all of this to agent logs is still being worked out. That part is your department, not mine. I know, I say this all the time, but it’s true.

So, what to do?

Get curious earlier. At intake, alongside “Who was involved?” ask “What automated systems acted on this?” In custodian interviews, have people walk through the workflow step by step, including the steps they delegated and then never actually saw.

That will tell you more than asking whether they “use AI,” which can mean anything from fixing a comma to letting software negotiate with a supplier.

Your client’s copilots and agents may hold part of the factual record. Find it while it still exists.

Has an automated system turned up in one of your matters yet, either as a source of evidence or as a gap in it? I’d like to hear how it went.

Questions about the digital trail behind an automated transaction? Burgess Forensics examines system logs, account activity, metadata, and other digital evidence. (866) 345-3345 | steve@burgessforensics.com