Roadmap

Where things stand

v0.2.0 is live. The protocol is in active development toward full Level 1 conformance.

Releases

v0.1.0 — Partial Level 0 ✓

• createField with in-memory store
• write with mandatory intent
• read — declarative query
• attune — keyword-based relevance ranking

v0.2.0 — Full Level 0 + selected Level 1 ✓

• Standard message envelope
• register / deregister with capability exchange
• Relevance scoring across topic, role, recency, and intent quality
• Draft lifecycle: draft, commit, discard
• retract — author-only, idempotent
• supersede — replace with a chain extension (any agent)
• reckon — attune plus mechanical conflict detection

v0.3 — Full Level 1

• Persistent storage (file-based and SQLite)
• Append-only event log
• Full Lamport logical clocks
• confidence block on committed writes
• REPLAY operation
• since_epoch polling on attune

v0.4 — Level 2 (Semantic)

• Vector embeddings for memory unit content
• Semantic relevance scoring in attune
• Automatic conflict detection (scan mode)
• MERGE operation with resolution strategies
• SUBSCRIBE with push delivery (WebSocket / SSE)

v0.5 — Level 3 (Transport)

• MCP Server binding — any MCP-compatible agent gets shared memory for free
• HTTP REST binding — language-agnostic API with OpenAPI spec
• Full security model, authority hierarchy

Ecosystem

Open Questions

These are real design decisions being worked through now. If you've built multi-agent systems and hit these walls, your input would be genuinely valuable.

Open an issue on GitHub →

1. Relation Weights — Define or Remove?

MemoryUnits can declare relationships (supports, contradicts, depends_on, etc.). Should relationships carry a weight (0.0–1.0) with formally defined semantics, or stay binary for simplicity?

The tension: Weights enable nuanced graph traversal in ATTUNE scoring. But they add complexity and are hard to set correctly without guidance.

2. Embedding Standardization

The protocol supports semantic attunement via vector embeddings at Level 2+. Should the spec mandate a baseline embedding format for cross-implementation interoperability, or leave it fully up to each implementation?

The tension: Standardization enables interop between implementations. Flexibility enables best-in-class embeddings for each use case.

3. Draft Enrichment

When an agent records a quick, lightweight draft, should the Field be able to auto-enrich it (generate confidence scores, infer intent from content), or should enrichment always require an explicit agent action?

The tension: Auto-enrichment reduces friction for quick captures. Explicit actions preserve the principle that every write is intentional.

4. Cross-Session Memory

Currently, memory is scoped to a Field instance. Should there be a standard way for memory to persist and be queried across sessions — a "global Field" concept?

The tension: Cross-session memory enables longitudinal agent knowledge. But it raises hard questions about scope, privacy, and garbage collection.

5. Conflict Detection Boundaries

Should DETECT and MERGE stay in the core Memory Protocol, or be split into a separate optional extension for simpler adoption at lower levels?

The tension: Keeping it in core means all implementations handle conflict consistently. Moving it to an extension reduces the Level 0–1 surface area significantly.

How to contribute

The spec is in active development and the SDK is shipping fast. Now is the best time to shape it.

• Weigh in on the open questions above — these are real decisions being made right now
• Open issues for gaps, contradictions, or unclear sections
• Share your use cases — what would you build if your agents could share memory?
• Star the repos if you think this gap needs filling

If you're building multi-agent systems and you've hit the stateless agent wall — we'd love to hear from you.