Inspiration
I run research and engineering work across six different AI coding agents — Kiro, Finch, Qoder, OpenCode, Trae and PI-Desktop. Each one is good at something different, so I switch constantly. The problem was that each agent kept its own memory: the same project conventions, the same hard-won debugging rules, the same "we already tried that, it failed" notes had to be re-explained every single time I changed tools. Switching agents meant starting from zero, and the same mistakes got repeated in a different window.
What it does
MemBridge is a small local memory layer that makes all of those agents read and write the same project memory.
- A single CLI (
mem.py) is the only writer:search,read,notes,append,injectandprotocol. - Writes are file-locked, so two agents working at the same moment cannot corrupt the store.
- Every note follows one five-field template — what was finished, where it stopped, the next step, the reusable conclusion, and the pitfall — so memory stays structured instead of becoming a chat-log dump.
- A secret filter blocks API keys, tokens and credentials before anything is written to disk.
- Each agent is connected through its own native surface: a global
AGENTS.md, a globalCLAUDE.md, a prompt include file, or project-level rules — no plugin, no server, no vendor lock-in.
The result: start a task in Kiro, hand it to another agent, and the new agent already knows the project state, the decisions and the traps.
How we built it
It started as a written protocol: one shared AGENTS.memory.md that defines who writes what, and which memory layer a fact belongs to (hard rules vs. project state vs. reusable lessons). Then the CLI enforced it — search across an index, read daily logs, append notes under a lock, and inject the relevant slice into whatever prompt an agent is about to run. Finally I wrote six thin adapters, one per agent, each pointing at the same store.
Challenges we ran into
The hard part was not storage, it was discipline. Without a template, "memory" degrades into noise, and noisy memory is worse than none. The second challenge was concurrency: agents run in parallel and all want to append at once, which is why every write goes through a lock and a single entry point. The third was portability — every agent has a different config surface and priority order, so each adapter had to be verified by actually starting a fresh session and checking that the memory was read.
What we learned
Memory should be layered and explicit: rules belong where they are always injected, project state belongs in project scope, and only genuinely reusable conclusions get promoted. Everything else is a diary, not memory.
What's next
Automatic session harvesting, a shared search index across projects, and a portable format so the same memory can follow me onto a new machine or a new agent.
Log in or sign up for Devpost to join the conversation.