Agent Persistent State Profile

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 June 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

AI agents are entering a new operational phase. Early systems focused on prompt engineering and model context. Modern deployments involve several of autonomous agents with distinct identities and long-lived state. Persistent state stores embeddings, preferences, memory, safety constraints, and reasoning artifacts that must remain durable and compliant across failures.¶

Current practice reveals a structural mismatch: agent developers assume implicitly that "somewhere" there is a low-latency, compliant store; storage administrators assume short-lived, stateless applications. This mismatch leads to data loss, privacy violations, tail-latency spikes, and unpredictable behavior.¶

Reviewers have observed that this draft is premature but can be possibly timely: as deployments scale to thousands of agents, storage semantics will become critical infrastructure. By the time APS reaches maturity, the need is expected to be urgent.¶

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals.¶

2. Terminology

Agent:

An autonomous software entity with a distinct identity and a multi-session lifecycle. Agents maintain durable state across restarts or container rescheduling, motivating specialized persistent storage semantics.¶

Persistent State:

Durable data associated with an agent identity, including embeddings, preferences, caches, audit logs, and vector indexes.¶

APS:

Agent Persistent State Profile defined in this document.¶

Usage Class:

A tag applied to storage resources indicating the expected workload. This document defines AgentPersistentState.¶

Line of Service (LoS):

A structured description of storage behavior.¶

Forgetting Policy:

A policy that causes persistent state to be deleted or scrubbed according to age, event triggers, or external legal/compliance requests (for example, scheduled deletion of records older than a given retention period).¶

3. Landscape of Agent Frameworks and Persistent State Needs

Agent frameworks today implement persistence at the application layer, leading to fragility. The following table summarizes common patterns as of 2025; it is illustrative and non-exhaustive.¶

The structural problems across frameworks validate the need for APS: requirements for durability, performance, and compliance must move downward into the infrastructure layer in a standard form.¶

4. APS Data Model

APS defines a new Usage Class:¶

UsageClass: "AgentPersistentState"

APS applies to storage abstractions that present block or filesystem semantics to agents and their orchestrators, including volumes provisioned via Kubernetes PersistentVolumes or surfaces exposed through SNIA/DMTF management schemas. Applying APS directly to pure object stores or HTTP-based APIs is outside the scope of the normative requirements in this document.¶

5. PersistentStateLineOfService Schema

The PersistentStateLineOfService structure describes a single APS profile. Fields marked OPTIONAL are advisory and MAY be omitted. A subset of fields constitutes the core APS compliance baseline and MUST be present and honored for any profile that claims APS compliance.¶

PersistentStateLineOfService {

  ApsVersion: string           # e.g., "1.0"

  Id: string
  Name: string
  Purpose: "AgentPersistentState"

  IOProfile: enum {
      SmallRandom,
      MixedRandom,
      MetadataHeavy,
      VectorIndex
  }

  # Optional refinement for vector workloads:
  VectorPhase: enum {
      Ingest,
      Query,
      Mixed
  } OPTIONAL

  CapacityRangeGiB {
    MinGiB: integer
    MaxGiB: integer
    RecommendedStepGiB: integer
  }

  Performance {
    MinIOPS: integer
    MaxLatencyMsP95: number
    MaxLatencyMsP99: number

    RecommendedIOSizeKiB: integer
        # Embeddings and vectors may use 16-64KiB I/O sizes
  }

  Durability {
    DurabilityClass: enum { Standard, High, VeryHigh }
    ReplicationScope: enum { LocalAZ, MultiAZ, MultiRegion }
  }

  CrashConsistency {
    RequiresWriteOrdering: boolean
  }

  Retention {
    RetentionDays: integer
    ForgettingPolicySupported: boolean
  }

  Privacy {
    ContainsUserFacingDataExpected: boolean

    MinDeletionSemantics: enum {
      BestEffort,
      CryptographicErase,
      MediaScrub
    }

    ErasureScope: enum {
      Volume,          # Whole LUN / filesystem
      FilesystemTree,  # Directory / inode subtree
      ObjectPrefix,    # Prefix subset for object-backed systems
      ApplicationKey   # Crypto handled above storage
    }

    MaxEraseLatencyHours: integer
  }

  ConcurrencyHints {        # OPTIONAL, advisory only
    AdvisoryLockingSupported: boolean
  }
}

The core APS compliance baseline consists of the following fields, which MUST be present and reflect behavior meaningful to the abstraction being exposed:¶

• IOProfile¶

• CapacityRangeGiB (all members)¶

• Performance.MinIOPS¶

• Performance.MaxLatencyMsP95¶

• Durability.DurabilityClass¶

• Durability.ReplicationScope¶

• CrashConsistency.RequiresWriteOrdering¶

