Your agents don’t have a memory problem. They have a team memory problem.

"Agent memory" has become a crowded phrase, and most of what gets built under it is solving a real but narrower problem: how does this agent remember this user across sessions. Their preferences, their past conversations, facts they mentioned once that shouldn't need repeating. That's personalization memory, and it's genuinely useful — for a support bot, a companion app, a product that has exactly one human on the other end of every session.

A dev team writing code with AI agents has a different shape of problem entirely. It's not one agent and one user — it's several engineers, each running their own agent, in their own tool of choice, all pointed at the same repo. Personalization memory doesn't help here, because the thing worth remembering isn't about any one person. It's about the repo: the migration that broke prod last month, the architectural decision the team already argued about and settled, the three approaches someone already tried and ruled out before you showed up.

Why this needs a different design, not just a different prompt

If memory is scoped to a single user, it doesn't matter how good the retrieval is — a teammate's agent simply has no path to it. The fix isn't a smarter embedding model; it's scoping memory to the repo and the team, not the individual, and making it reachable from whatever tool each engineer happens to prefer. That's a different architecture from the ground up, not a configuration option on top of personalization memory.

It's also why threadctx is built as a standard MCP server rather than a per-product SDK: a memory system scoped to a team, not a user, only pays off if every tool that team uses can reach it. One engineer's Claude Code session and another's Cursor session need to read and write the exact same memory, or the whole premise falls apart.

If what you're building is a product that remembers its users, that's a real and different problem, and there are good tools built specifically for it. If what you're trying to fix is your own team re-discovering the same repo lessons because nobody's agent knew what another teammate's agent already learned — that's the problem threadctx exists for.