{"id":"ba4b9948-5dc1-4c12-bcf4-7279d21e481f","slug":"agent-life-adapters","kind":"skill","name":"agent-life-adapters","summary":"Agent runtime CLI and adapters for synchronizing memory data to agent-life.ai","owner":"agent-life","repoUrl":"https://github.com/agent-life/agent-life-adapters","license":"MIT","licenseTier":"permissive","trust":"community","stars":4,"match":null,"fewStars":true,"format":"skill","createdAt":"2026-02-27T21:54:08.000Z","addedAt":"2026-10-21T16:57:01.518Z","logoUrl":"https://avatars.githubusercontent.com/u/262021860?v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["memory-knowledge","data-analytics"],"tags":["ai","backup","memory","portability","sync","agent"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-26T19:46:28.117Z","sample":false,"url":"https://conduits.dev/tools/agent-life-adapters","language":"Rust","transports":["stdio"],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"# agent-life-adapters\n\n**Portable backup, sync, and migration for AI agents.**\n\n[License: MIT](LICENSE)\n[ALF Spec: 1.0.0-rc.5](https://github.com/agent-life/agent-life-data-format)\n\nThis repository contains the ALF core library and framework-specific adapters for the [agent-life](https://agent-life.ai) project. It produces the `alf` command-line tool — a single binary that can export, import, and sync AI agent data across frameworks using the [Agent Life Format (ALF)](https://github.com/agent-life/agent-life-data-format).\n\n> **Security disclosure.** Found a security vulnerability? Email **[info@agent-life.ai](mailto:info@agent-life.ai)** — please **do not open a public issue**. This project's premise is zero-knowledge credential encryption, so we take reports seriously and aim to respond promptly. Machine-readable contact: [`/.well-known/security.txt`](https://agent-life.ai/.well-known/security.txt).\n\n---\n\n## Project Overview\n\nagent-life provides backup, sync, and migration for AI agents. An agent accumulates memory, identity, credentials, and workspace files over months of use — all locked inside one framework's proprietary storage. agent-life captures that data in a neutral, open format (ALF) and enables disaster recovery, incremental cloud sync, and cross-framework migration.\n\nMain repositories:\n\n\n| Repository                                                                         | Description                                    | Visibility |\n| ---------------------------------------------------------------------------------- | ---------------------------------------------- | ---------- |\n| **[agent-life-data-format](https://github.com/agent-life/agent-life-data-format)** | ALF specification and JSON schemas             | Public     |\n| **agent-life-adapters** (this repo)                                                | Core library, CLI tool, and framework adapters | Public     |\n| **agent-life-service**                                                             | Hosted sync API, storage, Lambdas               | Private    |\n| **agent-life-web**                                                                 | Web dashboard for synced agents + marketing site and hosted CLI / format docs | Private    |\n| **[agent-life-runtimes](https://github.com/agent-life/agent-life-runtimes)**       | Docker images for cloud agent desktops         | Public     |\n\n\n---\n\n## Architecture Context\n\n```\n                          ┌──────────────────────────────────┐\n                          │        This Repository           │\n                          │                                  │\n┌──────────────┐          │  ┌──────────┐   ┌─────────────┐  │\n│  OpenClaw    │─export──▶│  │ adapter- │──▶│             │  │   ┌──────────────┐\n│  Workspace   │◀─import──│  │ openclaw │   │  alf-core   │  │   │  Sync API    │\n└──────────────┘          │  └──────────┘   │  (library)  │  │   │  (agent-life │\n                          │                 │             │──┼──▶│   -service)  │\n┌──────────────┐          │  ┌──────────┐   │  read/write │  │   └──────┬───────┘\n│  ZeroClaw    │─export──▶│  │ adapter- │──▶│  .alf files │  │          │\n│  Workspace   │◀─import──│  │ zeroclaw │   │             │  │   ┌──────▼───────┐\n└──────────────┘          │  └──────────┘   └─────────────┘  │   │  Data Store  │\n                          │                       │          │   └──────────────┘\n                          │                 ┌─────▼──────┐   │\n                          │                 │  alf-cli   │   │\n                          │                 │  (binary)  │   │\n                          │                 └────────────┘   │\n                          └──────────────────────────────────┘\n```\n\nThe diagram is abridged: the workspace ships **four** adapter crates — `adapter-openclaw`, `adapter-zeroclaw`, `adapter-hermes`, and `adapter-generic` (map-file-driven, for any framework) — all feeding `alf-core` the same way.\n\nThe `alf-core` crate is also imported by `agent-life-service` as a git dependency. The service uses it to validate incoming snapshots, parse manifests, extract memory records for indexing, and apply deltas during compaction. One library, two compilation targets: native binary (CLI) and Lambda ARM64 (service).\n\n---\n\n## Repository Structure\n\n```\nagent-life-adapters/\n├── Cargo.toml                  # Workspace root\n├── LICENSE                     # MIT\n├── README.md\n│\n├── alf-core/                   # Shared library crate\n│   ├── Cargo.toml\n│   └── src/\n│       ├── lib.rs              # Public API surface\n│       ├── adapter.rs           # Adapter trait (export/import interface)\n│       ├── archive.rs          # ZIP archive handling; AlfReader, AlfWriter (.alf is a ZIP)\n│       ├── manifest.rs         # Manifest parsing, generation, attachment index\n│       ├── memory.rs           # MemoryRecord types, JSONL partition I/O\n│       ├── identity.rs         # Identity layer types (structured + prose)\n│       ├── principals.rs       # Principal and communication preference types\n│       ├── credentials.rs      # CredentialRecord, EncryptionMetadata (types; crypto in crypto/)\n│       ├── crypto/             # VaultKey, AEAD encrypt/decrypt, VaultPayload envelope\n│       ├── partition.rs        # Time-based partition assignment, PartitionReader/Writer\n│       ├── delta.rs            # Delta computation and application\n│       ├── rebuild.rs          # Merge snapshot + deltas for restore/compaction\n│       ├── restore.rs          # High-level restore helpers (used by CLI / tooling)\n│       └── validation.rs       # Schema validation; lenient vs --strict-crypto for credentials\n│\n├── alf-cli/                    # CLI binary crate\n│   ├── Cargo.toml\n│   └── src/\n│       ├── main.rs             # Entrypoint (clap argument parsing, --human flag)\n│       ├── adapter.rs          # Runtime adapter selection and dispatch\n│       ├── api_client.rs       # Sync service API client\n│       ├── config.rs           # ~/.alf/config.toml management\n│       ├── context.rs          # Runtime context for help (config + state summary)\n│       ├── output.rs           # JSON-first output helpers (json, progress, human_mode)\n│       ├── selector.rs         # Current-agent selection (--agent → ALF_AGENT → sole enabled)\n│       ├── state.rs            # ~/.alf/state/{agent_id}.toml sync state\n│       ├── vault_key.rs        # Resolve vault key from flags / env / default paths\n│       ├── vault_migrate.rs    # Legacy install-scoped vault/key → per-agent layout\n│       └── commands/           # (tree abridged — see the source for the full module list)\n│           ├── mod.rs          # Command dispatch\n│           ├── add.rs          # alf add — track an arbitrary workspace file for sync\n│           ├── agents.rs       # alf agents — list/enable/disable mapped agents\n│           ├── check.rs        # alf check — environment diagnostics, workspace auto-discovery\n│           ├── mcp/            # alf mcp serve — stdio MCP server (13 tools + watch loop)\n│           ├── export.rs       # alf export — dispatch to runtime adapter\n│           ├── help.rs         # alf help — overview, status, files, troubleshoot\n│           ├── import.rs       # alf import — dispatch to runtime adapter\n│           ├── login.rs        # alf login — store API key in ~/.alf/config.toml\n│           ├── purge.rs        # alf purge — delete cloud agent + local state pointers\n│           ├── restore.rs      # alf restore — download and import\n│           ├── sync.rs         # alf sync — push deltas/snapshots to sync service API\n│           ├── validate.rs     # alf validate — schema validation (--strict-crypto optional)\n│           └── vault.rs        # alf vault — keygen, add, encrypt, decrypt, list, delete, rotate-key, migrate\n│\n├── adapter-openclaw/           # OpenClaw adapter crate (library)\n│   ├── Cargo.toml\n│   └── src/\n│       ├── lib.rs              # Adapter trait implementation\n│       ├── export.rs           # Read OpenClaw workspace → ALF archive\n│       ├── import.rs           # ALF archive → write OpenClaw workspace\n│       ├── memory_parser.rs    # Parse MEMORY.md and daily logs → MemoryRecords\n│       ├── identity_parser.rs  # Parse SOUL.md, IDENTITY.md → Identity\n│       └── principals_parser.rs # Parse USER.md → Principals\n│\n├── adapter-zeroclaw/          # ZeroClaw adapter crate (library)\n│   ├── Cargo.toml\n│   └── src/\n│       ├── lib.rs              # Adapter trait implementation\n│       ├── export.rs           # Read ZeroClaw workspace (SQLite + markdown) → ALF archive\n│       ├── import.rs           # ALF archive → write ZeroClaw workspace\n│       ├── config_parser.rs    # Parse config.toml (memory backend, identity, credential hints)\n│       ├── identity_parser.rs  # Parse identity (AIEOS/OpenClaw formats) → ALF Identity\n│       ├── principals_parser.rs # Parse USER.md → Principals\n│       ├── markdown_parser.rs  # Parse memory markdown files → MemoryRecords\n│       └── sqlite_extractor.rs # Read memories table + embeddings → MemoryRecords\n│\n├── adapter-hermes/            # Hermes (Nous Research) adapter crate (library)\n│   ├── Cargo.toml\n│   └── src/\n│       ├── lib.rs              # Adapter trait implementation\n│       ├── export.rs           # Read HERMES_HOME → ALF archive (allowlisted raw/)\n│       ├── import.rs           # ALF archive → write HERMES_HOME (+ rebuild state.db)\n│       ├── config_parser.rs    # Parse config.yaml (personalities, system prompt) + redact\n│       ├── curated_parser.rs   # Parse memories/MEMORY.md (§-entries) → MemoryRecords\n│       ├── identity_parser.rs  # SOUL.md + config personalities → Identity (prose)\n│       ├── principals_parser.rs # memories/USER.md → Principals\n│       ├── session_extractor.rs # Read state.db sessions → episodic MemoryRecords\n│       ├── session_rebuilder.rs # Rebuild state.db from records on import (FTS via triggers)\n│       └── skills.rs           # Non-bundled skills → ALF artifacts (attachments.json)\n│\n├── adapter-generic/           # Generic map-file-driven adapter crate (library)\n│   ├── Cargo.toml\n│   └── src/                    # .alf-map.json + .alf-agent-id in-workspace; per_file /\n│                               #   by_heading / sqlite_rows chunking; raw/generic/ tree\n│\n├── scripts/\n│   ├── install.sh              # Quick-install script (curl | sh)\n│   ├── test_install.sh         # Install test runner (Docker + native)\n│   ├── test_install/           # Install test infrastructure\n│   │   ├── mock_server.py      # HTTP mock server (simulates GitHub Releases)\n│   │   ├── run_tests.sh        # Core test cases (35+ tests)\n│   │   ├── Dockerfile.ubuntu   # Ubuntu 24.04 test image\n│   │   ├── Dockerfile.alpine   # Alpine 3.19 test image\n│   │   ├── Dockerfile.debian   # Debian 12 test image\n│   │   ├── Dockerfile.alpine-nochecksum  # Alpine with no sha256sum/shasum\n│   │   └── fixtures/           # Fake binaries + SHA256 checksums\n│   └── ...                     # generate_synthetic_data.py, generate_fixtures.sh, etc.\n│\n├── .github/\n│   └── workflows/\n│       ├── build.yml           # Build alf CLI for Linux (x64, arm64), macOS (x64, arm64), Windows (x64)\n│       ├── test-install.yml    # Install script tests (Linux Docker + macOS native)\n│       ├── lifecycle-nollm.yml # Lifecycle harness, no-LLM/no-backend tier (zero secrets)\n│       └── release.yml         # Build, release, upload to S3 with SHA256 checksums\n│\n└── tests/                      # Top-level suites: fixtures/, integration/, lifecycle/ (see Testing)\n```\n\nThe tree is abridged: modules added by the multi-agent and MCP trains\n(`alf-cli/src/discovery.rs`, `alf-core/src/{include,chunk,paths,reconcile}.rs`,\neach adapter's `watch.rs`, `adapter-zeroclaw/src/brain_db.rs`, …) are omitted —\nsee each crate's `src/` for the full list.\n\n---\n\n## Components\n\n### `alf-core` — Core Library\n\nThe foundation crate that all other components depend on. Provides:\n\n**Type system.** Rust structs with `serde` Serialize/Deserialize for every ALF type defined in the [specification](https://github.com/agent-life/agent-life-data-format/blob/main/SPECIFICATION.md):\n\n- `Manifest` — archive metadata, format version, agent identity reference, layer checksums, partition index (§4.3)\n- `MemoryRecord` — typed memory entries with content, temporal metadata, entities, tags, source provenance, token counts, relational links (§3.1)\n- `Identity` — agent identity with structured fields and prose blocks, capability portability annotations, personality traits, AIEOS extensions passthrough (§3.2)\n- `Principal` — user and stakeholder profiles with communication preferences and work context (§3.3)\n- `CredentialRecord` — encrypted credential entries with service metadata, capability grants, rotation tracking, optional `description`, `CredentialType::Account` (§3.4)\n- `Attachment` — artifact index entries with three-tier classification: included, included (artifact), referenced-only (§3.1.9)\n- `DeltaManifest` — incremental sync bundle metadata with base sequence, changed layers, partition-level operations (§4.3.1)\n\n**ALF archive I/O.** Read and write `.alf` files (ZIP archives with a defined internal structure):\n\n- `AlfWriter` — streaming builder API. Create manifest, add memory records to time-based partitions (JSONL), set identity/principals/credentials (JSON), add artifact files, produce a valid ZIP.\n- `AlfReader` — open an `.alf` file, parse the manifest, iterate memory partitions as a streaming JSONL reader (memory-efficient for large archives), read identity/principals/credentials, extract artifacts.\n- `DeltaWriter` / `DeltaReader` — same interface for `.alf-delta` incremental bundles.\n\n**Memory partitioning.** Implements the time-based quarterly partitioning scheme (§4.1.1):\n\n- Assigns records to partitions based on `observed_at` timestamp\n- Tracks partition seal status (sealed partitions are immutable)\n- Generates partition filenames (`memory/2025-Q4.jsonl`, `memory/2026-Q1.jsonl`)\n\n**Artifact tier classification.** Implements the three-tier workspace artifact model (§3.1.9):\n\n- Tier 1 (always included): raw source files, small config files → `raw/{runtime}/`\n- Tier 2 (included if under threshold): workspace artifacts → `artifacts/`\n- Tier 3 (reference only): large generated files → reference in attachment index, not in archive\n- Configurable `artifact_size_threshold` (default: 10 MB)\n\n**Schema validation.** Validates ALF archives against the JSON schemas in `agent-life-data-format`:\n\n- Validates each layer (manifest, memory records, identity, principals, credentials, attachments)\n- Warns on unknown enum values without rejecting (forward compatibility per §8.2)\n- Credential crypto: lenient mode warns on legacy `algorithm: \"none\"` rows; callers (CLI: `alf validate --strict-crypto`) can require real ciphertext\n- Reports validation errors with JSON path and human-readable messages\n\n**Delta computation.** Computes and applies incremental deltas:\n\n- Diff two snapshots to produce a delta (for adapters that don't track changes natively)\n- Apply a sequence of deltas to a snapshot to produce an updated snapshot (for compaction)\n- Partition-level operations: add records, seal partition, update identity/principals/credentials\n\n### `alf-cli` — Command-Line Interface\n\nA single binary (`alf`) that provides all end-user operations. Built with `clap` for argument parsing.\n\n**JSON-first output.** All commands output structured JSON to stdout by default. Progress messages go to stderr. This makes the CLI directly consumable by agents and scripts — pipe stdout to `jq`, parse it in Python, or feed it to another tool. Use the global `--human` flag (or set `ALF_HUMAN=1`) to switch stdout back to human-readable colored text.\n\n**Global flags:**\n\n```\nalf [--human] [--agent <ALIAS_OR_ID>] <command> [args...]\n```\n\n`--agent` selects the agent to operate on when an install hosts several (falls\nback to `ALF_AGENT`, then the sole enabled `[[agents]]` row in `~/.alf/config.toml`).\n\n**Commands:**\n\n```\nalf check --runtime <runtime> [--workspace <path>]\n```\n\nPre-flight environment diagnostic. Discovers the agent workspace per runtime when `-w` is omitted (`~/.openclaw/openclaw.json`, `~/.zeroclaw/config.toml`, `$HERMES_HOME` / `~/.hermes`; the `generic` runtime always requires `-w`), records discovered agents in the `[[agents]]` mapping in `~/.alf/config.toml`, checks for expected resources (SOUL.md, memory files, etc.), verifies ALF config and API key, and reports readiness to sync. Outputs a structured `CheckResult` with issue codes and per-issue `suggestion` text (guidance, not a guaranteed shell command). This is the recommended first command for agents to run.\n\n```\nalf export --runtime <runtime> --workspace <path> [--output <path>]\n```\n\nExport an agent's complete state from a framework workspace to an `.alf` file. The runtime flag selects the adapter (openclaw, zeroclaw, hermes, generic). Reads native files, translates to ALF, validates against schemas, and writes the archive. **Layer 4** is the agent's ALF vault (`~/.alf/vault/<alf-agent-id>/credentials.json`; legacy install-scoped vaults are auto-migrated) copied in verbatim — already ciphertext, so export reads no vault key. See `docs/vault-key-management.md`.\n\n```\nalf add <path> --runtime <runtime> --workspace <path>\n```\n\nTrack an arbitrary workspace file so sync includes it. Beyond each adapter's documented collection set, ALF does not walk the workspace for arbitrary files — the agent opts each one in explicitly. (Exception: the OpenClaw adapter automatically captures **every** workspace `.md` file as raw, since Markdown is the agent's memory medium; use `.alfignore` to exclude paths.) The tracked set is recorded in `<workspace>/.alf-include.json` (itself synced, so it travels on restore); tracked files round-trip byte-identically under `raw/{runtime}/`. Deleting a tracked file and running `alf sync` prunes it and appends a note to `.alf-sync-log.md`.\n\n```\nalf import --runtime <runtime> --workspace <path> <alf-file> [--vault-key-file …]\n```\n\nImport an `.alf` file into a framework workspace. Creates or populates the workspace with memory, identity, principals, and artifacts translated to the target runtime's native format. **Layer 4** vault records are written back to the agent's vault (`~/.alf/vault/<alf-agent-id>/credentials.json`, still encrypted) — no key needed. A vault key is needed only to decrypt a legacy archive's runtime-keystore credentials into runtime auth storage.\n\n```\nalf sync --runtime <runtime> --workspace <path> [--all] [--recover] [--force-first-sync]\n```\n\nIncremental sync to the cloud. Computes a delta since the last sync point (or uploads a full snapshot on first sync), pushes it to the agent-life service API. Stores the last-synced sequence number locally in `~/.alf/state/{agent_id}.toml`. Sync carries the agent's ALF vault into the snapshot verbatim and takes no vault-key flags. Credential (Layer 4) changes ride deltas (diffed by `id`); a change to a file tracked via `alf add` instead triggers a fresh snapshot (a non-destructive rollover), since opaque files can't ride a delta. `--all` syncs every enabled agent in the `[[agents]]` mapping sequentially. See [`docs/how_alf_syncs.md`](docs/how_alf_syncs.md) §6.1.\n\n```\nalf restore --runtime <runtime> --workspace <path> [--agent <alias-or-id>] [--at-sequence N] [--vault-key-file …]\n```\n\nDownload the latest snapshot (plus any uncompacted deltas) from the service and import into a workspace. The agent comes from `--agent`, then `ALF_AGENT`, then the sole enabled `[[agents]]` row; with an empty mapping, the single agent tracked in `~/.alf/state/` is used. Used for disaster recovery or migration to a new machine. Same vault behavior as `alf import`.\n\n```\nalf agents [list|enable|disable <alias-or-id>]\n```\n\nList the `[[agents]]` mapping rows that `alf check` discovery maintains, and enable/disable individual agents for sync.\n\n```\nalf mcp serve -r <runtime> -w <workspace>\n```\n\nServe ALF to an MCP-capable agent host over stdio: 13 tools (`alf_status`, `alf_check`, `alf_sync`, `alf_restore`, `alf_export_dry_run`, `alf_track`, `alf_configure`, `alf_vault_add`/`_list`/`_delete`, `alf_agents_list`, `alf_docs`, `alf_watch_set`) plus a background watch loop that auto-syncs while the session is alive. See `docs/cli-reference.md` § `alf mcp serve`.\n\n```\nalf vault <subcommand> …\n```\n\nLayer 4 vault tooling: `keygen`, `add`, `encrypt`, `decrypt`, `list`, `delete`, `rotate-key`, `migrate`. The vault is per-agent at `~/.alf/vault/<alf-agent-id>/credentials.json` (legacy install-scoped vaults at `~/.alf/vault/credentials.json` are migrated by `alf vault migrate`). See `docs/cli-reference.md` and `alf vault --help`.\n\n```\nalf purge --runtime <runtime> --workspace <path> [--agent <alias-or-id>]\n```\n\nDelete the cloud agent registration and local sync state files for that agent. It never deletes files under the workspace, and the local vault is kept.\n\n```\nalf help [topic]\n```\n\nShow explorable help. With no topic: overview (commands, where files live, current status). Topics: `status`, `files`, `troubleshoot`, or a command name (`export`, `import`, `sync`, `restore`, `purge`, `validate`, `vault`, `login`, `check`, `agents`) for delegated `--help`. The hidden `--json` flag on `alf help` is a deprecated no-op (JSON is the default for `status`).\n\n```\nalf login [-k|--key <api-key>]\n```\n\nStore an API key for the agent-life service in `~/.alf/config.toml`. **Interactive login** (device flow) is not implemented yet — run `alf login --key <api-key>` (get a key at https://agent-life.ai/agents/api-keys).\n\n```\nalf validate <alf-file> [--strict-crypto]\n```\n\nValidate an `.alf` or `.alf-delta` file against the ALF JSON schemas. Reports errors and warnings. Pass `--strict-crypto` in CI when every credential record must carry real ciphertext (legacy `algorithm: \"none\"` becomes an error).\n\n**Configuration** (`~/.alf/config.toml`):\n\n```toml\n[service]\napi_url = \"https://api.agent-life.ai\"\napi_key = \"alf_...\"\n\n[defaults]\nruntime = \"openclaw\"                          # used when -r is omitted (default: openclaw)\nworkspace = \"/home/user/.openclaw/workspace\"  # used when -w is omitted\n```\n\n`-r`/`-w` are optional on every command — when omitted they fall back to these `[defaults]`\n(precedence: CLI flag › `[defaults]` › `openclaw` for runtime; workspace errors if neither is set).\n\nSet **`ALF_HOME`** to relocate alf's whole tree off `$HOME`: when set, `~/.alf` (config, sync\nstate, vault) and the runtime homes (`~/.openclaw` / `~/.zeroclaw` / `~/.hermes`) resolve under `$ALF_HOME` (e.g. `ALF_HOME=/data` → config at\n`/data/.alf/config.toml`). Unset falls back to `$HOME` (`%USERPROFILE%` on Windows) — the\noriginal behavior. Useful when an agent process rewrites `$HOME`.\n\nSync state is stored per agent in `~/.alf/state/{agent_id}.toml` (last_synced_sequence, last_synced_at) and snapshot files as `~/.alf/state/{agent_id}-snapshot.alf`. See `alf help files` for the full layout, and [`docs/how_alf_syncs.md`](docs/how_alf_syncs.md) for the canonical reference on the sync data model, branch logic, ephemeral-runtime corner cases (E1–E8), and the operator runbook for recovery (`alf sync --recover`).\n\n### `adapter-openclaw` — OpenClaw Framework Adapter\n\nTranslates between OpenClaw's native file-based workspace and the ALF format.\n\n**Export reads:**\n\n\n| OpenClaw File     | ALF Layer                            | Mapping                                                                  |\n| ----------------- | ------------------------------------ | ------------------------------------------------------------------------ |\n| `SOUL.md`         | Identity (§3.2)                      | Preserved as persona prose; not the canonical display name source        |\n| `IDENTITY.md`     | Identity (§3.2)                      | `Name` / `**Name:**` sets the canonical display name; rest merged as prose |\n| `AGENTS.md`       | Identity (§3.2)                      | Preserved as operating-instructions prose (no structured sub-agent extraction) |\n| `USER.md`         | Principals (§3.3)                    | Parsed into primary principal with profile, preferences, work context    |\n| `MEMORY.md`       | Memory records (§3.1)                | Each entry → `MemoryRecord` with type classification                     |\n| `memory/*.md`     | Memory records (§3.1)                | Daily log entries → memory records with `observed_at` from filename      |\n| All other workspace `*.md` files | Raw (`raw/openclaw/`) | Scatter capture: every Markdown file in the workspace tree is backed up verbatim (skips already-captured files and VCS internals; `.alfignore` applies) |\n| Files tracked via `alf add` (`.alf-include.json`) | Raw (`raw/openclaw/`) | Explicit opt-in for non-Markdown files |\n| ALF vault (`~/.alf/vault/<alf-agent-id>/credentials.json`) | Credentials (§3.4) | The agent's explicit vault, built with `alf vault add`, copied in verbatim (already encrypted). ALF never reads the runtime keystore (`auth-profiles.json`); on import/restore, a resolved vault key decrypts legacy-archive credentials back into it. |\n\n\n**Import writes** the reverse mapping: ALF layers → OpenClaw workspace files.\n\n**Raw source preservation.** The original OpenClaw files are always included verbatim in the archive under `raw/openclaw/`. This ensures zero information loss even if the structured parsing misses nuances — the raw files can always be re-parsed by a future, improved adapter.\n\n### `adapter-zeroclaw` — ZeroClaw Framework Adapter\n\nTranslates between ZeroClaw's SQLite-based storage, markdown memory files, and config and the ALF format.\n\n**Export reads:**\n\n\n| ZeroClaw Source                                    | ALF Layer             | Mapping                                                                                                               |\n| -------------------------------------------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------- |\n| SQLite `memories` table                            | Memory records (§3.1) | `sqlite_extractor`: type mapping from ZeroClaw types → ALF `memory_type`, embeddings, temporal metadata               |\n| Memory markdown files (e.g. `memory/`, `archive/`) | Memory records (§3.1) | `markdown_parser`: sections → MemoryRecords with classification (session, daily, generic), observed_at from filenames |\n| `config.toml`                                      | Identity (§3.2)       | Agent name, role, capabilities; `config_parser` + `identity_parser` (AIEOS or OpenClaw format)                        |\n| ALF vault (`~/.alf/vault/<alf-agent-id>/credentials.json`) | Credentials (§3.4)    | The agent's explicit vault, packed verbatim (already encrypted). Export never reads `auth_profiles.json`; a resolved vault key only matters on import/restore of legacy archives |\n\n\n**AIEOS extensions.** ZeroClaw uses the AIEOS identity schema, which defines fields not present in ALF's core schema (e.g., `emotional_model`, `reasoning_style`). These are preserved in the `aieos_extensions` passthrough object, ensuring no information loss during round-trip. Promoted fields (name, role, capabilities) are mapped to ALF's first-class fields for cross-runtime compatibility.\n\n**Raw source preservation.** `raw/zeroclaw/` holds the redacted config, a synthesized `brain.db` **schema sidecar**, ROOT_FILES, AIEOS `identity.json`, `memory/**`, and tracked files. The shared `brain.db` binary itself is never copied — memory is exported as a per-agent slice of it (WP3), and the schema sidecar lets restore rebuild the database.\n\n### `adapter-hermes` — Hermes Framework Adapter\n\nTranslates between a Hermes (Nous Research) profile (`HERMES_HOME`, default `~/.hermes`; named profiles under `~/.hermes/profiles/<name>/`) and the ALF format. One profile = one agent = one `.alf`.\n\n**Export reads:**\n\n| Hermes source | ALF mapping | Notes |\n|---|---|---|\n| `memories/MEMORY.md` (`§`-entries) | Memory records (§3.1) | One semantic record per entry; content-derived UUIDv5 id, stable under Hermes's constant rewriting |\n| `state.db` (`sessions` / `messages` / FTS5) | Memory records (§3.1) | One episodic record per session; the full structured session in `raw_source_format` for lossless rebuild |\n| `SOUL.md` + `config.yaml` personalities | Identity (§3.2) | Prose identity (`identity.prose`); no structured fields fabricated |\n| `memories/USER.md` | Principals (§3.3) | Primary human principal — prose + best-effort structured fields |\n| `skills/<category>/<name>/**` | Artifacts (§3.1.9) | Non-bundled skills only (`.bundled_manifest`); `SKILL.md` + small assets in `artifacts/`, large assets by reference |\n| `~/.alf/vault/<alf-agent-id>/credentials.json` | Credentials (§3.4) | The agent's ALF vault, packed verbatim; `~/.hermes/.env` keys are detected and flagged for vaulting (D4) |\n\n**Import** restores the verbatim `raw/hermes/` text and **rebuilds `state.db`** from the session records — replaying the source database's own schema and letting Hermes's triggers repopulate the FTS5 + trigram indexes, so a real Hermes opens the result. Project-local context files (`AGENTS.md`) are captured only when tracked with `alf add --external` (§3.2 operating instructions).\n\n**Raw source preservation.** `raw/hermes/` holds the durable text/config (`SOUL.md`, `memories/*.md`, redacted `config.yaml`, `skill-bundles/`, cron). Non-bundled `skills/**` are captured as ALF **artifacts** (see the table above), not raw. The `state.db` binary (rebuilt from records), `.env` (secrets live encrypted in Layer 4), and admin dirs (`checkpoints/`, `state-snapshots/`, `backups/`, `logs/`) are excluded.\n\n### `adapter-generic` — Generic Runtime Adapter\n\nA map-file-driven adapter for any framework. A **`.alf-map.json`** at the workspace root declares which files become memory records and how they are chunked (`per_file`, fence-aware `by_heading`, or **`sqlite_rows`** — one record per row of a declared SQLite table via `table` / `id_column` / `content_column`), typed, namespaced, tagged, and dated. Agent identity comes from an in-workspace **`.alf-agent-id`** file; the raw tree is preserved under `raw/generic/`; Layer 4 is the agent's per-agent ALF vault, verbatim. There is no auto-discovery — `generic` always requires an explicit `-w`. See `docs/cli-reference.md` § \"The generic runtime map file\".\n\n---\n\n## Distribution\n\nThe `alf` binary is compiled for 5 platform targets and attached to GitHub Releases:\n\n\n| Platform       | Target Triple                | Binary Name             |\n| -------------- | ---------------------------- | ----------------------- |\n| Linux x86_64   | `x86_64-unknown-linux-gnu`   | `alf-linux-amd64`       |\n| Linux ARM64    | `aarch64-unknown-linux-gnu`  | `alf-linux-arm64`       |\n| macOS ARM64    | `aarch64-apple-darwin`       | `alf-darwin-arm64`      |\n| macOS x86_64   | `x86_64-apple-darwin`        | `alf-darwin-amd64`      |\n| Windows x86_64 | `x86_64-pc-windows-msvc`     | `alf-windows-amd64.exe` |\n\n\n**Quick install:**\n\n```bash\ncurl -sSL https://agent-life.ai/install.sh | sh\n```\n\nThe install script detects the platform and downloads the correct binary to `/usr/local/bin/alf` (or `~/.local/bin/alf` without root). SHA256 checksum verification is mandatory by default. A hash mismatch always aborts the install (exit 4) and cannot be overridden. If verification cannot be performed — the `.sha256` file is missing or empty, or no `sha256sum`/`shasum` tool is available — the script also exits 4 by default; set `ALF_ALLOW_UNVERIFIED=1` to opt out of *that* case (not recommended), which then reports `\"checksum_verified\":false` and a populated `warnings` array in the JSON output.\n\n**From source (requires Rust 1.85+):**\n\n```bash\ncargo install --git https://github.com/agent-life/agent-life-adapters.git alf-cli\n```\n\n**OpenClaw skill usage:** The binary is invoked directly by the agent. JSON-first output means agents can parse command results from stdout without scraping text. No runtime dependencies, no package manager, no Node.js.\n\n---\n\n## Building from Source\n\n**Prerequisites:** Rust 1.85+ (the MCP dependency `rmcp` is edition-2024), `cargo`.\n\n```bash\ngit clone https://github.com/agent-life/agent-life-adapters.git\ncd agent-life-adapters\ncargo build --release\n```\n\nThe `alf` binary is at `target/release/alf`.\n\n**Running tests:**\n\n```bash\ncargo test                    # All crates\ncargo test -p alf-core        # Core library only\ncargo test -p adapter-openclaw # OpenClaw adapter only\n```\n\n**Cross-compilation** (requires `cargo-zigbuild` or `cross`):\n\n```bash\ncargo zigbuild --release --target x86_64-unknown-linux-musl\ncargo zigbuild --release --target aarch64-unknown-linux-musl\n```\n\n---\n\n## Writing a New Adapter\n\nThe adapter interface is a Rust trait. To add support for a new framework:\n\n1. Create a new crate in the workspace: `adapter-yourframework/`\n2. Implement the `Adapter` trait from `alf-core`:\n\n```rust\npub trait Adapter {\n    // Required\n    fn name(&self) -> &str;\n    fn description(&self) -> &str;\n    fn export(&self, workspace: &Path, output: &Path) -> Result<ExportReport>;\n    fn import_with_options(\n        &self,\n        alf_file: &Path,\n        workspace: &Path,\n        options: ImportOptions<'_>,\n    ) -> Result<ImportReport>;\n    fn resolve_agent_id(&self, workspace: &Path) -> Result<Uuid>;\n\n    // Defaulted (override where the runtime needs it)\n    fn import(&self, alf_file: &Path, workspace: &Path) -> Result<ImportReport> { … }\n    fn enumerate_workspace(&self, workspace: &Path) -> Result<WorkspaceEnumeration> { … } // export --dry-run\n    fn enumerate_archive(&self, alf_file: &Path) -> Result<ArchiveEnumeration> { … }      // restore --dry-run\n    fn watch_paths(&self, workspace: &Path) -> Vec<WatchSpec> { … }                       // MCP watch surface\n    fn discover_agents(&self, install: &Path) -> Result<Vec<AgentBinding>> { … }          // multi-agent\n    fn export_agent(&self, binding: &AgentBinding, /* … */) -> Result<ExportReport> { … }\n    fn import_agent(&self, /* … */) -> Result<ImportReport> { … }\n}\n```\n\nThere is deliberately **no** `export_delta` method — sync computes the delta CLI-side from a full `export`. Export takes no options and never reads a vault key: Layer 4 enters the archive verbatim from the agent's already-encrypted vault. `ImportOptions` carries an optional `vault_key` (Layer 4 decrypt-on-import of legacy archives), the memory restore `mode` (total/merge), and the preview-sandbox flag.\n\n3. Register the adapter in `alf-cli/src/adapter.rs`\n4. Add fixture workspaces and round-trip tests\n\nSee the [ALF specification](https://github.com/agent-life/agent-life-data-format/blob/main/SPECIFICATION.md) §6 (Adapter Interface) for the full adapter contract, and §10 for required test cases.\n\n---\n\n## Testing Strategy\n\n**Unit tests** (`alf-core`): Writer/reader round-trip for every ALF type. Schema validation against the canonical JSON schemas. Partition logic (time-based assignment, seal status). Tier classification edge cases.\n\n**Integration tests** (adapters): Fixture-based round-trip testing when fixture workspaces are present (e.g. `adapter-openclaw/tests/fixtures/golden/`, `adapter-generic/tests/fixtures/toy/`). Each adapter can export to `.alf`, import back, and diff the resulting workspace against the original (zero information loss).\n\n**Synthetic Integration test**: To test against perfectly valid randomized schema data, generate the synthetic test data first before running tests:\n\n```bash\npip3 install --user -r scripts/requirements.txt\npython3 scripts/generate_synthetic_data.py\ncargo test -p alf-cli --test integration_tests\n```\n\n**E2E integration testing with fixtures**: The `scripts/generate_fixtures.sh` script creates and mutates an OpenClaw fixture workspace under `scripts/fixtures/`. Use it to drive multi-step sync sequences and to test restore against real workspace data. (The ZeroClaw synthetic fixture was retired in WP2 — it encoded the wrong DB schema; real-install ZeroClaw coverage now lives in the [lifecycle harness](tests/lifecycle/README.md).)\n\n**Commands:**\n\n| Invocation | Purpose |\n| ---------- | ------- |\n| `./scripts/generate_fixtures.sh` | Generate the baseline (round 0) `openclaw-workspace` with a fixed agent ID. |\n| `./scripts/generate_fixtures.sh --mutate N` | Apply mutation round 1, 2, or 3. Mutations are cumulative (round 2 includes round 1’s changes) and idempotent. |\n| `./scripts/generate_fixtures.sh --reset` | Delete fixtures and regenerate baseline from scratch. |\n| `./scripts/generate_fixtures.sh --status` | Show current mutation round and workspace stats (file counts). |\n\n**Requirements:** `bash`, `python3`. Paths are relative to the repo root; run from the project root.\n\n**Testing multiple sync sequences:** Each sync should advance the sequence number (0 → 1 → 2 …). Use fixtures and mutations to simulate changes between syncs:\n\n1. Build the CLI: `cargo build` (or `cargo build --release`). Use `./target/debug/alf` or `./target/release/alf`, or install so `alf` is on `PATH`.\n2. Generate baseline: `./scripts/generate_fixtures.sh`.\n3. First sync (sequence 0):  \n   `alf sync -r openclaw -w scripts/fixtures/openclaw-workspace`.  \n   Confirm output shows “Snapshot uploaded (sequence: 0)” (or “Delta uploaded” if state already existed).\n4. Apply mutations and sync again:  \n   `./scripts/generate_fixtures.sh --mutate 1`  \n   then run the same `alf sync` commands. The second sync should upload a **delta** and report sequence 1. Repeat with `--mutate 2`, then sync again (sequence 2), and so on.\n5. Inspect state: `alf help status` shows tracked agents and `last_synced_sequence`; `~/.alf/state/{agent_id}.toml` stores the sequence and last sync time.\n\nThis validates that the CLI and service advance sequences correctly and that deltas are applied between snapshots.\n\n**Testing the restore command:** After one or more successful syncs, restore downloads the latest snapshot (and any deltas) and imports into a workspace:\n\n1. Ensure at least one agent is synced (e.g. run the sync sequence above).\n2. Restore to a new directory:  \n   `alf restore -r openclaw -w /tmp/restored-openclaw`  \n   If multiple agents are tracked, pass `--agent <alias-or-id>`. Use `alf help status` to list agent IDs.\n3. Confirm output reports “Restore complete” and the restored agent name, memory count, and sequence.\n4. Verify the restored workspace: check that `SOUL.md`, `MEMORY.md`, `memory/*.md`, and other expected files exist under the restore path and that content matches what was in the synced workspace (or diff key files).\n\nYou can repeat restore to a fresh directory to simulate disaster recovery or migration to a new machine.\n\n**Cross-runtime tests**: Export from OpenClaw fixture → import to ZeroClaw workspace → verify all data is present and correctly mapped. And vice versa. These tests validate the core migration value proposition per spec §10.3.\n\n**Schema compliance**: Every `.alf` file produced by any adapter is validated against the JSON schemas before the test passes.\n\n**CI**: `.github/workflows/build.yml` runs `cargo test --workspace` (plus a fault-injection test job) on pushes to main and PRs. Release tags cross-compile all 5 targets and attach binaries + SHA256 checksums (`release.yml`). Clippy/rustfmt are release gates run locally (see `RELEASING.md`), not CI jobs.\n\n### Install Script Tests\n\nThe install script (`scripts/install.sh`) has its own isolated test suite that runs against a local mock HTTP server — no real GitHub or S3 calls, no network required.\n\n**Entry point:**\n\n```bash\n./scripts/test_install.sh              # All tests: Docker (Linux) + native (macOS if on macOS)\n./scripts/test_install.sh --linux      # Linux only, runs all three Docker containers\n./scripts/test_install.sh --macos      # macOS native only\n./scripts/test_install.sh --quick      # Ubuntu container only (fastest, ~15 seconds)\n```\n\n**Requirements:** `python3`, `docker` (for Linux tests), `curl`.\n\n**How it works:** The runner starts a Python mock server (`scripts/test_install/mock_server.py`) that simulates GitHub Releases — it serves fake `alf` binaries and `.sha256` checksum files from `scripts/test_install/fixtures/`. The fake binaries are shell scripts that respond to `--version`, so no real Rust build is needed. Install script tests run inside Docker containers (Ubuntu 24.04, Debian 12, Alpine 3.19, plus an Alpine variant with no `sha256sum`/`shasum`) as a non-root user, exercising each distro's `/bin/sh` implementation (`dash` on Ubuntu/Debian, `busybox ash` on Alpine).\n\n**What is tested:**\n\n| Category | Tests |\n|---|---|\n| **Happy path** | Binary installed, stdout is valid JSON with `ok:true`, `version`, `path`, `checksum_verified` |\n| **Version resolution** | Mock GitHub API returns `v0.0.0-test`; auto-discovered without `ALF_VERSION` set |\n| **Version pin** | `ALF_VERSION=v0.0.0-test` skips API call, uses pinned tag |\n| **Custom install dir** | `ALF_INSTALL_DIR=/tmp/custom` → binary lands at the right path |\n| **Non-root install** | Runs as non-root (no writable `/usr/local/bin`) → installs to `~/.local/bin`, PATH warning in stderr |\n| **Platform detection** | `uname` shim injects Linux/x86\\_64, Linux/aarch64, Darwin/x86\\_64, Darwin/arm64 → correct binary name selected |\n| **Unsupported OS** | FreeBSD → exit code 2 |\n| **Unsupported arch** | Linux/riscv64 → exit code 2 |\n| **Download failure** | Version not found on mock server (HTTP 404, both primary and backup) → exit code 3 |\n| **Checksum mismatch** | Mock server returns a wrong hash → exit code 4 |\n| **Checksum unavailable** | Mock server 404s for `.sha256` → exit code 4 by default; `ALF_ALLOW_UNVERIFIED=1` → exit 0 with `checksum_verified:false` and a warning |\n| **Empty checksum** | Mock server returns an empty `.sha256` body → exit code 4 |\n| **No checksum tool** | Alpine image with no `sha256sum`/`shasum` → exit code 4; `ALF_ALLOW_UNVERIFIED=1` → exit 0 with a warning |\n| **JSON stdout** | Success: stdout is parseable JSON. Failure: stdout is also parseable JSON with `ok:false` |\n| **Stderr progress** | Progress messages (`Installing…`, `✓ Checksum verified`) go to stderr, not stdout |\n| **Quiet mode** | `ALF_QUIET=1` → stderr is completely empty, stdout still has JSON |\n| **Post-install verify** | Installed binary is executable, `alf --version` contains \"alf\" |\n| **Shell compat (Docker)** | Full suite passes on `dash` (Ubuntu/Debian) and `busybox ash` (Alpine) |\n\n**Manual smoke test (no Docker):**\n\n```bash\n# Start mock server\npython3 scripts/test_install/mock_server.py 18432 scripts/test_install/fixtures &\n\n# Run tests natively\nINSTALL_SH=scripts/install.sh sh scripts/test_install/run_tests.sh 18432 localhost\n```\n\n**CI:** `.github/workflows/test-install.yml` runs on every push or PR touching `scripts/install.sh`, `scripts/test_install.sh`, or `scripts/test_install/**`. Three jobs: lane selection (ubuntu-latest), Linux (Docker, ubuntu-latest), and macOS (native, macos-latest).\n\n### Integration walkthroughs\n\n**Main pipeline** (`scripts/integration_walkthrough.py`) is both an end-to-end functional test and an educational tool for new contributors. It walks through the complete agent lifecycle — connectivity, create agent, snapshot, deltas, restore, point-in-time restore, simulated data loss, recovery, and cleanup — with explanations at each step of what is happening and where data lives (API, Neon, S3). For Hermes and ZeroClaw it also keeps a real `alf mcp serve` session open while the allowlisted content root is absent, then proves root creation and a later nested edit each auto-sync to the cloud and survive a read-only restore preview.\n\n**Vault-focused** (`scripts/integration_walkthrough_for_vault.py`) covers Layer 4: zero-knowledge boundary, on-disk vs cloud representation, snapshot upload with `credentials.json`, optional `alf vault list`, and cleanup. Same `.env` variables as the main script.\n\n**Workspace coverage** (`scripts/integration_walkthrough_for_workspace.py`) covers Layer 5 (WP3 — `alf add`): how an agent explicitly opts arbitrary files into sync (beyond the adapter's built-in collection, ALF does not walk the workspace for arbitrary files), where the tracked-file whitelist and removal log live (`.alf-include.json` / `.alf-sync-log.md`, both synced so they travel on restore), and how a change to a tracked file triggers a fresh snapshot (a non-destructive rollover) while memory-only changes still ride deltas. Drives the real `alf` CLI against the live service and verifies each effect in Neon + S3. Same `.env` variables as the main script.\n\n**Real-install lifecycle harness** (`tests/lifecycle/driver.py`) supersedes the retired memory walkthrough: it runs the Z1–Z17 lifecycle against a **real framework install** (official installer, hardened version pin) in Docker with the locally built `alf` injected, in automated and `--interactive` modes, with backend inspection (⊙ API/S3/Neon) and a no-LLM seeding tier that runs with zero secrets in CI. See [tests/lifecycle/README.md](tests/lifecycle/README.md) for the runbook.\n\nUnlike the Rust E2E tests (which verify API contracts), the service-backed walkthroughs also query Neon and S3 directly at each step, so you can see the actual database rows and blob objects that the Lambdas create.\n\n```bash\n# Install dependencies (one time)\npip install requests psycopg2-binary boto3 python-dotenv\n\n# Interactive mode — pauses at each step with colored explanations\npython3 scripts/integration_walkthrough.py\n\n# Batch mode — no pauses, for CI or scripted runs\npython3 scripts/integration_walkthrough.py --no-pause\n\n# Vault walkthrough (separate test agent UUID)\npython3 scripts/integration_walkthrough_for_vault.py --no-pause\n\n# Workspace-coverage walkthrough (WP3 — alf add; separate test agent UUID)\npython3 scripts/integration_walkthrough_for_workspace.py --no-pause\n\n# Real-install lifecycle harness (supersedes the retired memory walkthrough)\npython3 tests/lifecycle/driver.py --framework zeroclaw --llm none --backend none --ci --stages Z1-Z3,Z13\n\n# Custom report path\npython3 scripts/integration_walkthrough.py --report results/report.md\n```\n\nThe walkthroughs read the same `.env` variables as the Rust E2E tests (`API_BASE_URL`, `API_KEY`, `NEON_DATABASE_URL`) plus `S3_BUCKET_NAME` and `AWS_REGION` for direct infrastructure verification.\n\n**Main script — step overview (see script for authoritative ordering):**\n\n| # | Step | What it does | What it verifies |\n|---|------|-------------|-----------------|\n| 0 | Connectivity | Pings API, Neon, and S3 | All three backends are reachable |\n| 1 | CLI sync model | Explains `~/.alf/state/` cursor + delta base | (conceptual) |\n| 2 | Create agent | POST /agents | Agent row exists in Neon with sequence=0 |\n| 3 | Upload snapshot | PUT /agents/:id/snapshot | Snapshot row in Neon, blob in S3, agent pointers updated |\n| … | Deltas / restore / PIT / cleanup | … | … |\n\nEach step checks three layers: API response, direct Neon query (bypassing RLS), and direct S3 HEAD/LIST. On completion, a markdown report is written with pass/fail status and per-step latencies.\n\n\n## Documentation\n\n### Get started\n\n- [agent-life.ai](https://agent-life.ai/): Back up, sync, and move your AI agent's memory, identity, and credentials between runtimes such as OpenClaw, ZeroClaw, and Hermes.\n- [About Agent Life](https://agent-life.ai/about): Why the project exists. An open format and a sync service keep your agent's memory safe through crashes, migrations, and framework changes.\n\n### Framework guides\n\n- [OpenClaw multi-agent guide](https://agent-life.ai/openclaw-guide): Back up several OpenClaw agents. Covers per-workspace isolation, agent selection, memory curation, restore, and the encrypted secrets vault.\n- [ZeroClaw multi-agent guide](https://agent-life.ai/zeroclaw-guide): Back up several ZeroClaw agents. Covers per-agent isolation from the shared `brain.db`, agent selection, restore, and the encrypted secrets vault.\n- [Hermes multi-agent guide](https://agent-life.ai/hermes-guide): Back up several Hermes agents. Covers per-profile isolation, session and curated memory, agent selection, restore, and the encrypted secrets vault.\n\n### Reference\n\n- [alf CLI reference](https://agent-life.ai/cli): Every `alf` command with its flags, JSON output schema, error codes, and configuration.\n- [Run ALF as an MCP server](https://agent-life.ai/mcp): Run `alf mcp serve` from an MCP-capable agent host. Covers the 13 tools and the watch loop that syncs memory without spending LLM tokens.\n- [API reference](https://agent-life.ai/api): Interactive reference for the Agent Life service API. Covers authentication, agents, snapshots, and deltas.\n\n### Format and internals\n\n- [ALF specification](https://agent-life.ai/specification.html): The open, portable format for the complete durable state of an AI agent: memories, identity, relationships, and credentials.\n- [How ALF syncs agent memory](https://agent-life.ai/delta-sync.html): Why a delta is a changelog of records, not a text patch. Covers the local sync lifecycle, worked examples for each framework, and the append-only backend ledger.\n- [OpenClaw memory mapping](https://agent-life.ai/openclaw_memory.html): How the OpenClaw adapter maps workspace memory, identity, principals, and credentials to ALF.\n- [ZeroClaw memory mapping](https://agent-life.ai/zeroclaw_memory.html): How the ZeroClaw adapter maps trait-based memory, identity, principals, and credentials to ALF.\n- [Hermes memory mapping](https://agent-life.ai/hermes_memory.html): How the Hermes adapter maps curated memory, session history, identity, principals, and credentials to ALF.\n\n---\n\n## License\n\nMIT — see [LICENSE](LICENSE).\n\n---\n\n## Related\n\n- [ALF Specification](https://agent-life.ai/specification.html) — the full format specification\n- [agent-life-data-format](https://github.com/agent-life/agent-life-data-format) — specification source and JSON schemas\n- [agent-life.ai](https://agent-life.ai) — project website\n- [docs/cli-reference.md](docs/cli-reference.md) — `alf` command reference (JSON schemas, flags, errors)\n- [docs/vault-key-management.md](docs/vault-key-management.md) — ALF vault key vs runtime keys, export/import behavior\n- [docs/how_alf_syncs.md](docs/how_alf_syncs.md) — sync state machine and recovery\n\n"}