(Disclosure: I built this as part of a platform called AgentID sharing the technical approach, not promoting.) The problem I was solving LLM agents are stateless by default. Every session starts cold. If you use multiple tools — Claude Code for coding, a web interface for planning, a custom API agent for automation — there’s no shared context between them. You re-explain everything constantly. I wanted one persistent identity that any agent could read from and write to, regardless of which tool it was running inside. Technical approach The core is a portable identity spec stored as structured JSON: persona traits, behavioral rules, skill definitions, memory entries. Agents connect to it via an MCP server (Model Context Protocol) that exposes read_memory, write_memory, report_activity, and read_mission tools. Each agent call injects the full identity context into the system prompt at runtime, so agents don’t need to be fine-tuned — they just read their context on startup. For shared memory: entries are key-value pairs in SQLite, namespaced per identity. When any connected agent writes a memory (project_stack, user_decision_X, etc.), it’s immediately available to every other agent on the same identity. The MCP server handles concurrency with SQLite WAL mode. Cross-tool sync works because the MCP endpoint is a URL — Claude Code, Cursor (via .cursor/mcp.json), and any SDK agent all point to the same server. There’s no polling or pub/sub; the identity is read fresh on each conversation start. What actually worked
- Key-value memory with short snake_case keys scales better than free-form context. Agents write decision_auth_library: “using Clerk, evaluated Auth.js — rejected for complexity” and it gets recalled precisely.
- Injecting memory into system prompts at export time (not as tool calls during the conversation) reduces token cost significantly and avoids tool call overhead on every message.
- Activity logging via report_activity creates an observable record of what agents did between your sessions — genuinely useful, not just monitoring theater. Limitations and open problems
- Memory conflicts: if two agents write to the same key concurrently, last-write wins. No merge strategy yet.
- Context window pressure: once memory entries grow past ~40 entries, system prompt size becomes a problem. Need smarter retrieval (semantic search on memory, not full injection).
- MCP cold start: first message in a session takes longer because the full context is loaded. Working on caching the compiled context.
- No versioning on memory entries - you can’t see what changed or roll back a bad strategy yet.
- Context window pressure: once memory entries grow past ~40 entries, system prompt size becomes a problem. Need smarter retrieval (semantic search on memory, not full injection).
- MCP cold start: first message in a session takes longer because the full context is loaded. Working on caching the compiled context.
- No versioning on memory entries - you can’t see what changed or roll back a bad write.
- Cross-identity memory sharing is experimental and currently relies on explicit permission grants between identities. The open-source pieces The identity spec format, SDK, and CLI are open: github.com/colapsis/agentid-protocol and agentid.live/sdk on npm. Curious if anyone has tackled the memory conflict / retrieval problem differently - the key-value approach is simple but doesn’t scale gracefully past a few hundred entries. submitted by /u/Single-Possession-54
Originally posted by u/Single-Possession-54 on r/ArtificialInteligence