Giving AI coding agents memory that survives a restart

The problem

Close Cursor, Claude Code, or Codex, and the context goes with it. The decisions your team made last sprint, the "we tried that already, it broke," the naming conventions you agreed on three weeks ago in a Slack thread: gone. Next session the agent starts from zero, and you end up re-explaining the same things, to the same agent, over and over.

Palace fixes that: persistent, searchable memory for AI coding agents. It's an MCP server, written in Rust, that plugs into the tools you already use with no workflow change.

How it actually works

palace-rs is the open source core (MIT licensed). Install it, and your agent gets a local, persistent memory. It exposes a set of palace_* tools over MCP, so any MCP-compatible agent connects with no config change.

Retrieval is hybrid BM25 plus cosine search over your own stored memory, with source-grounded provenance on every hit (recall@5 = 0.981 on LongMemEval). Memory is organized into wings, rooms, and drawers, roughly workspace, project, and individual memory entry, and agents are project-aware: they detect whether the current repo is a known workspace and act on it automatically, no manual setup per project.

For a team, Palace Server adds the shared layer on top:

• A shared knowledge graph: temporal entity relationships, so "we decided X on this date" stays queryable and versioned, not just a fact that silently goes stale.
• Team diaries: structured session context (AAAK format) so the next agent, on anyone's machine, can warm start from the last person's session instead of starting cold.
• Workspace permissions backed by Postgres row level security, so contractors see what they need and sensitive projects stay scoped.

The part that usually surprises people

It's a single Rust binary, about 10MB, and it runs comfortably on a small VM or a Raspberry Pi. No JVM, no Node, no Python runtime required. Embeddings run locally through ONNX, license verification is offline capable, and nothing leaves your network unless you decide it should. Full air-gapped deployments are supported.

Connecting a team is two commands: palace remote set to point a developer's local CLI at the shared server, then palace remote on. Same MCP tools, same workflow, now reading and writing against team memory instead of a local file.

Try it

palace-rs is free forever, solo, on GitHub: github.com/AncientiCe/palace-rs. If you want to run the shared, team version with your own setup first, there's a quick self-serve trial now too (work email, no card, no sales call) at palacememory.com/pricing.

Comments

[P O]

the provenance and project-aware bits seem useful. for a shared setup, i'd also document retention and deletion rules, then run a small export/import test before trusting a schema migration. otherwise team memory can become another single point of failure.