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.

1. Notation and Conventions
2. Design Principles
3. Architecture
4. Core Concepts
5. Data Types
6. Protocol Operations
7. State Machines
8. Error Model
9. Conformance Levels
10. Transport Bindings
11. Security
12. Future Work
13. Appendix A: Wire Format Examples
14. Appendix B: Protocol Comparison
15. Appendix C: JSON Schema Reference

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 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here.

This specification uses TypeScript-style interface definitions for readability. These are informational, not normative. The canonical data format is JSON as defined in the JSON Schema Reference (Appendix C). Implementations MAY use any programming language.

The Akashik Protocol is built on five design principles. These inform every operation, data type, and behavioral contract in the specification.

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.

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.

This means the ATTUNE operation returns a scoped, ranked view of shared memory - not raw search results. Relevance is computed by the Field, not the agent.

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.

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.

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.

A minimal Akashik deployment consists of one Field and two or more Agents.

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. It builds on top of the Memory Protocol. Implementations MAY adopt the Memory Protocol without the Coordination Extension.

The Field is the shared knowledge space. All agents interact with the same Field. The Field is responsible for:

• Storing memory units committed by agents
• Computing relevance when an agent attunes
• Detecting conflicts between memory units
• Maintaining the event log for auditability
• Managing agent registration and scoping

The Field is a logical concept. It MAY be implemented as an in-memory store, a file-backed store, a database, or a distributed system. The protocol defines the behavioral contract, not the implementation.

A memory unit is the atomic unit of knowledge in the protocol. Every finding, decision, observation, question, or intention recorded by an agent is a memory unit.

Two properties distinguish Akashik memory units from generic data storage:

Intent is required. Every memory unit MUST include an intent field that declares why it was recorded. A memory unit without intent is invalid and MUST be rejected by the Field. This ensures that any agent examining shared memory can understand not just what was found, but what question it was answering and what task it was serving.

Confidence is explicit. At Level 1 and above, every committed memory unit MUST include a confidence score and the reasoning behind that score. This creates an auditable chain where the certainty of every finding is transparent.

Memory units are immutable once committed. A committed memory unit's content MUST NOT be modified. To update or correct information, an agent records a new memory unit with a supersedes or correction relation pointing to the original.

Attunement is the mechanism by which agents receive relevant context from the Field.

Unlike traditional query-based systems, agents do not formulate search queries. Instead, an agent declares its identity (role, interests, current task) and the Field computes and delivers the most relevant memory units.

The implementation of relevance computation varies by conformance level:

• Level 0: Keyword-based matching against the agent's role
• Level 1: Keyword-based matching with epoch-aware ordering
• Level 2+: Semantic similarity using vector embeddings, multi-factor scoring, and token budget management

At all levels, the agent-facing operation is the same: the agent calls ATTUNE and receives a ranked set of relevant memory units. The intelligence is in the Field, not in the agent.

An agent is any autonomous entity that interacts with the Field. Agents MUST register with the Field before performing any operations. At minimum, an agent declares an identifier and a role.

The protocol does not prescribe what an agent is internally - it may be an LLM, a deterministic script, a human operator, or any other entity capable of sending protocol messages.

A conflict exists when two or more memory units contain contradictory claims about the same entity, fact, or decision. The protocol treats conflicts as expected events, not errors. Conflicts are detected automatically (at Level 2+) or declared explicitly by agents, and resolved through structured strategies.

Every protocol message MUST use this envelope structure.

{
  "protocol": "akashik",
  "version": "0.1.0",
  "id": "<string>",
  "operation": "<OperationType>",
  "agent_id": "<string>",
  "session_id": "<string | null>",
  "epoch": <number>,
  "payload": { ... }
}

The atomic unit of knowledge. Immutable once committed.

{
  "id": "<string>",
  "mode": "draft | committed",
  "type": "<MemoryType>",
  "content": "<string>",
  "intent": {
    "purpose": "<string>",
    "task_id": "<string | null>",
    "question": "<string | null>"
  },
  "confidence": {
    "score": <number>,
    "reasoning": "<string>",
    "evidence": ["<string>"],
    "assumptions": ["<string>"]
  },
  "source": {
    "agent_id": "<string>",
    "agent_role": "<string>",
    "session_id": "<string | null>",
    "timestamp": "<ISO 8601>"
  },
  "relations": [<Relation>],
  "status": "active | draft | superseded | retracted | contested | pending_enrichment",
  "epoch": <number>
}

