Skip to content
stored
Sign inStart free

How it works

From empty workspace to memory that compounds

Five steps, no infrastructure. Create a workspace, point an agent at the remote MCP endpoint, and watch memory form: searchable across graph, vector, and wiki, and yours to govern. Built on the open-source agentwiki engine.

Create your workspaceSee the features
Signup to shared memory: create the workspace, issue an organization key, point an agent at the remote MCP endpoint, and watch memory start to form.

01 / 05

Create your workspace

Spin up an org with zero infrastructure

Sign up and create an organization. There is no Postgres to stand up, no pgvector to tune, and no MCP server to host. The workspace, the graph, and the remote endpoint are ready in seconds.

  • An org, an owner, and an API keyyour shared memory, scoped to your team
  • A remote MCP endpointone URL your agents will connect to
  • Nothing to runno database or server to provision or babysit
stored: new workspace

Workspace created

ready in seconds · nothing to provision

live
Organization
acme-research
Owner
you@acme.co
Role
owner
Org API key
mm_live_••••••••••••
https://mcp.stored.to/v1/sse
No PostgresNo pgvectorNo MCP server to run

02 / 05

Connect an agent

A URL and a key is the whole integration

Point any MCP-capable client at the remote MCP URL with your per-org API key. Claude Desktop, Cursor, and Claude Code each take the same endpoint and the same key: it is configuration, not code.

  • Remote MCP URL + per-org API keyno SDK to install
  • Claude Desktop, Cursor, Claude Codethe same remote endpoint for each
  • Read and write immediatelymemory tools register on connect

remote MCP config

URL + key

Same endpoint, same per-org key. Pick your client:

{
  "mcpServers": {
    "stored": {
      "url": "https://mcp.stored.to/v1/sse",
      "headers": {
        "Authorization": "Bearer mm_live_your_org_key"
      }
    }
  }
}
https://mcp.stored.to/v1/sseno SDK · no server to run

03 / 05

Agents write memories

Facts become entities and edges

As your agents work, they save what they learn. The engine extracts the entities and the relationships between them into a live graph, and stamps every memory with its source agent and timestamp from the very first write.

  • Extraction, not just storageentities and relationships, not loose text
  • Provenance from the startsource agent and timestamp on every memory
  • Straight into the shared graphone memory the whole team can reach
stored: agent writes a memorylive
claude-desktop ~ $

04 / 05

Retrieve

One query across graph, vector, and wiki

When an agent asks a question, a single query spans graph links, semantic vector matches, and long-form wiki context. The candidates merge into one ranked set, and on paid plans a premium reranker sharpens what surfaces first.

  • Graph + vector + wikievery signal searched in one pass
  • Merged, not siloedresults come back as one ranked list
  • Premium rerankeran extra ranking pass on Pro and above
memory.search: one query, three signals
what database does Acme run?
Graphentity links & relationships
Vectorsemantic similarity
Wikilong-form context
merge + premium reranker
  • graphAcme -[uses]→ Postgres 160.94
  • vector"prod DB is Postgres 16.2"0.89
  • wikiAcme · Infrastructure notes0.81

One ranked set, not three silos. The premium reranker sharpens ordering on Pro and above.

05 / 05

Govern

See where a memory came from: and fix it

Open any memory to inspect its provenance and history, then edit or delete what an agent got wrong. The memory is yours to govern, not the model's to guess; every change is logged and shared across your connected agents.

  • Provenance on every memorysource agent and timestamp, always
  • Edit or delete in a clickthe change is yours, not the model's
  • Not a black boxinspect, correct, and steer the memory

provenance & history

  • claude-desktopwrote "uses Postgres 16"· 2h ago
  • cursorconfirmed via repo scan· yesterday
  • claude-codecreated entity Acme· last week
Edit memoryDelete

Correct the model when it drifts; every change is logged and shared across your team's connected agents. No black box.

See it move

The product, drawn as it runs

The same end-to-end story as three live scenes: the write path a memory takes, the read path a question takes, and the one-endpoint architecture underneath. Built from the real rows, protocol, and workspace.

Watch a memory form

An agent saves what it learned. The call travels over the remote MCP endpoint into stored, which uses your OpenAI key to extract entities and relations, and the structured memory lands in a live Postgres + pgvector graph.

organization memory · shared ledger
capturing3 memories
Memory lives in the engine; the Cloud surfaces it read-mostly.claude-code
Agents reach memory via a remote MCP endpoint + per-org API key.cursor
agentwiki uses Postgres + pgvector for hybrid memory retrieval.claude-desktop

Recall in one query

One question fans out across graph links, semantic vector matches, and long-form wiki context at once. A reranker merges the candidates into a single ranked answer and hands it straight back to the agent.

retrieval · hybrid search
which database does the team use?
1agentwiki uses Postgres + pgvector for hybrid memory retrieval.0.91
2Memory lives in the engine; the Cloud surfaces it read-mostly.0.74
3Agents reach memory via a remote MCP endpoint + per-org API key.0.62

3 results · ranked by hybrid relevance · same answer in every tool

Zero infrastructure

Every MCP-capable client points at one remote URL with your org key. Behind it, hosted stored runs the open-source agentwiki engine on managed Postgres with pgvector; there is nothing for you to run.

connect · one MCP endpoint
Claude Code
Cursor
Windsurf
Claude Desktop
Shared memoryone context4 tools in sync

connect each tool once · every agent stays current

Connect once. Remember everything.

Start free