]> MemoryAI

Vietnam founder@memoryai.vn

Applications Independent Submission ai memory interchange portability agents This document specifies a vendor-neutral interchange format for the persistent memory of AI agents — preferences, decisions, identity claims, pitfalls, and procedures that an agent accumulates across sessions. The format is a self-contained JSON Bundle with explicit conformance levels (Producer, Consumer, Bidirectional). Implementations MAY accompany the Bundle with an HTTP Profile that exposes export and import endpoints. The goal is to allow a user's "agent brain" to move between cloud services, on-premise installations, and third-party implementations without lock-in, in a manner that interoperates with existing right-to-erasure obligations such as . This document is self-contained: all schema fields normatively required by Producers and Consumers are defined inline. An informative reference implementation is cited in .

Introduction In 2026, multiple commercial LLM platforms ship memory features that persist user identity, preferences, and prior decisions across sessions. Each platform serializes that memory in a vendor-specific schema, producing lock-in for the user and friction for downstream tooling such as audit, compliance, and migration. This document defines the AIMEM Bundle Format, an interchange container that decouples three concerns: Layer Concern Encoding What agent memory looks like on disk Transport How memory bundles move between systems Reasoning How an LLM uses recalled memory This specification standardises only the encoding and transport layers. The reasoning layer is left to each implementation, in keeping with the HTTP precedent of standardising the wire while leaving rendering to browsers.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Bundle:

A self-contained JSON document representing the complete or partial agent memory of one Tenant.

Tenant:

The principal who owns a Bundle's contents, identified by an implementation-defined identifier (URI, UUID, or DID per ).

Producer:

An implementation that serialises agent memory into a Bundle.

Consumer:

An implementation that ingests a Bundle and reconstructs the agent memory in its own storage.

Bidirectional:

An implementation that is both Producer and Consumer for the same Bundle scope.

Chunk:

An atomic memory record. A Bundle contains zero or more Chunks.

DNA-class memory:

A Chunk whose memory_type is one of preference, decision, identity, pitfall, or procedure. DNA-class memory MUST NOT be silently decayed or deleted by any implementation; see .

Producer Namespace:

An opaque, lower-case ASCII identifier (1-63 chars, [a-z0-9-]) that uniquely identifies the originating Producer instance. See .

Bundle Format A Bundle is a UTF-8 JSON document conforming to .

Required Envelope A Bundle MUST contain the following top-level fields:

The format field MUST be the string "aimem-bundle". The legacy value "memoryai-bundle" MAY be accepted by Consumers for backwards compatibility with implementations published before this revision. The version field MUST be "1" for this specification. The producer field MUST be a Producer Namespace (see ). It identifies the implementation that emitted the Bundle and is the namespace under which chunk.id values are interpreted. The tenant_id field MUST be either a UUID per RFC 4122 or a URI (including a DID per ). The exported_at field MUST be an ISO-8601 timestamp in UTC. The scope field MUST be one of "FULL", "DNA_ONLY", or "SINCE". When the scope is "SINCE", the envelope MUST include a since field (ISO-8601) marking the lower bound of the time window. The checksum field MUST be computed per . If any Chunk in the Bundle includes an embedding, the envelope MUST include embedding_dim (integer) and embedding_model (string). See .

ChunkRecord Each entry in chunks MUST be an object with the following normative fields:

The id field MUST conform to . The content field MUST be a non-empty UTF-8 string. Implementations MAY enforce a maximum length but MUST accept strings up to 65,536 codepoints. The content_hash field, if present, MUST be a lowercase sha256:<hex> over the UTF-8 bytes of content. Consumers MUST verify the hash on import and reject the Chunk on mismatch (HTTP 422 or equivalent error). The memory_type field MUST be one of: fact, preference, decision, identity, pitfall, procedure, episodic, goal. The five DNA-class types — preference, decision, identity, pitfall, procedure — carry the additional invariant defined in . The zone field, if present, MUST be one of critical, important, or standard. The is_pinned field, if present, MUST be a boolean. Pinned Chunks share the DNA-class invariant defined in . The created_at field MUST be an ISO-8601 UTC timestamp. The tags field, if present, MUST be a JSON array of strings, each 1-64 codepoints, lowercase ASCII recommended. The embedding field, if present, MUST be encoded per .

