Skip to toolbar

Community & Business Groups

Charter — AI Agent Memory Interoperability Community Group (v1.0)

Russell Jackson | Posted on:

Group: AI Agent Memory Interoperability Community Group
Group home: https://www.w3.org/community/ai-agent-memory-interop/
Short name: ai-agent-memory-interop
Status: v1.0 — Adopted
Adopted: 2026-06-19 (call for consensus circulated 2026-06-05; carried absent sustained objection per §9)

This Group elects to adopt a charter — optional under the W3C Community Group process — to fix its scope before technical work begins. This v1.0 charter was adopted by Group consensus on 19 June 2026: the call for consensus was circulated on 5 June 2026 and carried absent sustained objection per §9. It governs the Group’s work and may be revised per the Amendments section (§11).

1. Goals

The mission of the AI Agent Memory Interoperability Community Group is to make AI agent memory portable and verifiable across vendors, models, agent frameworks, and tool ecosystems by developing, in the open and royalty-free:

  • cross-vendor interoperability profiles,
  • a documented use-case catalogue, and
  • a conformance and test surface (criteria, test vectors, and a test suite)

that build upon and normatively reference an externally-maintained protocol specification for AI agent memory, rather than re-specifying that protocol within this Group.

The Group operates one layer above the protocol. Its purpose is to help independent implementations interoperate and to let adopters verify conformance — not to define, fork, or maintain a second copy of the underlying protocol.

2. Referenced protocol specification

