myco-brain

Persistent, source-traceable memory for AI agents — self-hosted on your own Postgres, with no API keys required to run.

• Source-traceable. Every fact traces to the document it came from (brain_why) — no trust-me summaries.
• Trust that compounds. Independent corroboration raises a fact's confidence; a contradiction supersedes it — kept and audited, never silently overwritten.
• Keyless & local-first. Full-text + semantic search and the knowledge graph all run with zero hosted dependency — add an Anthropic key only for the most accurate graph.
• Yours. Apache-2.0, plain Postgres tables, 13 MCP tools. Works with Claude, Cursor, Windsurf, Continue, Zed.

Who it's for: dev teams running agents that need one shared memory · agencies needing hard per-client isolation · anyone who wants their assistant to remember across sessions — import your ChatGPT / Claude history (from your data export) and your AI knows you on day one.

Built solo by a growth marketer — not a career engineer — directing AI coding agents over ~3 months. How it was built ↓

The usual fix for agent amnesia — letting an LLM maintain its own memory — fills it with duplicates, hallucinated summaries, and confident answers nobody can trace. Myco Brain is built on the opposite contract:

The LLM proposes. Deterministic rules decide what becomes a fact. You set the bar — from corroboration-gated auto-promotion (the default) to strict human review of every fact (BRAIN_REQUIRE_HUMAN_REVIEW=1).

Claude, Cursor, Windsurf, Continue, Zed, and custom agents all share one memory backed by your own Postgres.

⭐ If the trust model resonates, a star helps others find it.

# 1. Boot the stack (Postgres + MCP server + extraction worker)
git clone https://github.com/thegoodguysla/myco-brain.git && cd myco-brain
docker compose up -d

# 2. Give your agent a memory — point it at any repo or folder
#    (no env needed: it finds the quickstart stack on localhost)
npx -y -p @mycobrain/mcp-server mycobrain-ingest github:your-org/your-repo

# 3. Connect your client (one-liner below), then ask across sessions:
#    "what did we decide about auth, and where is that documented?"
#    → answered from your docs, with the source cited.

[!TIP] Zero API keys, all the way down. Full-text search, semantic search (local embeddings), and the knowledge graph (local extraction) all run with no hosted dependency. Add an Anthropic key only if you want the most accurate graph.

MCP-native by design — your agent knows when to use memory, not just how. Most MCP servers expose tools and hope the model calls them. Myco ships a usage contract over MCP's instructions channel: the moment it connects, your agent knows to pull context before a task, save durable decisions, and cite sources with brain_why — no per-project prompting. Tune the policy in one copy-paste block: Teach your agent to use it well.

Quick links: 10-minute quickstart · Teach your agent to use it well · The trust engine · Benchmark — run it yourself · Run every proof · Who it's for · Environment variables · Architecture · Roadmap · Cloud waitlist

Memory that gets more trustworthy (compounding confidence)

Most agent memory overwrites facts silently. Myco Brain compounds them:

• An independent source agreeing with a fact raises its confidence (damped noisy-OR — ten chunks of one document corroborate nothing; only distinct sources count).
• A confident contradiction on a single-valued relationship (who you work for, where something is located) supersedes the old fact: it's closed and weakened — kept, never deleted — with the supersession recorded in an audited claims ledger.
• Ask brain_why about any fact and you get its distinct source count (per relationship, not per mention), its confidence trend over time ("0.8 → 0.86"), and any superseded history. Contradictions stay visible. Your memory can't gaslight you.

works for → Halcyon Labs           0.55  [SUPERSEDED — kept, not deleted]
works for → Driftwood Analytics    0.90  [ACTIVE]
claims ledger: old fact superseded_by → new fact (audited)

Proof: npm run test:compounding — the full lifecycle runs against a live database in seconds, no LLM required.

The schema evolves with your data (dynamic schema)

