Roadmap
Where things stand
The protocol is in active development. The spec is published. The reference implementation is being built.
Phases
Now — Specification & Architecture
- Protocol spec
v0.1.0-draftpublished - Core data types and state machines defined
- Nine operations fully specified
- Conformance levels (0–3) with normative requirements
- Error model and partial failure semantics
- JSON Schema reference for all message types
Next — Reference Implementation
@akashikprotocol/core— TypeScript SDK starting at Level 0- In-memory Field, REGISTER, RECORD, ATTUNE
- File-based and SQLite persistence (Level 1)
- Working examples you can run in 5 minutes
@akashikprotocol/core is available on npm now. Currently in active development toward a stable Level 0 release.Then — Transport Bindings & Level 2
- MCP Server — any MCP-compatible agent gets shared memory for free
- HTTP REST — language-agnostic API with OpenAPI spec
- Semantic ATTUNE with embeddings
- DETECT + MERGE operations (conflict resolution)
- Push notifications via WebSocket/SSE
After — Community & Adoption
- Conformance test suite
- A2A agent card binding
- First external implementations
- Conference talks and deep-dives
Ecosystem
| Package | Description | Status |
|---|---|---|
@akashikprotocol/core | Reference implementation — Field, agents, RECORD, ATTUNE | Building |
@akashikprotocol/mcp | MCP server binding — expose Akashik as MCP tools | Planned |
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.
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
This is early. The spec is in active development and the SDK is being built. That means 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.