Stateful AI: What to Remember in the Shift to AI That Remembers

Providers have recently moved towards enabling AI agents to maintain persistent context and memory across interactions rather than treating each request as an isolated event. The environment makes it easier for enterprise AI systems to be designed to remember data and materials input and output from the tool.

The “stateful” concept falls at the opposite end of the spectrum from those providers’ “Zero Data Retention” (or ZDR) environments—an architecture that deletes data as soon as it is no longer necessary. Practically, this means that inputs and outputs (i.e., chat history, instructions, etc.) are not retained beyond transient processing and likely cannot be used to train or improve the model. This practice is often deployed in enterprise instances of AI systems to limit data exposure and security and compliance risks.

Stateless environments that enable ZDR were built around a core architectural assumption: that each interaction with the system is discrete and continuity is not required.

That assumption is now shifting, in part because of the proliferation of agentic tools. Agentic tasks unfold across multiple steps over time, requiring the agent to carry forward tool outputs, track what’s been tried, and maintain the current goal, which is not possible without a persistent state. Error recovery and tool chaining compound this, since each step’s result becomes the input for the next, and failure recovery demands a record of prior attempts. Human-in-the-loop workflows push further still, as agents must hold user intent across interruptions that can span minutes or hours.

As a result of the shift, ZDR will be less operationally plausible, and the data exposure, and security and compliance gaps that may have been operationally mitigated, will again come to the forefront. These risks may require that legal teams revisit agreement terms to address the resulting contractual gaps.

How Stateful AI Changes the Architecture
A stateless AI system processes requests transactionally. A prompt goes in, a response comes out, and the interaction (and data storage) ends.

In addition to generating outputs, stateful systems maintain a persistent memory layer that carries context across sessions. That layer may store conversation summaries, extracted facts, embeddings in vector databases, or other structured context derived from prior interactions. Future responses are shaped not just by the prompt at hand, but by accumulated history.

If you were already leveraging an AI tool’s memory capabilities, or agreed to a solution architected to allow for data retention, you may have already accounted for the new architecture.

Otherwise, you should consider the factors below as part of your assessment of the tool:

1. Data Location and Infrastructure Architecture
   Consider a common scenario. An enterprise negotiates processing with a cloud provider for its AI platform exclusively in EU regions. Months later, the AI model provider with the hosted tool enables its memory feature backed by storage in the United States. Prompts may still be processed in the EU, but the accumulated context derived from those prompts may not be.

The system has not changed from the user’s perspective. Architecturally, however, there is now a second data location that must be analyzed and contractually addressed.

In a stateless environment, data residency analysis is straightforward. It can be characterized by where inference occurs, where logs are stored, and which subprocessors touch the data. The boundaries of the system are visible.

Stateful systems add another location where data lives in a persistent memory store.

2. Retention and Deletion Procedures
   Many agreements that assume stateless systems limit data retention to just the transaction data like telemetry and incident logs. In stateful systems, even if raw logs are deleted on schedule, the memory store may retain structured context derived from those interactions.

That creates a practical dissonance. Raw interaction data and derived memory artifacts are not the same thing, and they may follow different retention paths. Deleting one does not automatically eliminate the other.

Retention provisions should therefore be reviewed with this distinction in mind. Agreements need to address not only transactional data, but also the persistent context that enables stateful functionality.

3. Privilege, Discovery and Confidentiality
   Attorney-client privilege and work-product protections depend, in part, on controlling who has access to protected communications. When lawyers use tools with persistent memory, that analysis shifts.

For example, it may not be necessary (though dependent on a number of other factors) in a stateless system to create walled gardens of client data, since there is no retention of the client data in the first place.

With a stateful system, the relevant considerations expand:

• • What has the system retained from prior privileged communications?
  • Could retained summaries or context resurface in a later session that is not itself privileged?
  • Could a third party reviewing the memory layer gain access to protected communications?