Chunk identifier Chunk identifiers MUST be URNs of the form urn:aimem:<producer>:<local> per where: <producer> is the Producer Namespace (lowercase ASCII, [a-z0-9-], 1-63 chars), identical to the producer envelope field. Producer Namespace assignment is by self-declaration; conflicts are resolved by domain ownership convention (a Producer SHOULD use a prefix derived from a domain it controls, e.g. memoryai-prod from memoryai.dev). <local> is an opaque identifier unique within <producer>, of any printable ASCII ([\x21-\x7E]) up to 256 chars, excluding : and whitespace. Consumers MUST treat id as opaque and MUST NOT parse semantics from it beyond the namespace prefix. Re-importing a Bundle with the same (producer, local) pair MUST be idempotent (see ).

Edges The edges field, if present, MUST be a JSON array of objects with the following normative fields:

The edge_type field MUST be one of hebbian, semantic, temporal, causal, or an implementation-defined value prefixed with x-. The weight field MUST be a number in the closed interval [0.0, 1.0]. Both source_id and target_id MUST reference id values present in the same Bundle's chunks array, or the Consumer MUST reject the Bundle with a 422.

Entities The entities field, if present, MUST be a JSON array of objects with the following normative fields:

The kind field MUST be one of person, organization, place, technology, concept, or an implementation-defined value prefixed with x-.

Chunk-entity links The chunk_entities field, if present, MUST be a JSON array of objects linking Chunks to Entities:

Both chunk_id and entity_id MUST reference URNs present in the same Bundle.

Embedding encoding When a Chunk includes an embedding: The Chunk's embedding field MUST be a base64-encoded little-endian float32 array. The envelope MUST declare embedding_dim (integer) — the array length. The envelope MUST declare embedding_model (string) — the model identifier under which the vector was produced (e.g. "text-embedding-3-small", "bge-large-en-v1.5"). A Consumer that does not support embedding_model MAY drop the embeddings (treating the Bundle as if embedding were null on every Chunk) and MUST emit a structured warning identifying the unsupported model. The Consumer MUST NOT silently re-embed Chunks under a different model when ingesting; re-embedding is a separate, explicit operation out of scope for this specification.

Checksum The checksum field MUST be computed as follows: Remove the checksum field from the envelope. Serialise the resulting object using JSON Canonicalization Scheme (). Compute SHA-256 over the UTF-8 bytes. Encode as "sha256:" + lowercase_hex(digest). A Consumer MUST verify the checksum before importing. Verification failure MUST result in HTTP 409 (Conflict) when the Bundle is delivered over HTTP, or an equivalent application-level error otherwise.

Idempotency rules Consumers MUST treat re-imports as idempotent on the URN (producer, local) pair. On re-import: If the Chunk already exists with identical content_hash and created_at, the Consumer MUST treat the import as a no-op. If content_hash differs but created_at matches, the Consumer MUST reject the Chunk with a structured error citing the conflict. If created_at is newer than the stored value, the Consumer MAY either reject or update at its discretion; the chosen behaviour MUST be documented.

HTTP Profile The following endpoints are RECOMMENDED for implementations that expose Bundles over HTTP .

Export GET /v1/brain/export?scope={FULL|DNA_ONLY|SINCE}&since={ISO-8601} A 200 response MUST contain the Bundle JSON with the application/aimem-bundle+json media type. A 401 response indicates missing authentication. A 403 response indicates the caller has no export scope on the Tenant. For Bundles whose serialised body would exceed 16 MiB, Producers SHOULD support a streaming variant returning newline-delimited JSON (application/x-ndjson) at GET /v1/brain/export/stream. The first line MUST be the envelope (without the chunks, edges, entities, chunk_entities arrays); subsequent lines MUST be objects of one of those record types each tagged with a _kind field ("chunk", "edge", "entity", "chunk_entity").

