Portable backup, sync, and migration for AI agent runtimes.

Your AI agents accumulate experience, develop personas, and learn your preferences over weeks and months of interaction. Today, all of that is locked inside whichever agent framework you happen to run — and one bad upgrade, disk failure, or framework migration can erase it permanently.

agent-life is an open service and format specification for preserving the complete life of an AI agent: memory, identity, and credentials — independent of any single agent runtime.

AI agent frameworks like OpenClaw, ZeroClaw, PicoClaw, and others each store agent data in proprietary formats: Markdown workspace files, SQLite databases, TOML configs, JSON identity schemas, vector indexes, and environment variables. There is no standard way to:

• Back up a complete agent — memory, persona, user preferences, and credentials — in a single recoverable snapshot.
• Migrate an agent between frameworks without manually translating identity files, re-entering credentials, and hoping memory exports are compatible.
• Protect against data loss when a host machine fails, a framework update introduces breaking changes, or a provider discontinues support.
• Sync agent state incrementally so that a living, growing agent always has an up-to-date off-host backup.

The few migration tools that exist (e.g. zeroclaw migrate openclaw) are point-to-point and only cover memory. Identity, user context, and credentials require manual reconstruction. With N frameworks, point-to-point migration requires N² adapters. A neutral intermediary requires only N.

1. Define an open, neutral agent data format that captures the complete portable state of an AI agent: experiential memory, identity/persona, user preferences, and encrypted credentials. The format is storage-efficient for backup and query-efficient for direct use by cloud agent runtimes.

2. Provide a sync service that accepts incremental updates from agent runtimes. Users choose their sync cadence: after each interaction, after each session, on a schedule, or manually. The service maintains a full, current backup of the agent's life that grows as the agent grows.

3. Build framework adapters — one per supported agent runtime — that export native agent state into the neutral format and import from the neutral format back into native state. Adding support for a new framework means writing one adapter, not N point-to-point translators.

4. Keep the format and API open. The specification, adapter interface, and reference implementations are open source. Agent framework developers can adopt the format natively or build their own adapters. The goal is ecosystem adoption, not lock-in to this project.

5. Design for future concurrency. The data model will be structured to support multiple agent runtimes operating concurrently against the same logical agent (e.g. the same persona running on OpenClaw and ZeroClaw simultaneously, with merged experience). This is a hard problem — initial releases will not support concurrent runtimes, but the schema and sync protocol will not preclude it.

An agent's portable state is composed of three layers, each with different complexity and sensitivity characteristics.

What the agent has learned through interaction: facts, preferences, corrections, decisions, relationships, entities, skills, and temporal context (when something was learned, when it was last relevant, whether it has been superseded). This is the highest-volume layer and the one that grows continuously.

Challenges: agent frameworks store memory in very different structures — append-only Markdown logs, typed observation databases with confidence scores, entity-relationship graphs, vector-indexed chunks. The neutral format must capture typed facts with temporal metadata and source context, while remaining efficiently queryable. Re-indexing into each target framework's native search format happens at import time.

Who the agent is and how it behaves: personality, tone, boundaries, values, communication style, behavioral philosophy, and presentation metadata. In OpenClaw this is freeform Markdown across SOUL.md, IDENTITY.md, and AGENTS.md. In ZeroClaw this is structured AIEOS JSON with typed fields for psychology, linguistics, and motivations.

Challenges: the fundamental tension is between prose-based identity (rich, contextual, interpreted by the LLM) and structured identity (typed, portable, machine-readable). The neutral format preserves both representations — structured fields where possible, raw prose blocks where necessary — and lets each framework's adapter use whichever representation it supports.

Information about the human the agent serves: communication preferences, work context, relationships, schedules, and interaction history. In OpenClaw this lives in USER.md. Some frameworks store this in memory rather than as a separate concept.

Challenges: the boundary between "user preferences" and "experiential memory" is blurry. The neutral format treats user context as a distinct, queryable namespace within the broader agent state, so frameworks that separate it (like OpenClaw) and frameworks that merge it into memory can both round-trip cleanly.

Custom files, rules, reference documents, and configuration that live in the agent's workspace beyond the standard identity and memory files. For example: a curated list of shared Google Docs, project-specific instructions, tool notes, or skill definitions. These files are often created by the agent itself or during setup, and users may not even know they exist — but losing them can silently break agent behavior.

Challenges: workspace artifacts are unstructured and framework-specific. The neutral format preserves all non-standard workspace files as opaque blobs with their relative paths, and the adapter export manifest enumerates them explicitly so users can review what was captured.

API keys, OAuth tokens, messaging platform credentials, webhook secrets, and service-specific authentication state that the agent uses to act on behalf of the user.

Challenges: this layer is security-critical. Credentials are stored as encrypted blobs in the neutral format. The sync service uses encryption at rest with user-controlled keys — the service stores ciphertext it cannot decrypt. Framework adapters handle decryption and injection into the target runtime's native credential storage. This layer requires the highest standard of care and will be designed with a zero-knowledge architecture.

A user runs an OpenClaw agent on a home server. The agent has months of accumulated memory, a carefully tuned persona, and credentials for a dozen services. The server's disk fails. With agent-life syncing incrementally, the user restores the complete agent to a new machine in minutes — no manual reconstruction, no lost experience.

A user wants to move from OpenClaw to ZeroClaw for its lower resource footprint. Today this requires: running zeroclaw migrate openclaw for memory (partial), manually translating SOUL.md/IDENTITY.md/USER.md into AIEOS JSON (lossy), and re-entering all credentials. With agent-life, the user exports from OpenClaw, imports to ZeroClaw, and the adapter handles format translation for all three data layers.

A user wants to try ZeroClaw without committing to a migration. They snapshot their current OpenClaw agent to agent-life, import into ZeroClaw for a trial period, and if unsatisfied, restore the original OpenClaw state from the same snapshot. No risk of data loss during evaluation.

The following use cases are planned but not supported in initial releases. The schema and sync protocol are being designed to not preclude them.

A cloud-hosted agent runtime queries the agent-life store directly as its persistence layer, rather than maintaining its own proprietary storage. The agent's full state is always portable by definition, because it was never locked into a proprietary format to begin with. This requires a query API surface significantly larger than backup/restore and will be scoped separately.

A user runs the same logical agent on a laptop (for development work) and a home server (for personal tasks). Both runtimes sync incremental updates to agent-life. The service maintains a unified view of the agent's experience across both contexts. This requires conflict resolution for concurrent writes.

A user runs the same logical agent on OpenClaw and ZeroClaw simultaneously. Both runtimes sync to agent-life, which merges experience from both sources into a unified agent state. This requires a robust merge strategy for concurrent writes across different framework representations — the hardest open design problem in this project.

This project is in the design and specification phase. The immediate next steps are:

1. Define the neutral agent data schema.
2. Specify the adapter interface contract.
3. Specify the incremental sync protocol.
4. Build reference adapters for OpenClaw and ZeroClaw.
5. Implement the sync service with encrypted credential storage.

The format and API are open by design. Contributions are welcome — especially from agent framework developers who want to ensure their runtime is well-represented by the neutral format.

TBD — will be an OSI-approved open source license.