Internet-Draft AIMEM Bundle June 2026
Minh Expires 16 December 2026 [Page]
Workgroup:
Independent Submission
Internet-Draft:
draft-vu-aimem-bundle-00
Published:
Intended Status:
Informational
Expires:
Author:
V. D. Minh
MemoryAI

Memory Interchange Bundle Format for AI Agents

Abstract

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 [GDPR-A17].

This document is self-contained: all schema fields normatively required by Producers and Consumers are defined inline. An informative reference implementation is cited in [AIMEM-REF].

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 16 December 2026.

▲

Table of Contents

1. 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:

Table 1
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.

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.2. 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 [W3C-DID]).

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 Section 5.

Producer Namespace:

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

2. Bundle Format

A Bundle is a UTF-8 JSON document conforming to [RFC8259].

2.1. Required Envelope

A Bundle MUST contain the following top-level fields:

{
  "format": "aimem-bundle",
  "version": "1",
  "producer": "memoryai-prod",
  "tenant_id": "11111111-1111-1111-1111-111111111111",
  "exported_at": "2026-06-12T10:00:00Z",
  "scope": "FULL",
  "checksum": "sha256:...",
  "chunks": [],
  "edges": [],
  "entities": [],
  "chunk_entities": []
}

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 Section 2.3). 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 [W3C-DID]).

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 Section 2.8.

If any Chunk in the Bundle includes an embedding, the envelope MUST include embedding_dim (integer) and embedding_model (string). See Section 2.7.

2.2. ChunkRecord

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

{
  "id": "urn:aimem:memoryai-prod:chunk-1",
  "content": "User prefers PostgreSQL over MongoDB.",
  "content_hash": "sha256:abcdef...",
  "memory_type": "preference",
  "zone": "important",
  "is_pinned": false,
  "created_at": "2026-04-01T09:30:00Z",
  "tags": ["db", "stack-choice"],
  "embedding": null
}

The id field MUST conform to Section 2.3.

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 Section 5.

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 Section 5.

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 Section 2.7.

2.3. Chunk identifier

Chunk identifiers MUST be URNs of the form

urn:aimem:<producer>:<local>

per [RFC8141] 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 Section 2.9).

2.4. Edges

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

{
  "source_id": "urn:aimem:memoryai-prod:chunk-1",
  "target_id": "urn:aimem:memoryai-prod:chunk-7",
  "edge_type": "hebbian",
  "weight": 0.42,
  "created_at": "2026-04-15T08:00:00Z"
}

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.

2.5. Entities

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

{
  "id": "urn:aimem:memoryai-prod:entity-7",
  "name": "PostgreSQL",
  "kind": "technology",
  "created_at": "2026-04-01T09:30:00Z"
}

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

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

{
  "chunk_id": "urn:aimem:memoryai-prod:chunk-1",
  "entity_id": "urn:aimem:memoryai-prod:entity-7"
}

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

2.7. Embedding encoding

When a Chunk includes an embedding:

  1. The Chunk's embedding field MUST be a base64-encoded [RFC4648] little-endian float32 array.

  2. The envelope MUST declare embedding_dim (integer) — the array length.

  3. 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.

2.8. Checksum

The checksum field MUST be computed as follows:

  1. Remove the checksum field from the envelope.

  2. Serialise the resulting object using JSON Canonicalization Scheme ([RFC8785]).

  3. Compute SHA-256 over the UTF-8 bytes.

  4. 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.

2.9. Idempotency rules

Consumers MUST treat re-imports as idempotent on the URN (producer, local) pair. On re-import:

  1. If the Chunk already exists with identical content_hash and created_at, the Consumer MUST treat the import as a no-op.

  2. If content_hash differs but created_at matches, the Consumer MUST reject the Chunk with a structured error citing the conflict.

  3. 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.

3. HTTP Profile

The following endpoints are RECOMMENDED for implementations that expose Bundles over HTTP [RFC9110].

3.1. 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").

3.2. 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 [RFC7807].

4. Conformance Levels

A Producer (Level 1) MUST emit a Bundle that round-trips through itself when re-imported, in conformance with Section 2.9.

A Consumer (Level 2) MUST ingest any Bundle that conforms to Section 2.

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 [AIMEM-REF].

5. Security Considerations

5.1. DNA-class invariant

Implementations MUST NOT silently decay, delete, or supersede DNA-class Chunks (see Section 1.2) during background processing. Explicit user-initiated deletion MUST be honoured (see Section 5.2); 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).

5.2. Right to erasure

When a Tenant exercises a right-to-erasure request such as [GDPR-A17], conforming implementations MUST:

  1. 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).

  2. Decrement reference counts on globally shared content pools and trigger orphan cleanup.

  3. 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.

5.3. 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 [RFC9052].

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 Section 2.8).

Producers MAY publish their public key under [RFC8615] /.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.

5.4. Replay and idempotency

Consumers MUST treat a re-imported Bundle as idempotent on chunk URN (within the Producer Namespace) per Section 2.9, 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 Section 5.3; duplicate ingest within a trust boundary is addressed by URN idempotency.

5.5. 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.

6. IANA Considerations

This document requests the registration of the media type application/aimem-bundle+json per [RFC8259]. The registration template is provided in Section 6.1.

6.1. Media type registration template 

Type name:        application
Subtype name:     aimem-bundle+json
Required parameters: none
Optional parameters: version (e.g. "1")
Encoding considerations: UTF-8 JSON
Security considerations: see Section 6 of this document
Interoperability considerations: see Section 5 of this document
Published specification: this document
Applications that use this media type: AI agent memory portability tools
Fragment identifier considerations: none
Restrictions on usage: none
Additional information:
  Magic number(s): N/A (UTF-8 JSON)
  File extension(s): .aimem.json
  Macintosh file type code: TEXT
Person & email address to contact:
  Vu Duc Minh <founder@memoryai.vn>
Intended usage: COMMON
Author: Vu Duc Minh
Change controller: IETF (after publication)

7. 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.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/rfc/rfc4648>.
[RFC8141]
Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, , <https://www.rfc-editor.org/rfc/rfc8141>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8785]
Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, , <https://www.rfc-editor.org/rfc/rfc8785>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.

8.2. Informative References

[AIMEM-REF]
Minh, V. D., "AIMEM Bundle Reference Implementation (Apache-2.0)", , <https://github.com/aimem-protocol/aimem-reference>.
[GDPR-A17]
"Regulation (EU) 2016/679 (GDPR), Article 17 — Right to erasure", , <https://eur-lex.europa.eu/eli/reg/2016/679/oj>.
[RFC7807]
Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, , <https://www.rfc-editor.org/rfc/rfc7807>.
[RFC8615]
Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, , <https://www.rfc-editor.org/rfc/rfc8615>.
[W3C-DID]
Group, W. D. W., "Decentralized Identifiers (DIDs) v1.0", , <https://www.w3.org/TR/did-core/>.

Appendix A. 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.

Author's Address

Vu Duc Minh
MemoryAI
Vietnam