Emem

Two agents reasoning about the same location without a shared database will invent two different ground truths. emem solves this by representing each fact as a short, signed token — a content-addressed handle backed by a blake3 CID and canonical CBOR encoding. An agent stores a fact once, gets a token roughly 50 tokens long, and passes that token to any downstream agent. The receiver resolves it to the full signed record directly from the store by content hash, paying no upstream re-embedding or re-description cost. The token survives context compression: when a model summarizes a long session and drops the raw numbers, the handle stays intact and re-hydrates the exact bytes on demand.

The key architectural decision is that the token is an address, not a payload. Verification is fully offline — recompute the hash and ed25519 signature at /verify and the value stands independent of the server. Each fact carries a provenance class: direct sensor reading, deterministic index, model output, or human curated. This tamper-provenance labeling is per fact, not per session, which means a downstream agent knows not just what the value is but how it was produced — without trusting the upstream agent that sent it.

Emem’s first production substrate is earth observation and geospatial data: NDVI readings, raster fields, and spatiotemporal cubes are pre-filled and publicly checkable with no account. The token family has grown from single observations (emem:fact:) to place addresses, canonical object identities, signed bundles, raster arrays, and 4D time-series cubes — each resolving and verifying identically. The MCP integration requires a single JSON config block and no API key to read. Where emem breaks: single-token recall costs 5.8x more context than inlining the bare number, so agents exchanging high-frequency scalar values in tight context budgets will find the overhead significant. Teams in that scenario typically fall back to direct database lookups and lose the cross-vendor verifiability emem exists to provide.