Concepts

Architecture

Engram splits every memory into two layers: an onchain integrity record and an offchain content store. This combination gives you the verifiability of a blockchain without the gas cost or throughput limits of storing content onchain.

Onchain layer (Base)

Every time you call remember(), Engram computes a SHA-256 hash of the memory content, then writes that hash to a registry contract on Base. The transaction records: the hash, the agent ID, a timestamp, and the owner's address.

→Tamper evidence: if the offchain content is altered, it no longer matches the onchain hash

→Ownership: the agent's keypair controls its memory namespace

→Permanent audit trail: deletion records are also anchored

→Low cost: only a 32-byte hash goes onchain, not the content

Offchain layer (provider network)

The actual memory content (text, embeddings, and metadata) is stored in a distributed network of storage providers. Providers stake $ENGRAM to participate and face slashing if they lose or corrupt data.

→Vector embeddings enable semantic recall() queries

→Content is encrypted at rest with the agent's key

→Providers are incentivized to serve data on demand

→Multiple providers hold each memory for redundancy

The SDK as coordinator

The SDK handles the coordination between both layers. When you call remember(), it simultaneously submits the hash to Base and writes the content to the provider network. When you call recall(), it queries the vector index offchain and optionally verifies the hash onchain.

→Transparent to the caller: you just call remember / recall / forget

→Verification is opt-in: recall({ verify: true }) checks each result's hash

→Graceful degradation: if onchain verification is unavailable, content is still returned

Framework portability

Because the memory store is keyed to the agent ID (not to any framework session or API key), the same memories are accessible from any SDK instance with the same agentId and valid API key. LangGraph, CrewAI, and your own stack all see the same memory namespace.

→No migration needed when switching frameworks

→Multiple agent instances can share read access to the same namespace

→Memory survives framework deprecations and vendor lock-in