• Retention.RetentionDays¶

• Retention.ForgettingPolicySupported¶

• Privacy.MinDeletionSemantics¶

• Privacy.ErasureScope¶

• Privacy.MaxEraseLatencyHours¶

Providers MUST NOT advertise an APS-compliant profile that omits or ignores these core fields. Additional fields MAY be omitted if they are not meaningful for the abstraction (for example, advisory locking hints on raw block volumes).¶

In environments that provision storage in terms of throughput (for example, MiB/s) rather than IOPS, implementers MAY derive an effective MinIOPS from documented throughput and average I/O size. One reasonable approach is:¶

MinIOPS ≈ (ThroughputMiBps * 1024) / RecommendedIOSizeKiB

APS does not constrain how this effective value is calculated, but providers SHOULD document the relationship between throughput and MinIOPS.¶

6. Crash Consistency Requirements

All APS-compliant resources MUST provide metadata consistency after power loss or crash. For the purposes of this document, metadata consistency means that the filesystem or block namespace remains mountable without manual repair tools and that directory and inode structures do not exhibit silent corruption that would cause loss of reachability for existing files.¶

The RequiresWriteOrdering flag indicates that applications rely on storage honoring write ordering or barrier semantics (for example, flush/fence operations) to maintain write-ahead logging or similar invariants. When true, providers MUST document the ordering guarantees and the mechanisms available to applications.¶

Implementations supporting high-frequency agent checkpointing SHOULD document whether O_DIRECT, O_SYNC, or equivalent durability hints are honored by the underlying storage stack.¶

Applications are expected to rely on standard filesystem atomic operations (such as POSIX rename) for batched updates. APS does not define or negotiate additional transactional semantics.¶

7. Privacy, Replication, and Erasure

The MinDeletionSemantics, ErasureScope, and MaxEraseLatencyHours fields describe the minimum deletion and erasure behavior for data stored under the profile. When combined with ReplicationScope, providers MUST interpret these fields as applying to all replicas of the primary data in scope.¶

The MaxEraseLatencyHours field MUST be a strictly positive integer. A value of zero is reserved and MUST NOT be used. Deployments that effectively provide synchronous erasure MAY represent this with a small non-zero value and SHOULD document the expected behavior.¶

For example, if MinDeletionSemantics is set to CryptographicErase and ReplicationScope is MultiRegion, then cryptographic erasure of all regions MUST complete within MaxEraseLatencyHours, unless the provisioning request explicitly accepts weaker behavior.¶

APS describes behavior for primary data under the profile. Snapshots, backups, and other disaster recovery mechanisms MAY retain older copies of data beyond MaxEraseLatencyHours. End-to-end compliance for such copies is outside the scope of this document and MUST be addressed by higher-level data lifecycle policies.¶

The ErasureScope field indicates the granularity at which cryptographic or destructive erase is expected to act:¶

• Volume: erasure is performed at the level of a whole volume, LUN, or filesystem. Destroying the associated key or media affects all data hosted on that volume.¶

• FilesystemTree: erasure is performed at the level of a directory or inode subtree. For example, implementations MAY use per-directory filesystem encryption mechanisms (such as Linux fscrypt) where destroying the key renders only that subtree unreadable.¶

• ObjectPrefix: erasure is scoped to a subset of objects under a prefix or bucket namespace. This is primarily informative for object-backed systems that expose filesystem views or may be the basis of future APS profiles for object-native agent state. Profiles that target purely block or filesystem abstractions MUST NOT use ObjectPrefix.¶

• ApplicationKey: cryptographic erase is implemented above the storage layer. The storage system provides generic persistence, and an application, sidecar, or agent runtime manages keys and performs crypto-shredding by destroying them.¶

When MinDeletionSemantics is set to CryptographicErase and ErasureScope is Volume, FilesystemTree, or ObjectPrefix, the storage or filesystem layer is responsible for ensuring that destruction of the relevant cryptographic material renders the targeted scope unreadable without affecting adjacent scopes beyond what is documented.¶

When MinDeletionSemantics is CryptographicErase and ErasureScope is ApplicationKey, the storage layer is not aware of per-agent keys. In this case, APS simply records that cryptographic erase is expected to be achieved via application- or sidecar-managed key lifecycles. Operators MUST NOT interpret such a profile as evidence of storage-controller-level key separation.¶

Storage backing APS MAY be multi-tenant. Providers SHOULD document whether cryptographic erase is implemented via volume-level keys, per-tenant keys, filesystem-level keys, or other mechanisms, and what the effective erase granularity is.¶

There is intentionally no single mandatory minimum for MinDeletionSemantics. A provider that cannot implement CryptographicErase MAY still advertise an APS profile using BestEffort semantics, but such profiles are generally unsuitable for compliance-critical deployments and SHOULD be clearly documented as such.¶