Required fields vary by mode:

Draft mode allows lightweight, low-ceremony recording. The Field or a downstream agent MAY enrich a draft into a committed unit by adding confidence and additional metadata.

Committed mode enforces full validation. At Level 0, intent.purpose is the only required field beyond type and content. At Level 1+, confidence.score and confidence.reasoning are also required.

The Field MUST auto-generate id, epoch, source.agent_id, source.agent_role, source.timestamp, and status on every RECORD. Agents MUST NOT set these fields manually.

MemoryType = "finding" | "decision" | "observation" | "intention"
           | "assumption" | "constraint" | "question" | "contradiction"
           | "synthesis" | "correction" | "human_directive"

Implementations MAY extend this set with additional types. Implementations MUST support at minimum: finding, decision, observation, and question.

{
  "type": "<RelationType>",
  "target_id": "<string>",
  "description": "<string | null>"
}

RelationType = "supports" | "contradicts" | "depends_on" | "supersedes"
             | "caused_by" | "elaborates" | "answers" | "blocks" | "informs"

{
  "id": "<string>",
  "role": "<string>",
  "status": "idle | working | waiting | offline | failed",
  "interests": ["<string>"],
  "current_task_id": "<string | null>"
}

Scope controls what an agent receives during attunement.

Required Scope (all conformance levels MUST support):

{
  "role": "<string>",
  "max_units": <number>
}

Extended Scope (Level 2+ SHOULD support):

{
  "role": "<string>",
  "max_units": <number>,
  "max_tokens": <number>,
  "interests": ["<string>"],
  "active_task_id": "<string | null>",
  "temporal_layers": ["past", "present", "future"],
  "relevance_threshold": <number>,
  "recency_weight": <number>,
  "since_epoch": <number | null>
}

{
  "id": "<string>",
  "type": "factual | interpretive | strategic | priority",
  "status": "detected | resolving | resolved | escalated",
  "unit_a": "<string>",
  "unit_b": "<string>",
  "description": "<string>",
  "detected_by": "explicit | semantic | logical | temporal",
  "resolution": {
    "strategy": "<ConflictStrategy>",
    "winner_id": "<string | null>",
    "rationale": "<string>",
    "resolved_by": "<string>",
    "epoch_resolved": <number>
  }
}

ConflictStrategy = "last_write_wins" | "confidence_weighted" | "authority"
                 | "evidence_count" | "synthesis" | "human_escalation" | "vote"

Memory Protocol (Core):

Coordination Extension (Optional, Level 3):

Purpose: Agent joins the Field and declares its identity.

Request payload:

{
  "id": "<string>",
  "role": "<string>",
  "interests": ["<string>"],
  "required_operations": ["<string>"]
}

Response payload:

{
  "status": "registered | rejected",
  "agent": <Agent>,
  "field_capabilities": {
    "conformance_level": <number>,
    "supported_operations": ["<string>"],
    "protocol_version": "<string>",
    "persistence": <boolean>,
    "conflict_strategies": ["<string>"]
  },
  "rejection_reason": "<string | null>"
}

Behavior:

1. The Field MUST validate that the agent id is unique among registered agents.
2. If required_operations is provided and the Field does not support all of them, the Field MUST reject the registration and return the missing operations in rejection_reason.
3. The Field MUST return its capabilities so the agent knows what features are available.
4. The Field MUST set the agent's initial status to "idle".

Purpose: Agent leaves the Field gracefully.

Level: 1+

Request payload:

{
  "agent_id": "<string>"
}

Response payload:

{
  "status": "ok | not_found",
  "cleanup": {
    "units_orphaned": <number>,
    "tasks_reassigned": <number>
  }
}

Behavior:

1. The Field MUST remove the agent from the registry.
2. Memory units previously recorded by this agent MUST NOT be deleted. They remain in the Field.
3. If the agent has assigned tasks (Coordination Extension), the Field SHOULD flag them for reassignment.

Purpose: Commit a memory unit to the Field.

This is the only way to add knowledge to shared memory. Every write goes through RECORD.

Request payload:

{
  "mode": "draft | committed",
  "type": "<MemoryType>",
  "content": "<string>",
  "intent": {
    "purpose": "<string>",
    "task_id": "<string | null>",
    "question": "<string | null>"
  },
  "confidence": {
    "score": <number>,
    "reasoning": "<string>",
    "evidence": ["<string>"],
    "assumptions": ["<string>"]
  },
  "relations": [<Relation>]
}

