What Is Discoverable When an AI Agent Is the Actor?

In an ordinary commercial dispute, the record of what happened is email, documents, and the memory of the people involved. When an autonomous agent took the action, none of those exist. There is no author to depose about why the agent did what it did, and the people who built the system frequently cannot say either.

What exists instead is a different category of evidence—system prompts, tool-call logs, model identifiers, retrieval context, and configuration state—and a great deal of it is discarded by default within days. By the time a complaint is filed, the record that would have explained the conduct is often gone, and it was deleted by a retention policy nobody thought of as a litigation-hold problem.

Key Takeaways

• The evidence is configuration, not correspondence. What the agent was instructed to do, what it was permitted to call, and what it retrieved matter more than any single output.
• The default retention posture is destructive. Prompt and tool-call logs are commonly kept for days, not years, and inference providers often retain nothing on the customer’s behalf.
• The model version is a discrete, load-bearing fact. Behavior is not reproducible without it, and providers deprecate versions on their own schedule.
• Preservation duties reach vendors. Much of the record sits with an inference provider or an orchestration platform under contract, and the contract usually does not require them to keep it.
• Reproduction is not verification. Running the agent again produces a new output, not evidence of the old one.

The Categories That Actually Matter

System prompts and instruction state. The standing instructions defining the agent’s role, constraints, and authority. This is the closest thing to a corporate policy the agent has, and it is the first thing to request. It also changes—often frequently, and often without version control—so the operative question is what the prompt said at the time, not what it says now.

Tool and function-call logs. What the agent actually invoked: which API, with what arguments, and what came back. This is the transactional record, and it is where the conduct is visible. It is also the category most likely to have been truncated or sampled for cost reasons.

Model identity and version. Which model, at which version, with which inference parameters. Two versions of the same model behave differently, and providers retire versions on their own timeline. A dispute that takes eighteen months to reach discovery may concern a model that is no longer available.

Retrieval and context state. For agents that retrieve documents or carry memory across sessions, what was in the context window is a substantive fact—the agent acted on that, and not on whatever the same query would retrieve today. Persistent memory raises its own problems, which we have written about in AI agent memory and privacy compliance.

Authorization and scope records. Who authorized the agent to act, within what limits, and what the counterparty was told. This is the same record that answers the liability question in deployer liability, which is why building it once serves both purposes.

Human-in-the-loop artifacts. Where a person reviewed, approved, or overrode the agent, that is ordinary evidence of ordinary decision-making, and it is often the most useful material in the case.

Why Preservation Is the Whole Problem

Federal Rule of Civil Procedure 37(e) applies where electronically stored information that should have been preserved in the anticipation or conduct of litigation is lost because a party failed to take reasonable steps to preserve it, and it cannot be restored or replaced through additional discovery.¹ That third element is what makes agent telemetry a live problem rather than an unfortunate one: a deleted log is not recoverable from a second custodian, because there was never a second copy.

The remedies then run in two tiers. On a finding of prejudice, the court may order measures no greater than necessary to cure it. Only on a finding that the party acted with the intent to deprive another party of the information’s use may the court presume the lost information was unfavorable, instruct the jury that it may or must so presume, or dismiss the action or enter default judgment.

Two features make this worse than ordinary ESI loss.

Rule 37(e) presupposes a duty that attaches well before a complaint: it reaches information that should have been preserved “in the anticipation or conduct of litigation.”¹ In an agent dispute the operator often learns something went wrong within hours—a chargeback, a complaint, an anomalous transaction—while the telemetry that explains it may expire within days.

The second is custody. A meaningful portion of the record sits with third parties: the inference provider, an orchestration platform, an observability vendor. A litigation hold directed at your own systems does not reach them, and standard commercial terms rarely obligate a provider to retain anything for a customer’s litigation. Whether that material is within a party’s “possession, custody, or control” is a contract question² that should be answered before it is a discovery dispute.

Reproduction Is Not Verification

There is an intuitive and wrong move available in these cases: run the agent again with the same input and treat the result as evidence of what happened.

It is not. A re-run is a new event: the model version may have changed, the retrieval corpus has almost certainly changed, and the system prompt may have been edited since—and inference is not reliably reproducible even holding those constant. The output it produces may be useful demonstrative material about how a system behaves; it is not proof of what the system did.

The corollary is that contemporaneous logging is the only reliable record, which returns the question to preservation.

Practical Guidance

For operators, before anything happens. Set retention for prompts, tool calls, model identifiers, and context state to a period measured against your realistic limitations exposure rather than your storage budget. Version your system prompts and keep the history. Ask your inference provider, in writing, what it retains and for how long, and negotiate a preservation obligation if the answer is nothing. Write an incident trigger that issues a hold on agent telemetry automatically, because a manual process will lose the race.

For operators, once something happens. Issue the hold immediately and extend it to vendors in writing the same day. Capture the model version before the provider deprecates it. Do not edit the system prompt to fix the problem before preserving what it said—the fix is usually right and the sequence is usually wrong.

For claimants. Request the configuration, not just the output.³ Ask for the system prompt as of the date of the conduct, the tool-call log for the transaction, the model identifier and parameters, the retrieval context, and the retention policy itself. The retention policy is worth requesting early: it establishes what existed, which is the predicate for everything that follows if it is gone.

For boards. Retention design for agent telemetry is an oversight question, not only an engineering one, for the reasons set out in the Caremark duty in the managed agents era. A company that cannot say what its agents did is a company whose board cannot supervise them.

Work with Astraea Counsel

Astraea Counsel litigates disputes arising from AI systems, including the preservation and discovery fights that decide what the record will show. See our AI litigation attorney page, or contact us to discuss a dispute or a preservation question.

Footnotes

1. Fed. R. Civ. P. 37(e). ↩ ↩²

2. Fed. R. Civ. P. 34(a)(1) (documents and ESI “in the responding party’s possession, custody, or control”). ↩

3. Fed. R. Civ. P. 26(b)(1) (scope and proportionality); Fed. R. Civ. P. 34 (requests for ESI). ↩