Specification v0.1.0-draft
Abstract
The Akashik Protocol defines a standard set of operations, data types, and behavioral contracts for enabling shared memory, contextual awareness, and coordination between multiple AI agents operating within a common system.
It is transport-agnostic, framework-agnostic, and designed to sit as the missing coordination layer beneath existing communication standards. Where MCP defines how an agent accesses tools and data, and A2A defines how agents communicate with each other, the Akashik Protocol defines what agents share, how they stay coordinated, and how they resolve contradictions — without a central controller.
0.1.0-draft represents the initial public release. Feedback, issues, and contributions are welcome at github.com/AkashikProtocol/spec.Status
| Version | 0.1.0-draft |
| Status | Draft |
| Published | March 2026 |
| Author | Sahil David |
| License | CC BY 4.0 |
Notation and Conventions
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 when, and only when, they appear in all capitals.
TypeScript-style interface definitions are used for readability throughout this specification. These are informational, not normative. The canonical data format is JSON as defined in the JSON Schema Reference. Implementations MAY use any programming language.
Terminology
| Term | Definition |
|---|---|
| Field | The shared knowledge space that all agents interact with. Holds memory units and manages relevance delivery. |
| Agent | An autonomous entity that reads from and writes to the Field. Each agent has an identity and a declared role. |
| Memory Unit | The atomic unit of knowledge. A single finding, decision, observation, or intention recorded by an agent. |
| Scope | A filter that determines which memory units an agent receives during attunement. |
| Intent | The stated purpose behind a memory unit — why it was recorded and what question it answers. |
| Epoch | A logical time value. Each operation advances the epoch. Used for causal ordering. |
| Session | A bounded period of coordinated agent activity with a defined goal. |
Design Principles
1. Intent Over Outcome
Every memory unit records not just what was found or decided, but why. The reasoning, assumptions, and confidence behind a finding are first-class citizens of the protocol. A memory unit without intent is invalid.
This ensures that any agent — or any human — can reconstruct the full reasoning chain behind any state of the system.
2. Attunement Over Search
Agents do not query a database. They declare their role, current task, and capabilities. The Field computes what is relevant and delivers it. Context finds the agent, not the other way around.
3. Temporal Awareness
The protocol distinguishes between what happened (past), what's true now (present), and what's planned (future). At minimum, operations are ordered using logical clocks. At higher conformance levels, three distinct temporal layers provide richer coordination.
4. Scoped Views of Shared State
Every agent sees a filtered, role-appropriate view of the underlying shared state. Scoping prevents context overload without creating isolation. Two agents with different roles, working on different tasks, receive different context from the same Field.
5. Self-Healing Coordination
Conflicts, stale state, and agent failures are expected — not exceptional. The protocol defines conflict detection, resolution strategies, and recovery mechanisms as core operations, not application-level afterthoughts.
Architecture
System Topology
A minimal Akashik deployment consists of one Field and two or more Agents. Agents register with the Field, record memory units, and attune to receive relevant context. The Field is the sole source of truth for shared state.
Protocol Stack
The Akashik Protocol sits between the application layer and the communication layer. It does not replace MCP or A2A — it complements them.
The Memory Protocol is the core specification. It defines shared memory operations that any multi-agent system can adopt independently.
The Coordination Extension is an optional, separate specification that adds task lifecycle management, agent-to-agent handoffs, and session management. Implementations MAY adopt the Memory Protocol without the Coordination Extension.
Scope of this Specification
Covered:
- The message envelope and wire format
- All data types with field-level definitions
- All core operations with request/response schemas and behavioral requirements
- Conformance levels and what each requires
- Transport bindings for Native SDK, MCP Server, and HTTP REST
- Security model and authority hierarchy
- Error codes and recovery guidance
Out of scope:
- Storage implementation details (left to implementors)
- Relevance scoring algorithms (the spec defines inputs/outputs; implementations choose the algorithm)
- Authentication mechanisms beyond the authority model
Conformance Levels
Implementations declare conformance at one of four levels. Each level is a strict superset of the previous.
| Level | Name | Description |
|---|---|---|
| 0 | Starter | The minimal viable implementation. REGISTER, RECORD, ATTUNE. Can be built in an afternoon. |
| 1 | Core | Memory persists. Events are ordered. Contradictions get flagged. Adds DEREGISTER, DETECT, durable log. |
| 2 | Standard | Relevance gets smart. Conflicts get resolved. Adds MERGE, SUBSCRIBE, REPLAY, COMPACT, semantic scoring. |
| 3 | Full | Production-grade orchestration with coordination, security, and full audit trails. Adds the Coordination Extension. |
Level 0 implementations MAY omit persistence, logical clocks, conflict detection, subscriptions, the Coordination Extension, and authentication.
Level 3 requires agent authentication, authority hierarchy enforcement, and at least two transport bindings.
Operations Summary
Memory Protocol (Core)
| Operation | Level | Purpose |
|---|---|---|
REGISTER | 0+ | Agent joins the Field |
DEREGISTER | 1+ | Agent leaves the Field |
RECORD | 0+ | Commit a memory unit |
ATTUNE | 0+ | Receive relevant context |
DETECT | 1+ | Identify conflicts |
MERGE | 2+ | Resolve conflicts |
SUBSCRIBE | 1+ | Register for updates |
REPLAY | 2+ | Reconstruct reasoning chains |
COMPACT | 2+ | Archive or summarize old memory |
Coordination Extension (Optional, Level 3)
| Operation | Level | Purpose |
|---|---|---|
COORDINATE | 3 | Manage task lifecycle |
HANDOFF | 2+ | Transfer task and context between agents |
SESSION | 3 | Manage session lifecycle |
Versioning
This specification follows Semantic Versioning (MAJOR.MINOR.PATCH).
- PATCH — clarifications, no behavioral change
- MINOR — new operations or optional fields, backward compatible
- MAJOR — breaking changes to message formats or behavioral requirements
Acknowledgments
The Akashik Protocol draws its name and conceptual model from the Akashic Records — the Vedantic concept of a universal field of knowledge where every thought, intention, and event is recorded and accessible through attunement, not search. This philosophy directly informs the protocol's design: intent-first memory, attunement over query, scoped views of shared truth.