Enterprise agents now carry four kinds of state—and they should not share one retention policy

Enterprise teams often talk about an agent’s “memory” as though it were one object. Two current product surfaces show why that is too simple: production agents now carry at least four kinds of state, and each deserves a different owner and retention rule.

Conversation state

Snowflake’s public-preview Cortex Agent SDK can preserve multi-turn conversations in persistent threads across application sessions. That state exists to keep a dialogue coherent; the SDK exposes conversations and threads as explicit resources rather than forcing an application to resend every prior message (Snowflake SDK documentation).

Execution state

The same SDK treats long-running work separately. An application can start a background run, disconnect, and reconnect later by run ID. It can also stream tool calls, tool results, citations and status events. That is operational state: teams need it for recovery and observability, but it is not automatically the business record a user intends to preserve (Snowflake release note).

Business memory

Workday’s early-access Talent Acquisition Agent describes a more consequential store. Interview feedback, notes, transcripts and hiring context can become durable memory so future candidate searches reuse what a recruiting team learned. That is not merely chat continuity. It is personnel-related business data whose reuse can affect later decisions, making access, correction and retention materially different from a resumable run (Workday).

Control state

Workday also exposes a fourth category: autonomy settings can vary by region, role or organization, determining what the agent may do itself and what requires review. Those settings are policy state. They need change control and auditability because they define when background work becomes an external action (Workday).

The practical lesson is to avoid one blanket “agent memory” toggle. Conversation history can expire with the user experience; execution records can follow incident and audit needs; business memory should inherit the source domain’s governance; autonomy policy should be versioned like configuration. Snowflake’s SDK makes the first two distinctions visible in its API, while Workday’s launch makes the latter two visible in an enterprise workflow. Treating all four alike may be convenient for implementation, but it obscures who can inspect, delete or change the state that actually shapes the agent’s next move.