The normative definition of the AI agent memory protocol — the memory-cell shape and encoding, the cryptographic envelope and key derivation, the identity/signature binding, the audit-anchor receipt, the sharing contracts, and the cryptographic-erasure mechanism — is maintained outside this Group, in the IETF Independent Submission Stream document draft-saihm-memory-protocol (https://datatracker.ietf.org/doc/draft-saihm-memory-protocol/).

All Group deliverables reference that document normatively. Where this charter names a protocol element (e.g. an ML-DSA-65 identity binding or an HKDF-derived per-cell key), it does so only to scope interoperability and conformance guidance for the element as defined in the referenced specification — never to redefine it.

2.1 Relationship to the IETF Independent Submission (scope restriction)

draft-saihm-memory-protocol is under consideration in the IETF Independent Submission Stream. While that submission is under the Independent Submissions Editor’s consideration, this Group will not develop or publish a competing normative specification of the protocol — that is, the Group will not produce a document that normatively defines the protocol’s wire format, cryptographic constructions, key derivation, identity binding, or erasure mechanism independently of the referenced document.

This restriction is a deliberate de-confliction measure so that the Group’s work complements, rather than interferes with, the evolution of the protocol in its single normative home. The restriction remains in force until the IETF Independent Submission concludes (the document is published as an RFC, or is withdrawn or declined). After that point the Group may, by the Amendments process, reconsider whether to host normative work — and if it intends to, it will coordinate with the relevant editor before doing so.

3. Scope

In scope:

  • Interoperability profiles that constrain or clarify use of the referenced protocol for specific deployment contexts (for example: a baseline cross-vendor interoperability profile; a profile for regulated-data deployments), adding interoperability guidance without adding new normative protocol elements.
  • A use-case catalogue capturing how portability, verifiable erasure, and cross-vendor migration are exercised in practice.
  • Conformance criteria, test vectors, and a test suite by which an implementation can demonstrate conformance to the referenced specification and to the Group’s profiles.
  • A regulatory crosswalk pack (informative): mappings from the referenced protocol’s capabilities to GDPR Article 17, the EU AI Act (Regulation (EU) 2024/1689), NIST AI RMF 1.0, ISO/IEC 27001:2022, ISO/IEC 42001:2023, and comparable regimes (HIPAA, PIPEDA, PIPL, LGPD).
  • Liaison and coordination notes with the forums listed in §6.

4. Out of scope

  • Normative (re-)specification of the AI agent memory protocol itself. The cell format and encoding, the cryptographic envelope and key derivation, the identity/signature binding, the audit-anchor receipt, the sharing contracts, and the erasure mechanism are defined normatively only in the referenced specification (§2); this Group references them and does not redefine, version, or fork them. See also the time-bound restriction in §2.1.
  • Selection or endorsement of any specific blockchain or ledger (the referenced protocol is chain-agnostic).
  • Vector-database or embedding-store semantics (orthogonal to memory portability).
  • Agent runtime semantics (addressed in other forums).
  • Tool-routing or tool-invocation semantics (addressed by the Model Context Protocol and its host foundation).

5. Deliverables

Each deliverable is a Community Group Report (or test software) that normatively references draft-saihm-memory-protocol. None re-specifies the protocol.

First 12 months (target):

  1. Use-case catalogue — portability, verifiable erasure, cross-vendor migration, regulated-data handling.
  2. Baseline interoperability profile — the minimum interoperability guidance two independent implementations need to exchange and verify memory cells per the referenced specification.
  3. Conformance and test-vector pack — conformance criteria plus published test vectors for the referenced protocol’s encoding, identity binding, envelope, and erasure-receipt verification.
  4. Regulatory crosswalk pack (informative) — the mappings enumerated in §3.

Candidate later work (subject to participant interest and §2.1):

  • A regulated-data interoperability profile.
  • An open-source conformance test suite exercising the test vectors.

The Group expects to publish work as it stabilises and to maintain an errata/issues list against each Report.

5.1 Normative status / limitation

Per the W3C process, a Community Group does not produce W3C Recommendations or other W3C standards. Group deliverables are Community Group Reports. A Report may, if the Group elects, be advanced to a Final Specification under the W3C Community Final Specification Agreement; this provides patent commitments but is still not a W3C Recommendation. Placing any work on the W3C Recommendation track would require transitioning the work to a W3C Working Group under a separate, Member-reviewed charter. This charter does not commit W3C or its Members to any such transition.

6. Dependencies and liaisons

  • IETF Independent Submission Stream — the normative home of the referenced protocol and this Group’s primary upstream dependency. The Group tracks the document’s status and aligns its profiles and test vectors to the published text. Coordination is conducted with respect for the restriction in §2.1.
  • Agentic AI Foundation (AAIF, Linux Foundation) — hosts the reference implementation and surrounding ecosystem; a contribution/implementation track that this Group’s specifications are intended to serve.
  • NIST — the AI RMF and related guidance, engaged via use-case and public-comment contributions; informative crosswalk only.
  • ISO/IEC JTC 1/SC 42 — a possible future track via national-body engagement; this Group’s output is intended to be cite-able by an SC 42 New Work Item Proposal should SC 42 choose to engage. No commitment is implied.

7. Community Group Process and contribution mechanics

This Group operates under the W3C Community and Business Group Process and the W3C Community Contributor License Agreement (CLA):

  • Anyone may participate by creating a W3C account, joining the Group at https://www.w3.org/community/ai-agent-memory-interop/join, and agreeing to the CLA.
  • Substantive contributions to a specification are made under the CLA. Should the Group take a specification to a Final Specification, participants commit under the W3C Community Final Specification Agreement (royalty-free patent commitments).
  • The reference implementation is published under the Apache License 2.0; the Group’s IPR mode is Royalty-Free.
  • All technical work — drafts, issues, decisions, and minutes — is conducted in public.

8. Communication

9. Decision process

The Group seeks consensus. Where a decision is needed:

  1. The Chair calls for consensus on the list or in a minuted meeting.
  2. Absent sustained objection, the proposal carries.
  3. A participant who disagrees may record a formal objection; the Chair responds on the record and, where warranted, escalates per the W3C Community Group process.

Decisions made in a meeting are confirmed on the public list so that participants who could not attend can weigh in. Substantive decisions are not made off-list.

10. Chair / convener

The Group is convened and chaired by Russell Jackson (W3C handle saihm, W3C user 177015 — https://www.w3.org/users/177015/).

The convener serves as initial Chair. The Group is vendor-neutral and open to all implementers; participation and membership do not imply endorsement of any implementation, including any maintained by the Chair. The Group may select or add Chairs by the decision process in §9. Group contact is via the public mailing list (§8).

11. Amendments to this charter

This charter may be amended by the decision process in §9. Proposed amendments are circulated on the public list with at least a stated review period before adoption. Amendments that would broaden scope into normative protocol specification are additionally subject to §2.1 (the IETF-submission restriction) for as long as that restriction is in force. The charter version and date are updated on each adopted amendment.

12. References

Leave a Reply

Your email address will not be published. Required fields are marked *

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.

*

Archives

Categories