Required fields by mode and level:

Response payload:

{
  "status": "accepted | rejected",
  "memory_unit_id": "<string>",
  "epoch": <number>,
  "conflicts_detected": ["<string>"],
  "rejection_reason": "<string | null>"
}

Behavior:

1. The Field MUST validate the payload against the required fields for the given mode and conformance level.
2. If intent.purpose is missing or empty, the Field MUST reject the RECORD with error code MISSING_INTENT.
3. If confidence.score is required and missing, the Field MUST reject with MISSING_CONFIDENCE.
4. If confidence.score is present, it MUST be a number between 0.0 and 1.0 inclusive.
5. The Field MUST generate id, epoch, source, and status for the memory unit. Agents MUST NOT provide these.
6. For draft mode, the Field MUST set status to "draft".
7. For committed mode, the Field MUST set status to "active".
8. The Field MUST append the operation to the event log (Level 1+).
9. If any relations include a contradicts type, the Field MUST create a Conflict object (Level 1+).
10. If the Field supports semantic conflict detection (Level 2+), it SHOULD run detection against existing memory units and return any detected conflicts in conflicts_detected.
11. If the Field supports subscriptions, it SHOULD evaluate the new unit against active agent scopes and push notifications to matching agents.

Partial Failure:

• If the event log write succeeds but enrichment (embedding generation) fails, the Field MUST commit the unit with status "pending_enrichment" and include a warning in the response.
• If the event log write succeeds but conflict detection times out, the Field MUST commit the unit and return "conflicts_detected": [] with a "conflict_detection": "deferred" flag.

Purpose: Receive a contextually relevant, scoped view of shared memory.

The agent does not provide a search query. It declares who it is and what it needs. The Field computes relevance and returns ranked results.

Request payload:

{
  "scope": <Scope>,
  "context_hint": "<string | null>",
  "format": "full | summary | ids_only",
  "since_epoch": <number | null>
}

Response payload:

{
  "status": "ok",
  "record": [<ScopedMemoryUnit>],
  "conflicts": [<Conflict>],
  "context_budget": {
    "units_returned": <number>,
    "units_available": <number>,
    "tokens_used": <number | null>,
    "tokens_budget": <number | null>
  },
  "epoch": <number>
}

ScopedMemoryUnit = {
  "memory_unit": <MemoryUnit>,
  "relevance_score": <number>,
  "relevance_reason": "<string>",
  "format": "full | summary"
}

Behavior:

1. The Field MUST exclude memory units recorded by the requesting agent, unless the scope explicitly requests them.
2. The Field MUST exclude memory units with status "retracted" or "superseded".
3. The Field MUST score each candidate memory unit for relevance to the requesting agent.
4. The Field MUST sort results by relevance score in descending order.
5. The Field MUST truncate results to respect scope.max_units.
6. At Level 2+, the Field SHOULD also respect scope.max_tokens by estimating token counts and either including full content or summaries.
7. If since_epoch is provided, the Field MUST only return memory units committed at or after that epoch.
8. The Field MUST include unresolved conflicts relevant to the requesting agent in the conflicts array.
9. Each returned unit MUST include a relevance_score (0.0 to 1.0) and a human-readable relevance_reason.

Relevance Scoring:

The protocol does not prescribe a specific scoring algorithm. Implementations MUST produce a relevance score between 0.0 and 1.0 for each candidate. The following factors are RECOMMENDED:

• Recency: More recent memory units SHOULD score higher.
• Role alignment: Memory units related to the agent's role SHOULD score higher.
• Type importance: Decisions and contradictions SHOULD score higher than observations.
• Source diversity: Results SHOULD include memory units from multiple agents where possible.

At Level 2+, the following additional factors are RECOMMENDED:

• Semantic similarity: Using vector embeddings to measure content relevance.
• Task relevance: Memory units serving the same or dependent tasks SHOULD score higher.
• Relation proximity: Memory units connected via relations to the agent's current context SHOULD score higher.
• Confidence weighting: Higher-confidence units SHOULD score higher.

Purpose: Identify conflicts between memory units.

Level: 1+

Request payload:

{
  "mode": "check | scan | list",
  "target_id": "<string | null>",
  "filter": {
    "status": ["<string>"],
    "types": ["<string>"],
    "involving_agents": ["<string>"]
  }
}

Response payload:

