Overview

Status: Draft v2. Under active development.

Synixolis is a draft protocol for persistent state in agent systems. It describes how a single node, or a small set of cooperating nodes, can structure, maintain, and evolve memory over time.

The reference implementation uses markdown files and slash commands inside Claude Code. The protocol is intended to be portable, but any implementation still needs a few concrete capabilities: durable state, append-only history, provenance, retrieval, and enough coordination to preserve causal dependencies.

The design is motivated by CDR — a theoretical framework arguing that long-lived bounded systems face recurring pressures to compress, partition, and renew memory.

What this page is

This page is an orientation document, not the full spec. It answers:

• what a node looks like
• what multi-node coordination looks like
• what the protocol is trying to optimize
• what is still draft

What a single node looks like

A node is a concrete directory layout: protocol rules, regioned memory, eval traces, and operational control state all live in inspectable documents.

A Synixolis node is a directory on disk:

synixolis/
├── CLAUDE.md                 ← Protocol: region rules, decay rates,
│                               provenance requirements, action cascade
├── .claude/commands/
│   ├── memory-write.md       ← Classify incoming information, write with provenance
│   ├── memory-review.md      ← Run decay checks, renew or archive entries
│   ├── reflect.md            ← Condense observations into patterns
│   ├── query.md              ← Search memory with read logging
│   ├── status.md             ← Memory health dashboard
│   ├── evolve.md             ← Mine eval traces, propose convention changes
│   └── housekeeping.md       ← Link audit, expiry, archive sweep
├── memory/
│   ├── ephemeral/            ← Hours. Hard-expire at TTL.
│   ├── operational/          ← Days to weeks. Active decay.
│   ├── structural/           ← Months to quarters. Review cycle.
│   ├── identity/             ← Permanent until explicitly changed.
│   └── glacier/              ← Archived. Indexed. Retrieved on demand.
├── eval/
│   ├── traces.md             ← Append-only interaction traces
│   ├── query-log.md          ← Read logging
│   └── compiled-rules.md     ← Classification shortcuts from traces
├── fault-isolation/          ← Invariant checks, fault signatures, incident log
├── colony/                   ← Node manifest, coordination channels
└── protocol/                 ← Changelog, conventions, invariants

In the reference implementation, the agent reads protocol rules from CLAUDE.md, classifies information into regions by timescale, tracks provenance on each entry, logs reads, and periodically reviews entries for decay and renewal. The /evolve command is the proposed path from repeated behavior to explicit rules.

This is the core design move: put lifecycle rules, procedures, and conventions in inspectable documents rather than burying them in code alone.

What a colony looks like

A colony is not a shared prompt. It is a set of nodes coordinating through durable shared state and reconstructing local views from that state.

A colony is two or more nodes sharing an append-only state log. Nodes can be different models, different providers, or run at different times.

Example: three nodes covering different domains for a software team — engineering architecture, research, and project operations. Each keeps local memory. Shared state is coordinated through an append-only log, and each node materializes its own local view from that log. The spec proposes causal consistency for this shared layer.

Information flows from local to shared through evidence-based promotion. A node observes a pattern locally. If multiple nodes independently observe the same pattern, one node can propose promotion to shared structural memory. Promotion then requires majority validation.

Fault isolation uses a circuit-breaker-style model: if a node produces unreliable outputs, other nodes can fence it from shared writes pending investigation. The full design includes per-operation invariants, anomaly detection on telemetry, and escalation from monitoring through rollback.

Usage scenarios

These are intended use cases. The protocol is in draft; these are design targets, not production claims.

Personal productivity. A single node attached to a workspace. Tracks decisions and context with provenance, applies region-appropriate decay, condenses observations into patterns. On session restart, retrieves relevant state at appropriate compression level.

Team knowledge management. Multiple specialized nodes sharing structural memory. The promotion pipeline ensures shared knowledge has cross-node evidence. New participants bootstrap from colony checkpoints.

Research assistant. A node maintaining structured knowledge with full provenance chains. Responses include source attribution and confidence levels. Stale claims are flagged for renewal.

Code architecture memory. A node tracking architectural decisions and constraints. Flags contradictions between new changes and existing decisions with provenance for both.

Optimization path

Optimization levels, with promotion flowing downward into cheaper stable forms and decay flowing upward back into more flexible forms.

Synixolis starts expensive — the naive version uses a full LLM call for each major memory operation. The protocol’s optimization path is an attempt to compile repeated behavior into cheaper forms over time:

Level	Mechanism	Cost
0	Pure inference — agent reads conventions and reasons	High
1	Pattern recognition from eval traces	Medium
2	Convention compilation — patterns become explicit rules	Low
3	Prompt compilation — stable conventions in system prompt	Minimal
4	Native inference integration (research direction)	—

The goal is to move repeated, stable work into cheaper mechanisms without making that compilation permanent. If a compiled rule stops working, the system should be able to fall back to inference.

Spec sections

The full draft specification:

• Vocabulary — Canonical term definitions
• Node Contract — State partitions, entry format, operations, lifecycle gates
• Pluggable Policies — Protocol vs. policy distinction, modification gates
• Colony Dynamics — Formation, resource allocation, communication
• Collective State — Storage topology, consistency, conflict resolution
• Node Lifecycle — States, liveness, maintenance, budgets
• Self-Modification — Modification classes, promotion, sandbox
• Fault Isolation — Byzantine mitigation, three-layer model
• Reference Implementation — Directory structure, bootstrap, deployment