Give a Fleet of AI Agents a Shared Memory in About 10 Minutes

#agentic #vectordatabase #distributedsystems #selfhosted

Most "agent memory" tutorials show you how to make one agent remember things. This one shows what happens when you point two separate agents at the same memory backend — no message bus, no sync job, just two clients talking to one database.

The setup

A SynapCores gateway (self-hosted, one Docker container) as the shared memory store, and two "agents" — really just two separate curl sessions, to prove the point that they don't need to know about each other.

docker run -d --name synapcores -p 8080:8080 \
  -v synapcores-data:/var/lib/synapcores \
  ghcr.io/synapcores/community:latest

export SYNAPCORES_API_KEY="aidb_..."   # printed in docker logs on first boot
export SYNAPCORES_URL="http://localhost:8080"

Agent A learns something and stores it

curl -s -X POST "$SYNAPCORES_URL/v1/query/execute" \
  -H "Authorization: Bearer $SYNAPCORES_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"sql": "SELECT MEMORY_STORE('"'"'fleet'"'"', '"'"'Client Acme prefers async updates over calls'"'"') AS id"}'

That's it. One SQL call. Note the namespace — 'fleet' — that's the shared identity every agent in the group will use.

Agent B — a completely different process, could be a different machine — recalls it

curl -s -X POST "$SYNAPCORES_URL/v1/query/execute" \
  -H "Authorization: Bearer $SYNAPCORES_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"sql": "SELECT content, similarity FROM MEMORY_RECALL('"'"'fleet'"'"', '"'"'how does Acme like to be contacted'"'"', 3)"}'

Agent B never talked to Agent A. It never saw the original sentence. It gets the fact back anyway, because the query is semantic (cosine similarity over embeddings computed server-side) not a keyword match, and both agents are reading the same fleet namespace.

Why this matters

Every popular agent-memory pattern right now (markdown vaults, local vector stores, JSONL logs next to the process) is architecturally single-instance. The memory lives where the agent runs, so a second agent — even on the same machine — has no path to it. Point two agents at the same database instead, and "shared memory" isn't a feature you build — it's what naturally happens when two clients hit the same server.

Where it gets real

In production you'd scope identities more deliberately than one flat fleet bucket — per-team, per-role, whatever matches your actual agent topology — and use MEMORY_UPSERT's conflict-resolution policies once more than one agent might write contradictory facts. But the core mechanic — cross-instance recall with zero glue code — works exactly as shown above.

If you're on OpenClaw

This ships as a drop-in plugin — auto-capture and auto-recall wired into the memory slot, no manual curl needed:

openclaw plugins install clawhub:@synapcores/openclaw-memory

Everything else in this post — namespaces, shared identity, conflict resolution — works the same way underneath.

Source: https://github.com/SynapCores/synapcores-openclaw-memory

DEV Community