{
  "status": "ok",
  "conflicts": [<Conflict>],
  "scan_coverage": {
    "units_scanned": <number>,
    "new_conflicts_found": <number>
  }
}

Behavior:

At Level 1, the Field MUST support list mode and MUST detect explicit conflicts (when a RECORD includes a contradicts relation). The Field MAY support check and scan modes.

At Level 2+, the Field MUST support all three modes and MUST implement at least one automatic detection method beyond explicit relations. Automatic detection methods include:

• Semantic detection: Memory units with high embedding similarity that contain opposing claims.
• Logical detection: A finding's assumptions contradict another finding's content.
• Temporal detection: A newer finding contradicts an established finding of higher confidence.

The protocol does not prescribe specific thresholds or algorithms for automatic detection. These are implementation decisions documented in the Reference Architecture guide.

Purpose: Resolve a detected conflict.

Level: 2+

Request payload:

{
  "conflict_id": "<string>",
  "strategy": "<ConflictStrategy>",
  "resolution": {
    "winner_id": "<string | null>",
    "synthesis": "<string | null>",
    "rationale": "<string>"
  }
}

Response payload:

{
  "status": "resolved | escalated | pending_vote",
  "conflict": <Conflict>,
  "side_effects": {
    "superseded_units": ["<string>"],
    "new_unit_id": "<string | null>",
    "notified_agents": ["<string>"]
  }
}

Behavior:

1. The Field MUST validate that the conflict exists and is in "detected" or "resolving" status.
2. If strategy is "synthesis", a new memory unit MUST be created from resolution.synthesis with relations pointing to both original units.
3. The losing unit (or both originals, in synthesis) MUST have its status set to "superseded".
4. The conflict status MUST be updated to "resolved" with the full resolution details.
5. The Field MUST notify agents who recorded the affected units.

Required strategies by level:

Purpose: Register for updates when relevant changes occur in the Field.

Level: 1+ (poll-based). Level 2+ (push-based).

Request payload:

{
  "action": "subscribe | unsubscribe | list",
  "subscription": {
    "id": "<string | null>",
    "events": ["<SubscriptionEvent>"],
    "min_relevance": <number | null>,
    "debounce_ms": <number | null>
  }
}

SubscriptionEvent = "memory.recorded" | "memory.superseded" | "memory.contested"
                  | "conflict.detected" | "conflict.resolved"
                  | "task.state_changed" | "task.assigned" | "task.completed"
                  | "handoff.incoming"
                  | "agent.joined" | "agent.failed"
                  | "session.paused" | "session.ended"

Push notification format (Level 2+):

{
  "subscription_id": "<string>",
  "event": "<SubscriptionEvent>",
  "epoch": <number>,
  "relevance_score": <number>,
  "summary": "<string>",
  "memory_unit_id": "<string | null>",
  "conflict_id": "<string | null>",
  "requires_action": <boolean>
}

Level 1 alternative - polling:

At Level 1, implementations that do not support push notifications MUST support the since_epoch parameter on ATTUNE. An agent polls for updates by calling ATTUNE with since_epoch set to the epoch returned in its last ATTUNE response. This provides eventual consistency without requiring a persistent connection.

Purpose: Reconstruct the full reasoning chain for a task, decision, or memory unit.

Level: 2+

Request payload:

{
  "target_type": "task | memory_unit | decision | conflict | session",
  "target_id": "<string>",
  "depth": "summary | detailed | full_trace"
}

Response payload:

{
  "status": "ok",
  "timeline": [<ReplayEvent>],
  "summary": "<string>",
  "agents_involved": ["<string>"],
  "total_events": <number>
}

ReplayEvent = {
  "epoch": <number>,
  "event_type": "<string>",
  "agent_id": "<string>",
  "description": "<string>",
  "memory_unit_id": "<string | null>",
  "task_id": "<string | null>"
}

Behavior:

1. The Field MUST reconstruct the event timeline by reading from the append-only event log.
2. At "summary" depth, the Field MUST return a human-readable summary and the list of involved agents.
3. At "full_trace" depth, the Field MUST return every event in the causal chain.

Purpose: Archive, summarize, or purge aged memory units.

Level: 2+

Request payload:

{
  "strategy": "summarize | archive | purge",
  "filter": {
    "max_age_epochs": <number | null>,
    "session_id": "<string | null>",
    "types": ["<MemoryType>"],
    "status": ["<string>"]
  }
}

Response payload:

