Why Akashik Exists
The stateless agent problem
Every agent framework today builds memory from scratch — vector search, prompt injection, session dicts. None of it is shared, none of it is structured, and none of it handles contradictions.
The result: agents that forget, duplicate work, and produce conflicting outputs — even when running in the same system. Every project becomes custom glue code.
What MCP solves
Model Context Protocol (MCP) standardises tool invocation. An agent can call a function, read a file, or query a database through a single protocol. MCP is excellent at what it does.
What MCP does not address: persistent memory, shared context between agents, or coordination beyond individual tool calls.
What A2A solves
Agent-to-Agent (A2A) standardises agent messaging. Agents can send tasks, receive results, and stream progress through a single protocol. A2A is excellent at what it does.
What A2A does not address: where findings go after the call, how context accumulates across turns, or what happens when two agents disagree.
The gap
| Capability | MCP | A2A | Akashik |
|---|---|---|---|
| Tool invocation | ✓ | - | - |
| Agent messaging | - | ✓ | - |
| Shared memory | - | - | ✓ |
| Context accumulation | - | - | ✓ |
| Conflict detection | - | - | ✓ |
| Conflict resolution | - | - | ✓ |
| Intent tracking | - | - | ✓ |
| Audit trail | - | - | ✓ |
This gap is why every multi-agent system today carries its own ad-hoc memory layer — bespoke, fragile, non-interoperable.
The protocol stack
Akashik sits between the application layer and the communication layer:
| Layer | Protocol | Role |
|---|---|---|
| Application | Your agents | Business logic |
| Memory | Akashik | Shared memory, context, coordination |
| Communication | MCP / A2A | Tool calls, agent messaging |
| Transport | HTTP, stdio, WebSocket | Wire protocol |
Akashik defines the operations, data types, and behavioral contracts that the memory layer requires — so every system that implements the protocol gains interoperable, structured, intent-aware memory.
How it compares
| Capability | MCP | A2A | Akashik |
|---|---|---|---|
| State management | None | Minimal | Full (scoped, temporal) |
| Memory persistence | None | None | Event-sourced + configurable store |
| Conflict detection | None | None | Explicit (Level 1) + Automatic (Level 2) |
| Conflict resolution | None | None | 7 strategies |
| Semantic awareness | None | None | Embedding-based relevance (Level 2+) |
| Context scoping | None | None | Role, task, interest, budget-aware |
| Proactive delivery | None | Notifications | Attunement model + push subscriptions |
| Audit trail | None | Minimal | Full reasoning chain replay |
| Intent tracking | None | None | Required on every write |
| Relationship graph | None | None | 9 relation types |
These protocols are complementary, not competing. The Akashik Protocol is designed to work alongside MCP and A2A, not replace them.
The design philosophy
The protocol draws its name from the Akashic Records — the Vedantic concept of a universal field of knowledge where every thought and intention is recorded and accessible through attunement, not search. Five technical principles follow directly from that philosophy:
- Intent Over Outcome — every write records why, not just what
- Attunement Over Search — context finds the agent, not the other way around
- Temporal Awareness — past, present, and future coexist as first-class constructs
- Scoped Views — every agent sees a filtered, role-appropriate view of shared truth
- Self-Healing Coordination — conflicts and failures are expected, not exceptional