TL;DR: Every AI session starts from zero, and what memory exists
is locked to one vendor. .fafm fixes both — one open, IANA-registered
format your agent's memory lives in, readable by Grok, Claude, and Gemini alike.
Two reference implementations ship today.
Two profiles, one format
.fafm (application/vnd.fafm+yaml) is one format with two
profiles — and now two shipped, open reference implementations that point at each other:
- Voice — the Voice Memory Layer (VML). The original profile: durable memory for voice agents, so the assistant remembers you across calls. grok-faf-voice v0.3.2.
- Knowledge. Typed, cross-linked memory for agent runtimes like Claude Code. claude-fafm-sdk v0.1.1.
One core parser, one etch / recall / forget surface. No fork.
Try it — 30 seconds, offline
The local soul works with no account and no network:
uvx claude-fafm-sdk init Voice side, same shape:
pip install grok-faf-voice Your soul is a plain .fafm file you can read, diff, and commit to git.
memory.faf.one
When you want it hosted, memory.faf.one is the front door — one free namepoint where your soul lives, with full-intel recall at personal scale. Pay only when you scale, never to unlock the magic.
Cross-vendor, verified
This isn't a claim — it's a receipt. The same open client pulled live souls authored for Grok, Claude, and Gemini over the same protocol. One format, never trapped in one model's walled garden.
The paper
The format is documented in the companion white paper, Permanent Memory and Instant Recall: The .fafm Standard for Multi-Profile AI Agent Memory, published on Zenodo:
Receipts
- IANA-registered —
application/vnd.fafm+yaml(May 13, 2026) - claude-fafm-sdk v0.1.1 + grok-faf-voice v0.3.2 — both on PyPI, MIT
- Cross-linked — each PyPI page + README points at the other
- memory.faf.one — live (landing + MCP backend)
- Zenodo paper — DOI 10.5281/zenodo.20348942