{
  "status": "ok",
  "units_affected": <number>,
  "synthesis_units_created": <number>,
  "storage_reclaimed_bytes": <number | null>
}

Behavior:

1. COMPACT MUST NOT delete entries from the append-only event log, regardless of strategy.
2. For summarize, the Field MUST create new memory units of type "synthesis" with relations pointing to the originals.
3. For archive, archived units MUST be excluded from ATTUNE results unless the agent explicitly requests archived content.
4. For purge, the event log MUST retain a tombstone record (unit ID, deletion timestamp, reason).

All conformance levels that support DETECT MUST implement this state machine.

{
  "code": "<ErrorCode>",
  "message": "<string>",
  "operation": "<OperationType>",
  "recoverable": <boolean>,
  "suggested_action": "<string | null>"
}

Validation Errors:

Operational Errors:

System Errors:

Implementations declare conformance at one of four levels. Each level is a strict superset of the previous.

The minimal viable implementation. A developer can adopt this in an afternoon.

An implementation conforms to Level 0 if it:

1. Implements REGISTER with id and role fields.
2. Implements RECORD in both draft and committed modes.
3. Validates that intent.purpose is present and non-empty on every RECORD.
4. Rejects RECORD with MISSING_INTENT if intent is absent.
5. Auto-generates id, epoch, source, and status on every memory unit.
6. Implements ATTUNE with Required Scope (role, max_units).
7. Returns memory units scored and sorted by relevance (algorithm is implementation-defined).
8. Excludes the requesting agent's own memory units from ATTUNE results by default.
9. Excludes retracted and superseded memory units from ATTUNE results.
10. Returns relevance_score and relevance_reason for each result.
11. Uses the standard message envelope on all messages.

Level 0 MAY omit:

• Persistence (in-memory only is acceptable)
• Logical clocks (epoch MAY be a simple counter or 0)
• Conflict detection
• Subscriptions
• The Coordination Extension
• Authentication

Memory persists. Events are ordered. Contradictions get flagged.

An implementation conforms to Level 1 if it meets all Level 0 requirements AND:

1. Persists memory units to durable storage that survives process restarts.
2. Maintains an append-only event log of all operations.
3. Implements Lamport logical clocks: each operation increments the epoch; incoming messages update the local clock to max(local, received) + 1.
4. Requires confidence.score and confidence.reasoning on committed RECORD operations.
5. Implements DEREGISTER.
6. Implements DETECT in list mode.
7. Creates a Conflict object when a RECORD includes a contradicts relation.
8. Implements ATTUNE with since_epoch parameter for polling-based subscriptions.
9. Returns unresolved conflicts in the ATTUNE response.
10. Implements REGISTER with capability exchange (Field returns field_capabilities).

Relevance gets smart. Conflicts get resolved. Agents get notified.

An implementation conforms to Level 2 if it meets all Level 1 requirements AND:

1. Computes vector embeddings for memory unit content.
2. Implements semantic relevance scoring in ATTUNE using embeddings.
3. Supports Extended Scope fields: max_tokens, interests, active_task_id, relevance_threshold.
4. Implements token budget management in ATTUNE (truncation, summarization).
5. Implements DETECT in all three modes (check, scan, list) with at least one automatic detection method.
6. Implements MERGE with at least three strategies: last_write_wins, confidence_weighted, human_escalation.
7. Implements SUBSCRIBE with push notifications (WebSocket, SSE, or equivalent).
8. Implements HANDOFF with structured context packaging.
9. Implements REPLAY at all three depths.
10. Implements COMPACT with at least archive strategy.

Production-grade orchestration with coordination, security, and full audit trails.

An implementation conforms to Level 3 if it meets all Level 2 requirements AND:

1. Implements the Coordination Extension: COORDINATE, SESSION.
2. Implements the full task state machine with all transitions.
3. Implements MERGE with all seven conflict resolution strategies.
4. Supports agent authentication (at least token-based).
5. Enforces authority hierarchy for privileged operations.
6. Implements memory unit visibility rules (session scoping, role-based filtering).
7. Implements COMPACT with all three strategies.
8. Implements at least two transport bindings.

The Akashik Protocol is transport-agnostic. Operations MAY be carried over any communication layer. This specification defines bindings for common transports.

Direct API calls in the host language. Lowest latency, full feature support.

const field = new Field();
const agent = await field.register({ id: 'researcher', role: 'researcher' });

