Shared memory across agents

The support agent learns that a customer's SSO login loops on Safari; an hour later the sales agent upgrades them to enterprise; that evening the voice agent takes their call. Each agent has its own prompt, its own framework and its own machine, and they should all know the same things. Recall is one database the agents share, with typed facts whose rules decide what a new statement replaces.

The code

Runs as written: pip install polign-recall brings the client, the recall binary and a local polign_db. Swap local_dir for backend="polign" and a server URL when the database should live in your bucket, or for PostgreSQL, MongoDB or Qdrant.

from polign_recall import Client

# Any number of agents, on any machines, open the same database and the same subject.
db = dict(backend="local", backend_url="./recall-shared",       # or backend="polign", backend_url="http://memory.internal:23000"
          env={"RECALL_PREDICATES": "registry.json"})          # the kinds of facts every agent files under

with Client(**db, typed=True) as support_agent:
    support_agent.remember("customer-42", "plan_tier", "team")
    support_agent.remember("customer-42", "open_issue", "SSO login loops on Safari")

with Client(**db, typed=True) as sales_agent:
    sales_agent.remember("customer-42", "plan_tier", "enterprise")   # upgraded: replaces "team"

with Client(**db, typed=True) as voice_agent:
    for belief in voice_agent.recall("customer-42"):
        print(belief.predicate, "=", belief.value, "| replaced:", [b.value for b in belief.replaced])

What it printed:

open_issue = SSO login loops on Safari | replaced: []
plan_tier = enterprise | replaced: ['team']

What the record looks like

The registry file says which kinds of facts every agent files under and what each one replaces. The three records the two writers left, as the voice agent's read sees them (plan_tier holds one value, so the second statement replaced the first; open_issue holds many):

{"subject":"customer-42","predicate":"plan_tier","value":"team","observed_at":"2026-11-03T18:55:47.920Z","retraction":"false"}
{"subject":"customer-42","predicate":"open_issue","value":"SSO login loops on Safari","observed_at":"2026-11-03T18:55:47.967Z","retraction":"false"}
{"subject":"customer-42","predicate":"plan_tier","value":"enterprise","observed_at":"2026-11-03T18:55:48.000Z","retraction":"false"}

# registry.json
{
  "plan_tier":  { "cardinality": "single", "value_type": "string", "description": "The customer's subscription plan" },
  "open_issue": { "cardinality": "multi",  "value_type": "string", "description": "A problem the customer reported that is not resolved yet" }
}

Across machines, run recall serve in front of the database and give each agent a key bound to its namespace; a request that names another namespace is refused. On Kubernetes a pod exchanges its own service account token for a key, so no secret lives in the sandbox. The same memory is readable from LangGraph, the OpenAI Agents SDK, Pydantic AI, LiveKit and Vapi through their packages, and from any MCP host.

Evidence

The agent memory demo runs two agents on two polign_db nodes against one bucket: a fact remembered through one is read through the other, and a correction made by either is what both answer with afterwards. Memory for Kubernetes Agent Sandboxes shows the key-per-pod setup measured on a kind cluster: a sandbox deleted and recreated under the same name resumes with the memory and state the first one wrote.

Where to go next

• Agent memory demo: two agents, one bucket
• Kubernetes Agent Sandbox
• recall serve: keys, namespaces and workload identity
• Every framework package

Recall is typed, durable memory and state for AI agents. It stores corrections, decisions and task state as append-only records in your own object store (S3 or GCS), so an agent can be corrected without retraining and resumed after a crash, restart or pod replacement without snapshotting the process.