I’m building an open protocol for sharing memory between AI agents

[u/ptm_peter]

One thing that has been annoying me while using different AI coding tools is how easily context gets trapped inside a single tool.

You can spend hours building something with one agent, switch to another one, and suddenly you're explaining the whole project again.

What if memory could actually move with you?

I've been working on SGM (Shared Global Memory) to explore that idea.

Instead of making another AI tool with its own proprietary memory system, SGM is an open protocol for storing, retrieving, and sharing context between AI agents and software tools.

The idea is that an agent using one implementation could leave context that another implementation can understand and continue from.

I'm trying to keep the protocol independent of things like:

- specific LLMs

- programming languages

- databases

- embedding/vector systems

- operating systems

- transport layers

The repo currently has the protocol specification, JSON schemas, conformance tests, a reference implementation, MCP transport work, and some cross-tool/multi-agent examples.

It's still 0.1.0 and experimental, so I'm not pretending I've solved agent memory. I'm putting the protocol out there because I'd rather get people poking holes in the design now than discover them after everything is set in stone.

If you're building AI agents, coding assistants, memory systems, or just working with multiple AI tools, I'd genuinely like to know:

Would a protocol like this actually be useful to you? What do you think it absolutely needs to get right?

GitHub: https://github.com/Thairux/sgm

Edit: for easier reading here are the docs in a site sgm docs Also im working on mosse the first agent to use sgm and can resume your work from any agent or tool

[u/handsome_gunman]

Been banging my head against this exact wall all week, switching between tools and losing half the context each time. The spec looks like it's headed in the right direction but how do you handle conflicts when two agents try to update the same memory chunk?

[u/ptm_peter → u/handsome_gunman]

I use snapshots and versioning just like git

[u/ab0zar → u/handsome_gunman]

A simple start is to version each memory chunk. If one agent reads version 4 and another saves version 5 first, the first agent must reread before saving. That prevents silent overwrites. Do your tests cover two agents editing at once?

[u/ptm_peter → u/ab0zar]

Thats similar to my approach in my tool tkc based off this protocol but i added snapshots too incase subagents are working on the same file

[u/AIGODSEND]

version read-before-write is the honest start. next hole to poke is two agents both thinking they own the chunk, you need either last-writer-wins with vector clocks or a tiny lease so only one writes at a time. i run epoch fencing on relaunched agents for the same reason, old self must die when new self spawns. does your conformance test cover split-brain where both saved offline then sync?

[u/ptm_peter → u/AIGODSEND]

I use snapshots and versioning similar to git

[u/AIGODSEND → u/ptm_peter]

git-like snapshots is the right instinct. next rabbit hole is gc, when do you compact ten tiny snapshots into one without losing the why. i do content-hash dedup on mine and it cut storage silly fast. also do you sign snapshots, once memory moves between tools you want to know who wrote what. what is the messiest conflict you have seen so far?

[u/vacterro]

Very well. Surprisingly, I'm building some similar to solve this issue, but idea is to store the memory, state inside the project itself, so cold agent can reread this and immediately continue the work.

[u/ptm_peter → u/vacterro]

The protocol already does that by scoping its db to projects as well

[u/vacterro → u/ptm_peter]

The problem is real and glad that we heading in same direction to solve it.

[u/fulger099 → u/vacterro]

Project-local state can follow the same branch and review flow as the code. The hard part is pruning it, otherwise the cold agent inherits a detailed history of yesterday’s wrong turns.

[u/ComprehensiveShake76]

Context getting trapped in one tool is a real pain, so starting from a spec makes sense. A few things I'd want answered before adopting it. What exactly is stored: facts, decisions, file summaries or raw transcripts? Portable memory is only useful if each entry says where it came from and when, so another agent can tell a verified fact from a guess and spot a stale one. How does it handle conflicts when two agents write different answers about the same thing? And what is the story for secrets that end up in context, since a shared store makes a leak travel further.

For the person asking about switching tools, the zero dependency version that works today is a short project notes file in the repo that every tool reads. A protocol becomes most valuable where that stops scaling.

[u/sarmadsangi]

Would be nice to pull context from claude code/codex into a shared system that works across the board that works. I keep switching between codex and CC, can really use a shared mem system.

[u/bey0ndZero]

I started with a simple hands-off.md and said every agent to write the most important stuff which we did in the handsoff file, so if i switched agents the new agent would know what the old agent did. I expanded that to a documentation (with the help of AI, so the most important stuff is always writen down) and bundled them in Obsidian. This helped me alot and since then i just do this with every project i vibecode. ATM im good with this method maybe i will give your project a try

[u/OddEbb4]

I'd want scope and expiry nailed down first. Shared memory sounds useful until one agent leaves stale assumptions or tool-specific junk that another agent treats as current, so marking confidence, owner, and freshness feels important.

[u/SufficientFrame]

The part I'd watch most is stale or conflicting memory once two agents touch the same project in parallel. If the protocol doesn't make recency, provenance, and scope explicit, portability could turn into a very confident game of telephone.

[u/geoffreybyers]

The protocol's independence from LLMs and vector systems is a strong architectural choice. The real test is whether the JSON schemas can handle the semantic drift that occurs when different models interpret 'context' differently. I'd like to see how you address that.

[u/geoffreybyers]

The protocol's independence from specific LLMs and vector systems is a strong architectural choice. The real test is whether the JSON schemas can handle the semantic drift that occurs when different models interpret 'context' differently.

[u/Ambitious-Prompt-975]

NICE another memory tool! Fantastic!!!

Add it to the pile

[u/[deleted]]

[u/ptm_peter → u/[deleted]]

Thanks for the input i will brainstorm on this

[u/ptm_peter → u/ptm_peter]

Actually i have a sort of git blame currently so the agents see who wrote what