const unit = await agent.record({
  type: 'finding',
  content: 'Market growing at 23% CAGR',
  intent: { purpose: 'Validate market size' }
});

const context = await agent.attune({ max_units: 10 });

Exposes Akashik operations as MCP tools, enabling any MCP-compatible agent to use the protocol.

Limitation: MCP's request-response model cannot support real-time SUBSCRIBE push notifications. MCP-connected agents MUST use polling via ATTUNE with since_epoch.

POST /v1/register         → REGISTER
POST /v1/deregister       → DEREGISTER
POST /v1/record           → RECORD
POST /v1/attune           → ATTUNE
POST /v1/detect           → DETECT
POST /v1/merge            → MERGE
POST /v1/replay           → REPLAY
POST /v1/compact          → COMPACT
POST /v1/subscribe        → SUBSCRIBE (returns WebSocket URL for push)

GET  /v1/field/status     → Field overview
GET  /v1/agents           → Registered agents
GET  /v1/conflicts        → Active conflicts

All request and response bodies MUST use Content-Type: application/json and conform to the JSON Schema definitions in Appendix C.

At Level 3, operations are gated by authority level:

At Level 3, not all agents can see all memory units. Visibility is determined by:

1. Session membership: Agents MUST only see units from their active session.
2. Role-based rules: Configurable per session.
3. Authority level: Lower-authority agents MAY be restricted from certain memory types.

The following areas are planned for future specification versions. They are documented here to signal direction, not commitment.

Cross-Session Memory: A mechanism for memory units to persist and be accessible across sessions. The current specification scopes all memory to a single Field instance.

Temporal Layers: Full specification of three distinct temporal layers — Past Record (immutable event log), Present Record (mutable coordination state), Future Record (planned work as a directed acyclic graph). Currently, temporal awareness is limited to epoch ordering.

Embedding Standardization: Formal requirements for embedding interoperability, including dimensionality ranges, similarity metrics, and negotiation during REGISTER.

Conformance Test Suite: A standalone test suite that any implementation can run to verify conformance at each level.

Akashik Enhancement Proposals (AEPs): A formal process for community-driven protocol evolution, modeled after MCP's SEP process.

Step 1: Agent registers

{
  "protocol": "akashik",
  "version": "0.1.0",
  "id": "msg-001",
  "operation": "REGISTER",
  "agent_id": "researcher-01",
  "session_id": null,
  "epoch": 0,
  "payload": {
    "id": "researcher-01",
    "role": "market_researcher",
    "interests": ["market size", "competitors", "growth trends"]
  }
}

Response:

{
  "status": "registered",
  "agent": {
    "id": "researcher-01",
    "role": "market_researcher",
    "status": "idle",
    "interests": ["market size", "competitors", "growth trends"]
  },
  "field_capabilities": {
    "conformance_level": 1,
    "supported_operations": ["REGISTER", "DEREGISTER", "RECORD", "ATTUNE", "DETECT", "SUBSCRIBE"],
    "protocol_version": "0.1.0",
    "persistence": true,
    "conflict_strategies": []
  }
}

Step 2: Agent records a finding

{
  "protocol": "akashik",
  "version": "0.1.0",
  "id": "msg-002",
  "operation": "RECORD",
  "agent_id": "researcher-01",
  "session_id": null,
  "epoch": 1,
  "payload": {
    "mode": "committed",
    "type": "finding",
    "content": "European SaaS market for SMB HR tools is growing at 23% CAGR, expected to reach $4.2B by 2027. Primary growth driver is regulatory compliance automation post-EU AI Act.",
    "intent": {
      "purpose": "Validate market size assumption for go-to-market strategy",
      "task_id": "task-market-sizing",
      "question": "Is the European HR SaaS market large enough to justify a dedicated go-to-market?"
    },
    "confidence": {
      "score": 0.82,
      "reasoning": "Based on three independent analyst reports with consistent estimates. Slight uncertainty on AI Act impact timeline.",
      "evidence": ["https://example.com/report-a", "https://example.com/report-b"],
      "assumptions": ["EU AI Act enforcement begins Q3 2026", "No major EU recession in 2026-2027"]
    },
    "relations": [
      { "type": "answers", "target_id": "mem-question-001" }
    ]
  }
}

Response:

{
  "status": "accepted",
  "memory_unit_id": "mem-002",
  "epoch": 2,
  "conflicts_detected": []
}

Step 3: Another agent attunes