• The extraction worker notices entity kinds and relationship types your catalog doesn't have yet and proposes them (brain_stats: "Brain proposed 3 new types from your data").
• Promotion is yours by default — or opt into auto-promotion for types corroborated across enough distinct source documents (BRAIN_SCHEMA_AUTO_PROMOTE=1), counted per document, not per mention, so two documents passed back and forth can't manufacture consensus. One chatty document can never promote anything.
• A promoted type stays scoped to the workspace that earned it — one client's vocabulary never leaks into another's catalog (see per-client isolation).

Proofs: npm run test:dynamic-schema, npm run test:schema-promotion.

You pick the trust dial:

Mode	Behavior
Default	Confident facts auto-promote; novel types wait for review
BRAIN_REQUIRE_HUMAN_REVIEW=1	Strict curation — nothing the LLM proposes touches the canonical graph without a human decision
BRAIN_SCHEMA_AUTO_PROMOTE=1	Corroborated new types promote themselves, audited

When something is waiting on you — novel types in default mode, or everything in strict mode — review it from the command line:

mycobrain review                 # list pending entities, relationships, types
mycobrain review approve <id>    # promote it into the graph
mycobrain review reject  <id>    # reject it (kept and audited, never deleted)

Proof: npm run test:review — approving actually lands the entity / edge / type in the canonical graph; rejecting never does.

Private memories, shared knowledge

Multi-agent teams get real isolation: documents marked private are readable only by the agent that created them — enforced in every read tool, on top of workspace row-level security. Workspace memory stays shared. Proof: npm run test:sharing (a two-agent visibility matrix). Like workspace isolation, it binds only under the least-privilege brain_app role (security note).

One isolated workspace per client — built for agencies

Put each client in their own workspace, share one agency-wide playbook, and the guarantee you sell is Postgres row-level security — a session scoped to Client A cannot return Client B's rows. The agency starter kit provisions it (one command) and ships the least-privilege DB role that makes the isolation actually bind. Proof: npm run test:agency — Client A sees zero of Client B's facts.

[!IMPORTANT] Isolation binds only under the least-privilege role. RLS does not constrain a Postgres superuser, and the zero-config quickstart's default brain role is a superuser (fine for a single-workspace self-host — there's nothing to isolate). Before you put more than one client in one database, run the app as the NOSUPERUSER brain_app role the agency kit ships; mycobrain-doctor flags a superuser connection. Multi-tenant isolation is a guarantee of brain_app, not of the default quickstart role.

RLS decides which rows a tenant can read; this setting decides which tenant a request is — the step before RLS. On the stdio server, identity is taken only from the server's environment by default: a workspace_id, agent_id, or api_key supplied in tool-call arguments is ignored, so even a prompt-injected agent can't pass workspace_id: "<someone-else>" to reach another workspace. (For brain_ keys, identity comes from the key string and nothing else.)

Set BRAIN_TRUST_REQUEST_IDENTITY=1 only when you front the server with a real multi-tenant gateway that authenticates each request and maps it to a tenant itself — then per-request identity is honored (and a service-role JWT must equal BRAIN_SERVICE_ROLE_KEY, not merely look like one). Single-tenant self-hosts need none of this — their identity is already environment-derived.

Query over HTTP (read-only)

Not everything speaks MCP. For a web app, an automation, or a partner backend, mycobrain-rest puts a small read-only API in front of the brain — exactly two tools, search and why, plus health:

mycobrain-rest                                  # → http://127.0.0.1:8787

curl -s localhost:8787/search \
  -H "Authorization: Bearer brain_<ws>_<agent>_<secret>" \
  -d '{"query":"what did we decide about pricing?","limit":5}'