8. Multi-Tenancy and Volume Scalability

APS does not require a 1:1 mapping between agents and volumes. Volume-per-agent designs risk exhausting controller limits at scale. Instead, APS is intended to describe the behavior of shared storage classes that MAY host many agents.¶

Implementations are encouraged to separate cryptographic and policy granularity from volume granularity. For example, a single APS volume may host multiple agents while still satisfying erasure and isolation requirements at a filesystem-tree or application-key level, as indicated by ErasureScope.¶

9. Block and File Applicability

APS is intended for storage abstractions that present block or filesystem semantics to agents. Some fields are primarily relevant to block devices (for example, RecommendedIOSizeKiB), and others are primarily relevant to filesystems (for example, AdvisoryLockingSupported).¶

Providers MAY omit non-core fields that are not meaningful for the abstraction they expose. Core fields listed in Section Section 5 MUST be honored.¶

10. Identity and Control Plane Role

APS discusses persistent state in terms of "agent identity", but does not require storage protocols (for example, NVMe, iSCSI, NFS) to carry per-agent identifiers on individual I/O operations. In most deployments, storage controllers see host or initiator identifiers, not agent IDs.¶

Identity mapping and scoping are therefore the responsibility of the control plane and agent platform (for example, an orchestrator that binds particular agents or pods to specific volumes, filesystems, or filesystem subtrees). APS describes the properties of those storage constructs; it does not define new protocol headers or on-the-wire identity fields.¶

11. Kubernetes and CSI Mapping

Kubernetes and CSI are expected to be primary consumers of APS. This section provides guidance for CSI driver integrations. It is informative for the CSI specification itself.¶

A CSI driver that claims to be "APS-aware" MUST support a documented mechanism to pass APS hints from higher-level configuration (for example, StorageClass parameters) to backend profiles. One possible mapping is:¶

• parameters["aps.storage.k8s.io/ioProfile"] → IOProfile¶

• parameters["aps.storage.k8s.io/privacy.minDeletion"] → MinDeletionSemantics¶

• parameters["aps.storage.k8s.io/privacy.erasureScope"] → ErasureScope¶

• parameters["aps.storage.k8s.io/privacy.maxEraseHours"] → MaxEraseLatencyHours¶

• parameters["aps.storage.k8s.io/durability.replicationScope"] → ReplicationScope¶

The recommended "aps.storage.k8s.io/" prefix reduces the likelihood of collisions with vendor-defined parameters. Alternative key names MAY be used if they are clearly documented by the CSI driver and its consumers.¶

12. Bindings and Profile Discovery

APS MAY be expressed in existing schemas as follows:¶

Swordfish:

Implementations expressing APS profiles in Swordfish SHOULD use ClassOfService with UsageClass="AgentPersistentState", and attach a vendor-defined or standardized PersistentStateLineOfService extension carrying APS fields. Discovery of available APS profiles then follows Swordfish mechanisms for enumerating lines of service.¶

Redfish:

Implementations exposing APS via Redfish SHOULD use OEM extensions on StorageService and Volume resources to represent PersistentStateLineOfService fields, together with UsageClass="AgentPersistentState" where applicable. Discovery would use Redfish resource enumeration.¶

CSI:

APS hints MAY be conveyed through StorageClass parameters by convention, as described in Section Section 11. A higher-level control plane (for example, a storage operator) is expected to map available backend profiles to supported StorageClasses.¶

The details of profile discovery are intentionally left to existing management and orchestration mechanisms; APS focuses on the shape and semantics of individual profiles.¶

Future work MAY explore bindings for object-native stores, for example, using object prefixes and S3 Select-like mechanisms to host agent state directly in object storage, based on the ObjectPrefix erasure scope.¶

13. Versioning and Extensibility

The ApsVersion field in PersistentStateLineOfService identifies the APS version the profile conforms to (for example, "1.0").¶

Future versions of APS MAY add new OPTIONAL fields. Profiles that set ApsVersion to "1.x" MUST remain backward compatible for all fields defined in version 1.0, and consumers MUST ignore unknown fields rather than treating them as errors.¶

14. Security Considerations

APS-compliant resources are expected to host sensitive agent state, including user-identifiable data and behavior-derived embeddings. Implementations SHOULD support encryption at rest, strong identity scoping in the control plane, and cryptographic erasure according to policy.¶

15. Privacy Considerations

Enterprises may need to demonstrate that agent memory for a specific user was deleted in accordance with regulation (for example, GDPR). APS provides explicit deletion semantics, an erasure scope, and a latency bound to support such compliance, but implementation details and audits remain the responsibility of the operator and any higher-level governance systems.¶

