One memory server, every MCP client
One server. All your agents share the same memory. No lock-in.
Dev-native proof, without fabricated proof
The home page uses developer-native signals only: package download counts, registry status, and roadmap-labeled source availability. It does not invent customer quotes, logo walls, or measured result numbers.
Client edges, managed engine
Public repo pendingThe open-source split is documented without linking to a private or unpublished repository as public proof.
View open-source splitMCP Registry · Smithery · Glama
Launch listings pendingRegistry links appear here only after each listing is accepted. The page does not present submission targets as live proof.
43 npm downloads last month
Fetched from npm for @answer-engine/mcp-server during the static build.
How the memory loop works
The product flow stays simple: bring sources in, normalize memory, recall it through MCP, and inspect the trail behind an answer.
Ingest
Bring in web pages, Atlassian content, CSVs, documents, and other source material without turning each agent into a bespoke ingest job.
Remember
Store tenant-scoped memory with summaries, tags, and lineage so agents can reuse context instead of starting cold in each tool.
Recall
Expose the same memory through MCP so Claude Code, Cursor, Codex, Gemini CLI, and any compatible client query one shared source of truth.
Inspect
Trace what was recalled, what source it came from, and what memory was superseded so the answer remains explainable.
See what your agent remembered — and what it forgot
The wedge is not a performance claim. It is the inspectable cold path: source lineage, superseded memory, and missing-context evidence an operator can review when an answer needs proof.
Memory should be auditable, not mystical.
The inspector shows which sources were recalled, what memory was skipped, and where the system needs better source coverage. That lets teams improve memory without pretending a measured result exists.
View inspector roadmapInspector screenshot slot
Real screenshot pending the product inspector asset. This frame is intentionally labeled so it cannot read as shipped proof.
Trust controls belong on the first page
Memory is sensitive infrastructure. The page states the controls that matter at the install decision and routes deeper evaluation to security.
Choose the path that matches your use case
The home page routes the developer who wants an install, the AI team evaluating shared memory, and the agency separating client contexts.
Install memory for the agents you already use.
Start with MCP, inspect what was recalled, and keep memory portable across local agent tools.
AI teamsShared memory infrastructure for shipped agents.
Evaluate the managed engine, tenant boundaries, and the roadmap toward org-shared controls.
AgenciesPer-client memory without rebuilding the platform.
Keep customer contexts separated while giving each engagement an inspectable source of agent memory.
Open where portability matters, managed where operations matter
The open-source promise is deliberately narrow: installable client surfaces stay inspectable and portable, while the hosted engine, index, and billing remain managed services.
MCP server and CLI
The installable edge is open: @answer-engine/mcp-server
and @answer-engine/cli. Read it, run it, and keep
your agent client from being locked to a single app.
Hosted engine, index, and billing
The service that stores tenant-isolated memory, runs the hosted index, and handles account/billing operations is managed. This page does not imply the full engine is open source.
Read the splitShipping next, labeled as next
These items are roadmap work, not available-now claims. Each one uses the Roadmap chip so the claim ledger remains visible in the page body.
Give your agent inspectable memory from your own sources.
Install the MCP server, connect a source library, and route every compatible agent to the same tenant-isolated memory layer.