• Scoping: the key scopes every query to its workspace (same RLS as MCP), and there are no write routes. Like MCP, this binds only under the least-privilege brain_app role (security note) — never expose REST as the default brain superuser (mycobrain-doctor flags it).
• Key verification: installs migrated to …_agent_api_key_verification.sql verify each key's <secret> against agent_api_keys once a secret is registered (register/rotate via brain_set_agent_api_key_secret(...)). Until then the key acts as a bearer token; set BRAIN_REQUIRE_API_KEY_SECRET=1 to require a registered secret before exposing REST.
• Binding: loopback by default — set BRAIN_REST_HOST=0.0.0.0 behind your own TLS/proxy only when you mean to expose it, and treat the key like a password.

Proof: npm run test:rest.

Five Verified Demos

1. Cross-session recall

Save a fact in one conversation:

Save a memory: the board meeting is every Wednesday at 9 AM Pacific.

Start a fresh conversation and ask:

What time is the board meeting?

Expected result: the new session retrieves the stored fact instead of relying on chat history.

2. Cross-agent shared memory

Write from one client:

Save a memory: Acme's renewal call is on October 15 with Jordan.

Read from another client:

What is Acme's renewal date?

Expected result: both clients read the same shared memory because the source of truth is Postgres, not a single chat thread.

3. Provenance for answers

Ask brain_why about any fact and get the source chain — not a trust-me summary. Real output for an entity built from the demo corpus:

{
  "subject": { "kind": "entity", "name": "Mara Quinn" },
  "evidence": {
    "mention_count": 4,
    "source_document_count": 4,
    "summary": "Supported by 4 mentions across 4 source documents."
  },
  "source_proposals": [
    { "extracted_by": "ollama:llama3.2:3b", "confidence": 1, "state": "auto_promoted",
      "source_hyobject_id": "8e31414c-…" }
  ]
}

Every accepted fact traces to the document(s) it came from and how it was extracted.

4. Document ingestion with sources

Ingest a file or URL:

Ingest ./docs/customer-handbook.pdf and summarize the onboarding checklist with sources.

Expected result: the document is chunked, indexed, and cited back through retrieval.

5. Graph relationships

Ask:

Show related entities for Acme and explain how they connect.

Expected result: relationship queries surface connected people, documents, and entities — and the entity-to-entity edges the extraction worker builds (e.g. Mara Quinn —manages→ Northwind Coffee) — instead of flat vector matches. Build this graph locally with Ollama, no API key required.

All demos are code, not screen recordings — demos/ re-renders them deterministically against a fresh stack (npm run demo:render -- all).

How Myco compares

Different tools make different tradeoffs; this compares architectural approaches, not benchmarked head-to-heads — when retrieval recall is high the answer model becomes the bottleneck, so cross-system score comparisons mislead (see the benchmark section).

	Typical LLM-maintained memory	Framework memory (e.g. LangChain)	Myco Brain
Reproducible benchmark	Self-reported	—	Harness ships in-repo — reproduce the number yourself
Fact extraction	LLM-based	LLM-based	Deterministic write path; LLM output enters only via gated proposal queues
Contradicting facts	Coexist as independent records	Possible	Superseded, never overwritten — audited claims ledger
Fact confidence	Static	—	Compounds with independent evidence, falls on contradiction
Hallucinated facts	Possible	Possible	Constrained out of the write path
Provenance	Partial	Partial	First-class via brain_why (source + audit trail + confidence trend)
Shared memory	Depends on app wiring	Depends on app wiring	Native Postgres source of truth, multi-agent with per-object privacy
Data portability	Vendor / framework shaped	Framework shaped	Plain Postgres tables

Get Started In Under 10 Minutes

Verified local path: Docker Compose from a fresh clone.

git clone https://github.com/thegoodguysla/myco-brain.git
cd myco-brain
docker compose up -d

What starts:

• Postgres 16 + pgvector
• MCP server
• Extraction worker

No API keys required to boot — here's what each capability needs:

Capability	Out of the box?	To enable
Full-text (BM25) search	✅ immediately	nothing
Semantic search	needs embeddings	BRAIN_EMBED_PROVIDER=ollama (local, keyless)
Knowledge graph	needs an extractor	Ollama locally (keyless) or BRAIN_ANTHROPIC_API_KEY (most accurate)

