Shared memory for AI coding agents

Solenta supervises a small local memory server (HTTP + MCP, SQLite with full-text and vector search). When it is healthy, it is injected into agent sessions automatically, so decisions and gotchas one thread stores are visible to the next. The Memory tab in the right panel lets you search, read and store entries yourself. The server is localhost-only and bearer-token gated.

Entries carry provenance (which agent wrote them), and each agent builds a trust score from how its entries hold up, which ranks what comes back on a search. Facts can carry file:line, thread or commit citations; before a fact is injected, those file citations are checked against the current worktree and contradicted entries are invalidated. Assistant replies in the transcript carry the same idea as tier labels: a chip for repo paths the turn read or cited, one for shared-memory tools, one for GitHub issue or PR refs. A message long enough to make a claim (240 characters) with none of those sources is tagged model prior knowledge. Short chatter is left unlabeled. The stored embeddings are reused to fold near-duplicates together and to surface entries that contradict each other, and the memory graph records co-occurrence edges so related entries can be walked, not just matched on text.

Above facts sit strategy entries: distilled how we work here notes that survive a single thread. memory_distill is how a finished run gets folded into that layer instead of leaving a pile of one-off observations.

Config doctor lives in Settings, Memory, under Project tools, next to the code map. It lints the repo's AGENTS.md, CLAUDE.md, and sibling instruction files against a six-axis rubric (commands, architecture, patterns, conciseness, currency, actionability) and against shared-memory conventions, strategies, and verified decisions. Preview generates those files from memory without writing; Write from memory confirms, then writes AGENTS.md / CLAUDE.md / GEMINI.md. Scoring and generation are deterministic, no model in the loop.

A hypothesis ledger records what an agent tried and ruled out. The next thread on the same problem is handed that list, so it does not spend its first ten minutes re-walking dead ends. A per-repo code index of symbols is built once and injected into every dispatched prompt, so a fresh worker starts knowing where things live.

Each entry has an inclusion mode that decides when it is injected: always (the default), glob (when a file in play matches its globs), auto (when the prompt shares most of its title's words) or manual (when the prompt mentions # plus the first eight characters of its id). Conditional entries still show up in search.

Save as memory… in a finished thread's menu drafts a shared memory entry from the run. You review and edit the draft before anything is stored.

Two repos with the same folder name get separate memory scopes. The first keeps the plain name; later ones get a short suffix. Settings, Memory lists repos that share a folder name, with a Rename box per scope that moves its memories along.

Browse the full memory library

The Memory tab starts with your project's entries. Search by text or filter by knowledge, convention, strategy or task. Use + to add one, and load older memories to browse past the first page. Expand an entry to read its body and citations. When memories need a decision, a review banner opens the queue. The footer shows when consolidation last ran and links to Settings for the code map and config doctor.

Switching projects discards the previous project's config-doctor preview and write confirmation, so a stale preview cannot write another repository's instructions.

Recall and review

Inclusion modes control when an entry is injected. Always includes it in bootstrap context. Glob matches files, auto uses the prompt's overlap with the entry title, and manual includes an entry when the prompt names its shortened memory ID. Conditional entries remain searchable.

Stored facts can become stale. Checking a file citation does not prove that every remembered statement is still correct. Review recalled context and the resulting diff, and use a verify command for the project's checks.

Local storage and model requests

The shared memory database stays local. Your chosen agent CLI still sends its prompts to its provider, as it would when you ran that CLI yourself. Recalled entries included in a prompt follow that provider's normal request path. Local storage does not mean that a model request contains no project context.

Connect a local MCP client

The memory server and the coder-threads task server are separate MCP endpoints. The pairings described under External MCP pairing launch and track tasks. Do not use those pairing tokens as memory-server credentials.

For a local client that supports Streamable HTTP MCP and custom request headers, use the connection fields below. Solenta must be running with a healthy memory server. Read its current port and bearer token from memory-server.json in Solenta's application data directory. Do not post the token in a prompt or put it on a command line.

Field	Value
Transport	Streamable HTTP
URL	http://127.0.0.1:<port>/mcp, using the port in the memory-server configuration
Request header	Authorization: Bearer <token>, using that configuration's memory-server token

Client configuration field names differ. Keep the endpoint on localhost and use the client's private configuration or secret storage for the bearer token. The memory server's endpoint is not the public task-pairing URL. Read tools such as memory_bootstrap and memory_search use the project scope supplied by the client.

Questions about shared memory