The stateful shift also requires assessment of confidentiality. In a stateless environment, an employee sharing sensitive information with an AI tool could reasonably assume that information was not persisted beyond the immediate session. That assumption no longer holds when memory is enabled. Employees may now be inadvertently contributing to a growing organizational memory store without realizing it, and without understanding what that store contains, who can access it, or how long it will be retained. This creates a training and governance gap that legal and HR teams will increasingly need to address. Acceptable use policies written for stateless AI tools should be revisited to account for the fact that what an employee tells the system today may shape its behavior in a session weeks from now—and potentially for a different user.

Why Standard AI Clauses Miss the Memory Layer
Most AI data-handling provisions do not automatically extend to systems that maintain long-lived context. When a system retains persistent context, those clauses need to be revisited.

In practice, that means:

• Training restrictions should address memory, not just model retraining. Provisions that prohibit use of customer data for training should also clarify whether inputs are stored or structured within persistent memory systems.
• Deletion obligations should extend to derived artifacts. References to “customer data” should clearly encompass summaries, embeddings and other memory objects, as well as specify how deletion is verified.
• Residency and subprocessor disclosures should include the memory layer. If persistent context is stored separately from inference infrastructure, its geographic location and supporting vendors should fall within contractual commitments.
• Audit rights should cover stored context. Agreements should allow confirmation of what persistent information is retained and whether it has been deleted when required.
• Incident response provisions should expressly include memory systems. Breach definitions should encompass persistent context stores that may contain accumulated sensitive information.
• Privilege-sensitive deployments may require configuration limits. For legal and regulated use cases, contracts should address whether and how the system can limit retention or resurfacing of sensitive context.

What Questions Should You Be Asking
Many AI vendors have not yet updated their standard terms to address a change to persistent memory. Where memory features are disclosed at all, they may appear in product documentation or release notes rather than in data processing agreements or subprocessor lists.

For procurement teams, this gap has a practical implication: The absence of memory-specific language in a vendor’s standard terms should not be read as confirmation that no memory is occurring. It more likely reflects the fact that standard terms have not caught up with the product. Before you turn on a stateful feature, or accept it as a default, treat it like adding a new data store to the service. Use the questions below to drive diligence:

1. Can we scope or disable memory?
   Can we run memory off, or restrict it to a specific workspace, team or matter? If it’s on, can we limit what gets written (e.g., tool outputs only, no conversation text)?
2. What exactly is stored—and in what form?
   Does the system retain raw prompts/responses, summaries, extracted “facts,” embeddings, tool logs, uploaded files, or links/artifacts created during tool use? If raw text is deleted, do embeddings or summaries persist?
3. Where does the memory live (including backups and DR)?
   Where is the memory layer stored geographically, and does that location differ from the inference environment? Does the vendor replicate memory for backup, disaster recovery, analytics or support—and if so, to where?
4. How long is memory retained, and how is deletion verified?
   What are the retention defaults for the memory store, derived objects and backups? When we request deletion, what gets deleted (raw data, derived objects, indexes, caches), and how do we confirm completion?
5. Who can access memory, and under what controls?
   Which roles (customer admins, vendor support, subcontractors) can view or export memory contents? Is access logged? Can we enforce least-privilege, restrict support access and require approval workflows?
6. Can memory leak across users, tenants or matters?
   Is memory isolated by tenant and by workspace? Can a user in one matter ever see context from another? What protections prevent cross-user contamination (including through shared agents, shared vector stores, or reused toolchains)?

Conclusion
Stateful AI is likely the direction the AI industry is moving because systems that remember are dramatically more useful than systems that forget. Enterprises adopting stateful AI should not assume that legacy AI arrangements adequately govern persistent memory functionality.

For counsel and procurement teams revisiting AI agreements, the stateful memory layer deserves careful attention.

Pillsbury’s Global Sourcing and Technology Transactions team regularly advises clients on structuring and negotiating AI agreements, including emerging issues presented by stateful systems and agentic deployments. We are actively working with clients to update templates and procurement strategies to reflect this architectural shift.