Confirm it's healthy in one command. mycobrain-doctor doesn't just check that env vars are set — for the local Ollama path it live-verifies the setup (pings Ollama, confirms the embed/extraction models are pulled, and runs a real embed + generation), then checks the extraction backlog and review queue. It exits non-zero only on a real failure (a red line), so green means it works:

npx -y -p @mycobrain/mcp-server mycobrain-doctor

Add --fix to have it offer to pull any missing Ollama models for you:

npx -y -p @mycobrain/mcp-server mycobrain-doctor --fix

Connect your client

Recommended — guided setup. One command walks you through connecting an agent, with consent at every step:

npx -y -p @mycobrain/mcp-server mycobrain-setup

It runs pre-flight checks (each with an offered fix), verifies pgvector and a real write to your database, wires up your MCP client (Claude Code, Claude Desktop, Cursor, Codex, Windsurf), and offers a one-tap import of your ChatGPT or Claude data export if the zip is already in ~/Downloads. Each connected client gets its own agent identity, so later recalls show which tool a memory came from. Prefer to drive it yourself? The manual paths are below.

Claude Code — by hand (uses the quickstart stack's seeded, public localdev credentials):

claude mcp add myco-brain \
  --env DATABASE_URL=postgresql://brain:brain@localhost:5432/brain \
  --env BRAIN_API_KEY=brain_00000000-0000-0000-0000-000000000001_00000000-0000-0000-0000-0000000000a1_localdev \
  -- npx -y @mycobrain/mcp-server

Restart Claude Code and the brain_* tools are live — the server hands every connected agent its usage contract automatically (when to recall, save, and cite), so it works well out of the box.

Claude Desktop — add this to ~/Library/Application Support/Claude/claude_desktop_config.json (Cursor and Windsurf take the same mcpServers block in .cursor/mcp.json / their MCP settings):

{
  "mcpServers": {
    "myco-brain": {
      "command": "npx",
      "args": ["-y", "@mycobrain/mcp-server"],
      "env": {
        "DATABASE_URL": "postgresql://brain:brain@localhost:5432/brain",
        "BRAIN_WORKSPACE_ID": "00000000-0000-0000-0000-000000000001",
        "BRAIN_API_KEY": "brain_00000000-0000-0000-0000-000000000001_00000000-0000-0000-0000-0000000000a1_localdev"
      }
    }
  }
}

Note: BRAIN_WORKSPACE_ID is derived from your brain_ API key, so it is optional — the Claude Code one-liner above omits it and works the same.

Then test the happy path:

Save a memory: the launch checklist lives in the ops folder.

Open a new session and ask:

Where does the launch checklist live?

Full setup guide: docs/quickstart.md

First run — the fastest path to your magic moment

Myco ships empty. The "whoa" lands hardest on your own data, so the recommended first step is to bring your history in:

# Guided getting-started — leads with importing your own history
npx -y -p @mycobrain/mcp-server mycobrain-onboard

# Import your ChatGPT or Claude export (~30s), then ask your agent about your past
mycobrain-ingest --from chatgpt-export ~/Downloads/<your-export>.zip
mycobrain-ingest --from claude-export  ~/Downloads/<your-export>.zip
#   → "what did I decide about <topic>?" answered from your own conversations.

Prefer to skip it? Just start using it — Brain remembers as you work. Or take a 60-second live tour on sample data that cleans up after itself (your workspace is left untouched):

mycobrain-onboard --tour

See it work with the demo corpus (optional sandbox)

Want a richer guided example? Load the included demo corpus — a small set of interconnected documents for a fictional agency and its client:

npx -y -p @mycobrain/mcp-server mycobrain-ingest ./examples/demo-corpus

Then ask any connected agent:

• "When does Northwind's rebrand launch, and who owns the account?"
• "What pricing model did we choose for Northwind, and why?"
• "Show me the source for that." — provenance via brain_why
• "Show my Myco memory stats." — health snapshot via brain_stats

Every answer traces back to the document it came from. No API key required.

The finale: the corpus contains a deliberate contradiction — one document says Devin Osei works for Lumen, a later one says he left for Harbor & Co. With the keyless local graph running, ask:

• "Who does Devin Osei work for? What changed, and how do you know?"

The old fact comes back superseded — kept, not deleted — with both source documents cited. That's the trust engine working on your data, not a demo script.

Done exploring? Clear only the bundled sample data (your own imports and memories are never touched) with:

mycobrain-onboard --reset-demo

Bulk-ingest a folder or repo

Point Brain at a directory or a GitHub repo and it indexes every text file — searchable across sessions, with each answer traceable to its source file.

npx -y -p @mycobrain/mcp-server mycobrain-ingest ./docs        # a local folder
npx -y -p @mycobrain/mcp-server mycobrain-ingest github:owner/repo   # a GitHub repo

No env needed against the quickstart stack — the CLI defaults to it. For your own Postgres or workspace, set the same env vars the MCP server uses (DATABASE_URL, BRAIN_WORKSPACE_ID, BRAIN_API_KEY).

Then ask any connected agent: "search my ingested files for the auth flow" or "show my Myco memory stats". Set GITHUB_TOKEN for private repos.

Build the knowledge graph — locally, no API keys

What separates Myco from a vector store is the graph. The extraction worker reads your ingested documents and:

• pulls out the entities — people, companies, projects, places;
• collapses duplicates so "Priya" and "Priya Raman" become one node;
• connects them with directed relationships — Mara Quinn —works for→ Northwind Coffee, never the reverse (the shipped prompt is direction-aware, and endpoints the model forgets to list are recovered automatically);
• and proposes new types it observes, so the schema grows with your domain.

You choose which model does the extraction. Nothing leaves your machine with Ollama; Anthropic produces the most accurate graph.

Two distinct, often-conflated quality measures on the 14-edge gold fixture (proof: npm run test:direction):

Metric	What it measures	Score
Directed accuracy	edges point the right way	86% (12/14, llama3.2:3b)
Edge survival	endpoints recovered, not dropped	~80% (11–12/14, gated ≥75%)

Option A — Local & free (Ollama, no API key)

# Install Ollama (https://ollama.com/download), then pull a model:
ollama pull llama3.2:3b

# Point the worker at it and restart:
echo "BRAIN_OLLAMA_BASE_URL=http://host.docker.internal:11434" >> .env
docker compose up -d

Option B — Most accurate (Anthropic, bring your key)

echo "BRAIN_ANTHROPIC_API_KEY=sk-ant-..." >> .env
docker compose up -d

If both are configured, Anthropic is used automatically (it's more accurate); force a choice with BRAIN_EXTRACTION_PROVIDER=ollama|anthropic.

Try it

Ingest a few documents, give the worker a moment, then ask a connected agent:

• "What entities are in my Northwind documents?" — brain_neighbors
• "How does Mara Quinn connect to Northwind?" — entity-to-entity relationships
• "Show my Myco memory stats." — watch the graph grow (brain_stats)

Either way, the canonical graph lives in your Postgres — the model only proposes; the database decides what becomes a durable fact.

Benchmark — run it yourself

The point here is reproducibility, not a single score — the LongMemEval harness ships in this repo, so you run the numbers yourself; we don't assert them.

Metric	Subset (500q)	Config	Score
End-to-end QA	oracle	reader gpt-4o-mini · judge gpt-4o	73.6%
End-to-end QA	oracle	strong reader (gpt-4o)	71.8%
Evidence recall@5 (Ev@5)	longmemeval_s	hybrid (vector + BM25)	89.2%
Evidence recall@5 (Ev@5)	longmemeval_s	keyless recency reranker	91.6%
Evidence recall@10	longmemeval_s	hybrid → recency	90.2% → 93.2%