{
  "protocol": "akashik",
  "version": "0.1.0",
  "id": "msg-003",
  "operation": "ATTUNE",
  "agent_id": "strategist-01",
  "session_id": null,
  "epoch": 3,
  "payload": {
    "scope": {
      "role": "strategist",
      "max_units": 10
    },
    "context_hint": "About to draft competitive positioning section"
  }
}

Response:

{
  "status": "ok",
  "record": [
    {
      "memory_unit": {
        "id": "mem-002",
        "mode": "committed",
        "type": "finding",
        "content": "European SaaS market for SMB HR tools is growing at 23% CAGR, expected to reach $4.2B by 2027. Primary growth driver is regulatory compliance automation post-EU AI Act.",
        "intent": {
          "purpose": "Validate market size assumption for go-to-market strategy",
          "task_id": "task-market-sizing",
          "question": "Is the European HR SaaS market large enough to justify a dedicated go-to-market?"
        },
        "confidence": {
          "score": 0.82,
          "reasoning": "Based on three independent analyst reports with consistent estimates. Slight uncertainty on AI Act impact timeline.",
          "evidence": ["https://example.com/report-a", "https://example.com/report-b"],
          "assumptions": ["EU AI Act enforcement begins Q3 2026", "No major EU recession in 2026-2027"]
        },
        "source": {
          "agent_id": "researcher-01",
          "agent_role": "market_researcher",
          "session_id": null,
          "timestamp": "2026-03-01T10:30:00Z"
        },
        "relations": [
          { "type": "answers", "target_id": "mem-question-001" }
        ],
        "status": "active",
        "epoch": 2
      },
      "relevance_score": 0.85,
      "relevance_reason": "Recent finding from market_researcher. Market sizing is relevant to strategy.",
      "format": "full"
    }
  ],
  "conflicts": [],
  "context_budget": {
    "units_returned": 1,
    "units_available": 1,
    "tokens_used": null,
    "tokens_budget": null
  },
  "epoch": 3
}

Agent records a finding that contradicts an existing one:

{
  "protocol": "akashik",
  "version": "0.1.0",
  "id": "msg-010",
  "operation": "RECORD",
  "agent_id": "researcher-02",
  "session_id": null,
  "epoch": 10,
  "payload": {
    "mode": "committed",
    "type": "finding",
    "content": "European SaaS market growth is decelerating to 14% CAGR due to enterprise budget cuts in Q4 2026.",
    "intent": {
      "purpose": "Update market growth projection with latest data",
      "question": "Has the market growth trajectory changed?"
    },
    "confidence": {
      "score": 0.75,
      "reasoning": "Based on a single Q4 earnings report from a major player. May not represent the full market.",
      "assumptions": ["Q4 trends are indicative of 2027 trajectory"]
    },
    "relations": [
      {
        "type": "contradicts",
        "target_id": "mem-002",
        "description": "Original estimate was 23% CAGR; new data suggests 14%"
      }
    ]
  }
}

Response (conflict auto-created from explicit relation):

{
  "status": "accepted",
  "memory_unit_id": "mem-010",
  "epoch": 11,
  "conflicts_detected": ["conflict-001"]
}

Strategist's next ATTUNE now includes the conflict:

{
  "conflicts": [
    {
      "id": "conflict-001",
      "type": "factual",
      "status": "detected",
      "unit_a": "mem-002",
      "unit_b": "mem-010",
      "description": "Conflicting market growth estimates: 23% CAGR vs 14% CAGR",
      "detected_by": "explicit"
    }
  ]
}

