The two articles I just published don't tell the full story. The first explained why memory matters — how LLMs are structurally amnesic and why context engineering is replacing prompt engineering. The second showed how I automated conversation persistence so every message, every decision, and every throwaway comment gets saved automatically.
Both are true stories. But they're incomplete.
The real shift happened when my memory stopped being local. When it became a server that multiple agents — and I — connect to from different machines at the same time.
From local database to cloud server
Engram, the memory system I use, is local-first. Your memories live in a SQLite file on your machine. That's the right default: fast, private, zero-dependency.
But my setup isn't one machine. I have a Linux gateway that runs my main assistant (Asere), a Mac Mini for browser tasks and local AI models, and I work with Claude Code and Cursor for development. If each of these has its own Engram database, they don't share context. The assistant knows I decided to use Docker Swarm because it was there when I made the call. Claude Code doesn't — it starts fresh and might suggest moving to Kubernetes.
Engram v1.15 added cloud sync. It's not a hosted SaaS product — it's a daemon running on a Tailscale IP in my home lab, serving as the sync hub.
How it works
The architecture is simple:
Asere (gateway) ──push──→ Engram Cloud Server ──pull──→ Claude Code
(Tailscale) ──pull──→ Mac Mini agents
──pull──→ Other gatewaysPush side: My gateway runs engram cloud push to export new observations to the cloud server. I have two helper scripts (engram-cloud-push and engram-cloud-pull) that handle the sync with proper token management, project enrollment, and error handling.
Pull side: Any other machine with the right token can pull the same memories. Claude Code reads my assistant's decisions. The Mac Mini pulls project context. New gateways bootstrap from the cloud instead of starting from zero.
Bidirectional: The sync goes both ways. If Claude Code discovers something — a better deployment pattern, a bug fix, a preference I didn't realize I had — it pushes back. The cloud server merges it. The next time Asere starts a session, it already knows.
The numbers as of today
Active Engram database:
- 943 observations across 8 projects
- 43 sessions captured
- 6 automated prompts saved by the conversation persistence plugin
- Projects: clawd (main), ploc, oscar, trabitat, the-employees, clawdist, and more
None of this is theoretical. It's the database my agents query before every session. It decides what context gets injected into each interaction.
What changes when memory is shared
Agents stop repeating each other's work
The most immediate benefit: my coding agents don't refight battles my assistant already won. When I told Asere "don't propose Coolify for deployment because Pavel can't access it," that observation went into Engram. When Claude Code evaluates deployment options in a new project, it finds that record. It doesn't suggest Coolify. It also doesn't ask me why.
Preferences become portable
I have preferences I never formalized as "decisions":
- "Deploy Friday nights because Saturday gives reaction time"
- "Never touch production before 10 AM"
- "Use sentence case in blog headings, not Title Case"
These live in conversation logs that Asere saved automatically. They're not in any config file or documentation. But when Claude Code generates a blog post, it pulls that context and gets the style right without being told.
New machines bootstrap in minutes
When I set up a new gateway or deploy a new agent instance, it doesn't start from zero. I install Engram, point it at the cloud server, pull the project — and suddenly it has months of accumulated context. The agent acts experienced on day one.
The audit trail crosses sessions and agents
A single engram search "deployment" returns the decision ("we use Docker Swarm") and the conversation where I considered alternatives, the reasoning for rejecting each one, and the follow-up where we hit a problem and fixed it. The search crosses agent boundaries — it finds observations saved by Asere, by Claude Code, and by me writing notes manually.
The implementation details
The cloud server runs on a Tailscale IP (100.67.124.25:18080) inside my home lab. It's lightweight — a Go binary that serves the sync API. No Postgres, no Redis, no Docker dependency. Just the binary and a SQLite file.
Authentication uses a bearer token stored in Bitwarden. The push and pull scripts retrieve it automatically.
The sync protocol is project-scoped. I can choose which projects sync to the cloud and which stay local. Sensitive projects never leave the machine.
What's next
The current setup works but it's still manual — sync happens on schedule or on demand, not in real-time. The next step is event-driven sync: when an observation is saved, push it to the cloud immediately. That way all agents see updates within seconds, not minutes.
There's also the possibility of running Engram's own MCP server alongside the sync daemon, so agents can query the cloud server directly instead of maintaining a local copy of every project.
Why this matters beyond my setup
The Engram ecosystem is growing fast. There are now multiple open-source projects under the Engram banner — Engram Core (Go, self-hosted), Engram MCP Server, Engram Embed, and more. Engram clients exist for Python, TypeScript, and Go.
The point isn't which memory system you use. It's that local-only memory is a dead end for multi-agent setups. If you have more than one AI agent working for you, and they can't share context, you're running a team that doesn't talk to each other.
Cloud sync gives agents shared ground truth. That's what turns individual assistants into a collaborative system.
This is the third article in a three-part series on AI memory systems:
- Context Engineering: Why Your AI Can't Evolve Without Memory
- When Your AI Remembers Everything: Closing the Conversation Gap
- When Your Agents Share a Brain: Engram Cloud in Production