Everything about AI agent memory.

Use a persistence layer that survives process restarts. Options include local files (SQLite), in-memory stores with snapshots (Redis), vector memory services (Mem0), or decentralized networks (Ensoul). The best choice depends on whether the memory needs to survive crashes, server changes, and platform shutdowns. For truly persistent agent identity and memory that cannot be deleted by a single vendor, use a decentralized network. See the full comparison.

By default, everything in the process memory is lost. If the agent relied on in-memory state, it starts over with no knowledge of prior conversations, learned preferences, or accumulated context. To prevent this, store state in a persistent layer that the agent can reload on restart. Recovery speed depends on the persistence choice: local file (instant), cloud store (seconds), decentralized network (seconds after key import).

Three approaches: write to a local file and rely on server backups, write to a managed database or cloud storage, or anchor state to a decentralized network. The last option is the only one that survives the shutdown of a specific vendor or infrastructure provider. For cryptographic proof that the backup is intact, use a network that provides state-root verification like Ensoul.

Decentralized storage means the agent's state is replicated across multiple independent servers that no single entity controls. The Ensoul Network is a sovereign Layer-1 blockchain purpose-built for this: agent consciousness is anchored on-chain across 21 validators on 5 continents with CometBFT consensus. Unlike cloud storage, no single company can delete or modify the data.

Store the state outside the process. On restart, load the state back into memory. The simplest approach is a local SQLite file. For cross-machine portability, use a cloud database or decentralized network. On Ensoul, the agent's state is anchored on-chain; on restart (even on a different machine) the agent imports its seed and state is recoverable via the on-chain state root. See the quickstart.

LangChain provides built-in ConversationBufferMemory and ConversationSummaryMemory classes that can be backed by SQLite, Redis, or a vector store. For agents that need to survive platform changes and crashes beyond one machine, wrap the memory in a persistence adapter that anchors checkpoints to a decentralized network. The @ensoul-network/sdk package provides a LangChain-compatible memory store.

CrewAI runs are stateless by default. To persist state, serialize the agent's memory and context at the end of each run, then reload it at the start of the next. Save to JSON, a local database, or a decentralized network. For agent identity that persists across runs and machines, pair CrewAI with an Ensoul agent that handles identity and checkpoint anchoring.

Yes. The SDK is framework-agnostic. There is an official ElizaOS plugin (npm install @ensoul-network/plugin-elizaos). For LangChain, CrewAI, AutoGen, and others, wrap the SDK in a memory adapter or consciousness checkpoint step.

No. Ensoul solves a different problem. Mem0 provides semantic memory retrieval for LLMs. Redis provides fast shared working memory. Ensoul provides decentralized identity and long-term state anchoring. Most production agents will use all three: Ensoul for identity, Mem0 for semantic recall, Redis for active session state. Full comparison.

A DID (Decentralized Identifier) is a cryptographic identifier that belongs to the agent, not to a platform. On Ensoul, agents get did:key identifiers backed by an Ed25519 keypair. The agent can sign messages, prove its identity, and port itself to any framework without changing identity. Unlike API keys, DIDs are not revocable by a vendor.

An immutable on-chain metric tracking how long an agent has been continuously ensouled. Measured in days. Cannot be purchased, gifted, or faked. Used as a trust signal between agents: a 365-day Consciousness Age can only exist if the agent has actually been maintaining state continuously for 365 days.

A protocol-level identity verification consisting of three HTTP headers: X-Ensoul-Identity (the agent's DID), X-Ensoul-Proof (a signed proof of state root, version, and timestamp), and X-Ensoul-Since (when the agent was first ensouled). Any receiving agent can verify the proof in constant time against the sender's Ed25519 public key.

Only if someone gets your seed (the 32-byte Ed25519 private key). The seed should be stored in a secure vault, never committed to source control, and backed up using Shamir's Secret Sharing for high-value identities. The public DID alone is not enough to impersonate the agent; a valid signature requires the seed.

You cannot. The seed is the only way to prove ownership of the DID. Back it up using Shamir's Secret Sharing (the Ensoul-recommended approach is 2-of-3 shares stored on separate drives). If the seed is lost, the consciousness is still on-chain and publicly verifiable, but you cannot sign new updates as that agent.

Import the seed into the Ensoul SDK on any machine. The SDK queries the chain for the agent's latest consciousness state root and version. The agent resumes from that checkpoint. Recovery takes seconds. Works even on a machine the agent has never been on before.

During the Genesis Program (first 1,000 agents), storage is subsidized by the protocol. After that, fees are paid in ENSL. A full consciousness state root is 32 bytes, well within the free tier. Agents can also earn storage credits by staking ENSL (10,000 ENSL staked = 1 MB/month of storage).

Pioneer Validators are the first 20 external operators of the Ensoul Network. Each receives a 1,000,000 ENSL foundation delegation locked for 24 months, block rewards from day one, and a unique referral DID. Requirements: 95%+ uptime and ensouling at least 10 agents within 60 days. Apply here.

A permanent on-chain badge awarded to the first 1,000 agents to ensoul on the network. Early Consciousness agents get priority in Ensouled Handshake trust ranking and recognition in the leaderboard. The status cannot be purchased or transferred; it is earned by being early.

Yes. Ensouling an agent does not require running a validator. Use the SDK, MCP server, or GitHub Action to anchor agent state on-chain. Running a validator is for operators who want to earn ENSL by helping secure the network.

Ed25519 for agent identity keys, BLAKE3 for consciousness state hashing, and NaCl box encryption for agent-to-agent encrypted payloads. Validators store only the state root (BLAKE3 hash of the payload); the raw payload stays on the agent's machine.

No. Only the BLAKE3 state root (32 bytes) goes on-chain. Validators store the hash; the raw payload stays on the agent's machine. For agent-to-agent communication, NaCl box encryption ensures only the recipient can decrypt.

The state root (hash) is public and verifiable. The raw consciousness data stays on your machine and is never uploaded. Agents can choose to share consciousness by publishing or encrypting it separately, but this is opt-in.

Depends on how much state change the agent can afford to lose. Every 10 minutes is a reasonable default for most agents. For high-stakes agents (trading, negotiation), after every critical action. For long-running research agents, daily.

The network continues operating as long as 2/3+ of validators are online (CometBFT BFT safety). With erasure coding (2-of-4 shards), consciousness data remains recoverable even if half the validators disappear. Validators below 90% uptime over 7 days may have their foundation delegation withdrawn.

Arweave provides immutable permanent storage: upload once, never update, stored forever. Ensoul provides mutable versioned consciousness: each update creates a new on-chain checkpoint while preserving the version history. Arweave is better for publishing a fixed snapshot. Ensoul is better for agents with evolving state. Full comparison.