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