Import POST /v1/brain/import The request body MUST be a Bundle. A 200 response indicates a successful ingest with a summary of inserted, updated, and skipped Chunks. A 409 response indicates checksum mismatch. A 422 response indicates a malformed Bundle (envelope missing fields, invalid URN, edge references unknown chunk, etc.). Errors SHOULD use the format defined in .

Conformance Levels A Producer (Level 1) MUST emit a Bundle that round-trips through itself when re-imported, in conformance with . A Consumer (Level 2) MUST ingest any Bundle that conforms to . A Bidirectional implementation (Level 3) MUST satisfy both, AND a Bundle exported from such an implementation MUST be importable into the same implementation as a no-op (idempotent re-import). A test corpus exercising each conformance level is included with the informative reference implementation cited in .

Security Considerations

DNA-class invariant Implementations MUST NOT silently decay, delete, or supersede DNA-class Chunks (see ) during background processing. Explicit user-initiated deletion MUST be honoured (see ); implicit decay MUST NOT. The reasoning is operational: a user's identity claims and previously recorded decisions are higher-cost-to-lose than incidental facts. Implementations that decay them silently produce a privacy harm (loss of user-stated history without consent) and a correctness harm (divergent agent behaviour after decay).

Right to erasure When a Tenant exercises a right-to-erasure request such as , conforming implementations MUST: Hard-delete every Chunk for that Tenant, cascading through any per-tenant derivative tables (edges, entity links, recall logs, audit logs that contain content rather than hashes). Decrement reference counts on globally shared content pools and trigger orphan cleanup. Filter the Tenant's data out of any subsequent Bundle export, even if the export request precedes the cascade by milliseconds (i.e. erasure is durable from the user's perspective). Implementations SHOULD record the erasure event in a tamper-evident audit log so an auditor can reconstruct that erasure occurred without recovering what was erased.

Bundle authenticity When a Bundle crosses a trust boundary (e.g. ingest from a third party), Consumers SHOULD verify the Producer's signature over the canonicalised Bundle bytes using a detached COSE_Sign1 signature . The signature MUST be carried in the AIMEM-Signature HTTP header for HTTP transports, or in a sibling file <bundle-name>.sig for at-rest exchange. The signature payload MUST be the canonical JSON form of the Bundle as produced for the checksum (see ). Producers MAY publish their public key under /.well-known/aimem-pubkey, in COSE_Key format, to facilitate verification. Consumers that elect to skip signature verification (e.g. inside a trusted enclave) MUST log the decision in their audit trail.

Replay and idempotency Consumers MUST treat a re-imported Bundle as idempotent on chunk URN (within the Producer Namespace) per , and reject any field changes on a Chunk whose created_at matches a prior import. Replay attacks across trust boundaries are addressed by the Bundle-level signature defined in ; duplicate ingest within a trust boundary is addressed by URN idempotency.

Embedding privacy Embeddings can leak content under inversion attacks. Producers SHOULD NOT include embeddings in Bundles delivered to untrusted Consumers unless the Tenant has explicitly consented. Consumers receiving embeddings MUST treat them with the same access controls as the underlying content.

IANA Considerations This document requests the registration of the media type application/aimem-bundle+json per . The registration template is provided in .

Media type registration template

Intended usage: COMMON Author: Vu Duc Minh Change controller: IETF (after publication) ]]>

Versioning The version field is a string. Backwards-compatible additions MUST keep the same major version. Breaking changes MUST increment the major version and MUST NOT be silently accepted by Consumers — a v1 Consumer MUST reject a v2 Bundle with a 422 response.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.

Acknowledgments The author thanks the early implementers of the AIMEM Bundle Format for feedback on the conformance level structure and the embedding interop gap that motivated the embedding_model envelope field.