syndicalt/zaxy

**Production memory for agent teams that need receipts.**
Zaxy turns agent context into an auditable project memory fabric. It captures
parent missions, worker sessions, tool observations, cited findings, conflict
review, approval packets, and accepted merge-back into one durable history that
can be queried, replayed, and inspected.
Under the hood, Zaxy uses Eventloom append-only JSONL as the source of truth and
an embedded LadybugDB graph projection for local reasoning. It is built for agents
that need to remember what happened, cite where it came from, and avoid turning
project state into a pile of markdown files and vector chunks.
The embedded LadybugDB graph projection is the default local runtime.
The plain install uses embedded LadybugDB. Install zaxy-memory[neo4j] only for the
optional Neo4j sidecar, and zaxy-memory[pathlight] only for Pathlight tracing.
Why It Matters
- **Auditable memory**: every accepted fact can point back to Eventloom history.
- **Agent-team coordination**: parent and worker sessions stay isolated until
findings are reviewed and merged.
- **Local-first runtime**: the default path uses embedded LadybugDB, no Neo4j sidecar.
- **MCP-native integration**: Codex, Claude Code, Cursor, VS Code, Hermes Agent,
LangGraph, CrewAI, and AutoGen can use the same memory interface.
> **Benchmark claims withdrawn (2026-07-03).** The prior LongMemEval numbers
> were withdrawn: they were produced in *oracle* mode (mean ~1.9 candidate
> sessions per question, so Recall@5/citation-coverage were ~1.0 by
> construction, not by retrieval) and the preference-question scores rested on a
> hardcoded answer table that has since been removed. Zaxy does not currently
> publish a LongMemEval score. A real, full-haystack LongMemEval run is planned;
> until it lands, treat the earlier 0.956/0.910/1.000 figures as retracted.
> The Harvey LAB claim is pending the same audit.
Quick Start
Install, init, verify
The PyPI distribution is zaxy-memory; the import package and console command
are still zaxy. Bare zaxy init sets up the local embedded graph posture,
repo-local profile, deterministic capture config, genesis event, heartbeat, and
MCP guidance. For Codex, the printed activation launcher starts the managed
capture watcher when the local capture config is present; pass --capture start
only when you want init itself to start the watcher before opening Codex. The
default human output is compact and action-first; add --verbose when you need
the full setup diagnostics, optional checks, fallback commands, resume guidance,
and notes.
For automation, zaxy init --json keeps the raw onboarding fields and adds
setup.status, setup.issues, setup.pending, readiness.status,
readiness.reasons, readiness.actions, and structured
readiness.action_items for both commands and non-command review tasks. Each
structured action carries label, command, original source, and hints
for compact-output tips such as activation replacement and path-stable
command guidance. Installers can render those tips without parsing prose. It also
includes setup.summary, readiness.summary,
readiness.required_action_count, and readiness.reason_count, so client UIs
can render compact status without parsing human output. It also
separates readiness.blocking_diagnostics from
readiness.non_blocking_diagnostics so scripts can distinguish setup
completion, required actions, and advisory doctor warnings before relying on
live memory.
For Codex, zaxy init --codex-mcp-install auto is the default. It writes or
reuses the user-level Codex MCP config when that can be done without replacing
an existing zaxy server entry. If no safe config target exists, it prints the