These protocols are complementary, not competing. The Akashik Protocol is designed to work alongside MCP and A2A, not replace them.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://akashikprotocol.com/schema/0.1.0/envelope.json",
  "type": "object",
  "required": ["protocol", "version", "id", "operation", "agent_id", "session_id", "epoch", "payload"],
  "properties": {
    "protocol": { "type": "string", "const": "akashik" },
    "version": { "type": "string", "const": "0.1.0" },
    "id": { "type": "string", "minLength": 1 },
    "operation": {
      "type": "string",
      "enum": ["REGISTER", "DEREGISTER", "RECORD", "ATTUNE", "DETECT", "MERGE", "SUBSCRIBE", "REPLAY", "COMPACT", "COORDINATE", "HANDOFF", "SESSION"]
    },
    "agent_id": { "type": "string", "minLength": 1 },
    "session_id": { "type": ["string", "null"] },
    "epoch": { "type": "integer", "minimum": 0 },
    "payload": { "type": "object" }
  },
  "additionalProperties": false
}

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://akashikprotocol.com/schema/0.1.0/memory-unit.json",
  "type": "object",
  "required": ["id", "mode", "type", "content", "intent", "source", "status", "epoch"],
  "properties": {
    "id": { "type": "string", "minLength": 1 },
    "mode": { "type": "string", "enum": ["draft", "committed"] },
    "type": {
      "type": "string",
      "enum": ["finding", "decision", "observation", "intention", "assumption", "constraint", "question", "contradiction", "synthesis", "correction", "human_directive"]
    },
    "content": { "type": "string", "minLength": 1 },
    "intent": {
      "type": "object",
      "required": ["purpose"],
      "properties": {
        "purpose": { "type": "string", "minLength": 1 },
        "task_id": { "type": ["string", "null"] },
        "question": { "type": ["string", "null"] }
      }
    },
    "confidence": {
      "type": "object",
      "properties": {
        "score": { "type": "number", "minimum": 0.0, "maximum": 1.0 },
        "reasoning": { "type": "string", "minLength": 1 },
        "evidence": { "type": "array", "items": { "type": "string" } },
        "assumptions": { "type": "array", "items": { "type": "string" } }
      }
    },
    "source": {
      "type": "object",
      "required": ["agent_id", "agent_role", "timestamp"],
      "properties": {
        "agent_id": { "type": "string" },
        "agent_role": { "type": "string" },
        "session_id": { "type": ["string", "null"] },
        "timestamp": { "type": "string", "format": "date-time" }
      }
    },
    "relations": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["type", "target_id"],
        "properties": {
          "type": {
            "type": "string",
            "enum": ["supports", "contradicts", "depends_on", "supersedes", "caused_by", "elaborates", "answers", "blocks", "informs"]
          },
          "target_id": { "type": "string" },
          "description": { "type": ["string", "null"] }
        }
      }
    },
    "status": {
      "type": "string",
      "enum": ["active", "draft", "superseded", "retracted", "contested", "pending_enrichment"]
    },
    "epoch": { "type": "integer", "minimum": 0 }
  }
}

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://akashikprotocol.com/schema/0.1.0/scope.json",
  "type": "object",
  "required": ["role", "max_units"],
  "properties": {
    "role": { "type": "string", "minLength": 1 },
    "max_units": { "type": "integer", "minimum": 1 },
    "max_tokens": { "type": "integer", "minimum": 1 },
    "interests": { "type": "array", "items": { "type": "string" } },
    "active_task_id": { "type": ["string", "null"] },
    "temporal_layers": {
      "type": "array",
      "items": { "type": "string", "enum": ["past", "present", "future"] }
    },
    "relevance_threshold": { "type": "number", "minimum": 0.0, "maximum": 1.0 },
    "recency_weight": { "type": "number", "minimum": 0.0, "maximum": 1.0 },
    "since_epoch": { "type": ["integer", "null"], "minimum": 0 }
  }
}

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://akashikprotocol.com/schema/0.1.0/conflict.json",
  "type": "object",
  "required": ["id", "type", "status", "unit_a", "unit_b", "description", "detected_by"],
  "properties": {
    "id": { "type": "string", "minLength": 1 },
    "type": { "type": "string", "enum": ["factual", "interpretive", "strategic", "priority"] },
    "status": { "type": "string", "enum": ["detected", "resolving", "resolved", "escalated"] },
    "unit_a": { "type": "string" },
    "unit_b": { "type": "string" },
    "description": { "type": "string" },
    "detected_by": { "type": "string", "enum": ["explicit", "semantic", "logical", "temporal"] },
    "resolution": {
      "type": "object",
      "properties": {
        "strategy": {
          "type": "string",
          "enum": ["last_write_wins", "confidence_weighted", "authority", "evidence_count", "synthesis", "human_escalation", "vote"]
        },
        "winner_id": { "type": ["string", "null"] },
        "rationale": { "type": "string" },
        "resolved_by": { "type": "string" },
        "epoch_resolved": { "type": "integer" }
      }
    }
  }
}

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.

This specification is released under Creative Commons Attribution 4.0 International (CC BY 4.0).

© 2026 Sahil David sahildavid.dev@gmail.com.

This specification is a living document. Version 0.1.0-draft represents the initial public release. Feedback, issues, and contributions are welcome at github.com/AkashikProtocol.