16. Limitations and Future Work

This document does not define a conformance test suite or reference implementation. Future work MAY include tests for APS-aware CSI drivers, managed vector databases, and storage arrays.¶

APS does not provide guidance on how agents should degrade gracefully when APS-compliant storage is unavailable. Agent frameworks are responsible for fallback behavior (for example, operating in a stateless mode).¶

APS does not model cost trade-offs explicitly. Operators are expected to balance erase latency, replication scope, erasure scope, and storage-class cost.¶

APS does not attempt to model differential privacy, federated learning, or higher-level alignment techniques. Those may rely on APS semantics but are outside the scope of this profile.¶

A normative JSON Schema for PersistentStateLineOfService is intended for a future revision to enable automated validation and tooling.¶

17. IANA Considerations

This document requests that IANA create an "APS UsageClass and Profile Registry" containing the following initial values:¶

UsageClass:

• AgentPersistentState¶

IOProfile:

• SmallRandom¶

• MixedRandom¶

• MetadataHeavy¶

• VectorIndex¶

ErasureScope:

• Volume¶

• FilesystemTree¶

• ObjectPrefix¶

• ApplicationKey¶

No additional IANA actions are required by this document.¶

Appendix A. Example APS Profiles (Non-Normative)

This appendix provides three example PersistentStateLineOfService instances. These are illustrative and non-normative. They are intended to show how capacity, performance, durability, and privacy settings can be combined for common agent scenarios.¶

PersistentStateLineOfService {
  ApsVersion: "1.0"
  Id: "aps-standard-1"
  Name: "APS-Standard-Checkpoint"
  Purpose: "AgentPersistentState"

  IOProfile: SmallRandom

  CapacityRangeGiB {
    MinGiB: 5
    MaxGiB: 100
    RecommendedStepGiB: 5
  }

  Performance {
    MinIOPS: 3000
    MaxLatencyMsP95: 20
    MaxLatencyMsP99: 50
    RecommendedIOSizeKiB: 8
  }

  Durability {
    DurabilityClass: High
    ReplicationScope: MultiAZ
  }

  CrashConsistency {
    RequiresWriteOrdering: true
  }

  Retention {
    RetentionDays: 30
    ForgettingPolicySupported: true
  }

  Privacy {
    ContainsUserFacingDataExpected: true
    MinDeletionSemantics: CryptographicErase
    ErasureScope: Volume
    MaxEraseLatencyHours: 24
  }

  ConcurrencyHints {
    AdvisoryLockingSupported: true
  }
}

PersistentStateLineOfService {
  ApsVersion: "1.0"
  Id: "aps-vector-1"
  Name: "APS-Vector-Index"
  Purpose: "AgentPersistentState"

  IOProfile: VectorIndex
  VectorPhase: Query

  CapacityRangeGiB {
    MinGiB: 50
    MaxGiB: 2000
    RecommendedStepGiB: 50
  }

  Performance {
    MinIOPS: 8000
    MaxLatencyMsP95: 25
    MaxLatencyMsP99: 80
    RecommendedIOSizeKiB: 32
  }

  Durability {
    DurabilityClass: VeryHigh
    ReplicationScope: MultiRegion
  }

  CrashConsistency {
    RequiresWriteOrdering: true
  }

  Retention {
    RetentionDays: 90
    ForgettingPolicySupported: true
  }

  Privacy {
    ContainsUserFacingDataExpected: true
    MinDeletionSemantics: CryptographicErase
    ErasureScope: FilesystemTree
    MaxEraseLatencyHours: 48
  }

  ConcurrencyHints {
    AdvisoryLockingSupported: false
  }
}

PersistentStateLineOfService {
  ApsVersion: "1.0"
  Id: "aps-light-1"
  Name: "APS-Light-Experiment"
  Purpose: "AgentPersistentState"

  IOProfile: MixedRandom

  CapacityRangeGiB {
    MinGiB: 1
    MaxGiB: 200
    RecommendedStepGiB: 1
  }

  Performance {
    MinIOPS: 500
    MaxLatencyMsP95: 40
    MaxLatencyMsP99: 120
    RecommendedIOSizeKiB: 4
  }

  Durability {
    DurabilityClass: Standard
    ReplicationScope: LocalAZ
  }

  CrashConsistency {
    RequiresWriteOrdering: false
  }

  Retention {
    RetentionDays: 7
    ForgettingPolicySupported: false
  }

  Privacy {
    ContainsUserFacingDataExpected: false
    MinDeletionSemantics: BestEffort
    ErasureScope: ApplicationKey
    MaxEraseLatencyHours: 24
  }

  ConcurrencyHints {
    AdvisoryLockingSupported: false
  }
}

Author's Address