INITE Brain

io.github.inite-aiPublished by GitHub account inite-aiv2.7.0Updated Nov 3, 2026

Long-term memory for AI agents: a bitemporal knowledge graph with cited answers.

The publisher's own server: BrainDog

VerifiedStreamable HTTPWeb executableDatabasesKnowledge & MemoryDeveloper Tools

Overview

INITE Brain's hosted MCP server (brain.inite.ai); no sign-in required; Streamable HTTP; 30 tools.

No AI overview yet: these facts come from the registry entry and the server itself.

Endpoint
brain.inite.ai
Last checked

Installation

In SourceWeft

  1. Open INITE Brain in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.inite-ai%2Finite-brain-service/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "inite-brain": {
      "type": "http",
      "url": "https://brain.inite.ai/mcp"
    }
  }
}

README

[INITE Brain — memory with context]

INITE Brain

Open-source memory for AI agents: a bitemporal knowledge graph with provenance, over MCP and REST.

[CI] [Latest release] [License: AGPL-3.0-or-later] [Docker pulls] [Image: arm64 | amd64] [Stars] [PRs welcome] [MCP native]

[Install in Claude Code] [Add to Cursor] [Add to VS Code] [MCP Registry]

Website · Quick start · Architecture · Domain Packs · Getting started · Docs · Agent guide

Quick start

Needs Docker with Compose v2, openssl, and an OpenAI API key (the default model configuration). Runs the released image (linux/amd64 and linux/arm64) with SurrealDB; no clone, no build.

bash
: "${OPENAI_API_KEY:?export OPENAI_API_KEY first}"mkdir inite-brain && cd inite-braincurl -fsSLO https://raw.githubusercontent.com/inite-ai/inite-brain-service/main/docker-compose.quickstart.ymlBRAIN_KEY="brain_$(openssl rand -hex 24)"KEY_HASH="$(printf %s "$BRAIN_KEY" | openssl dgst -sha256 -r | cut -d' ' -f1)"cat > .env <<EOFBRAIN_VERSION=2.4OPENAI_API_KEY=$OPENAI_API_KEYBRAIN_API_KEYS='[{"keyHash":"sha256:$KEY_HASH","companyId":"co_demo","scopes":["brain:read","brain:write"]}]'SURREALDB_PASSWORD=$(openssl rand -hex 24)SURREALDB_SCOPED_PASS=$(openssl rand -hex 24)FORGET_HMAC_KEY=$(openssl rand -hex 32)EOFdocker compose -f docker-compose.quickstart.yml up -d --waitexport BRAIN_URL=http://localhost:3030 BRAIN_KEYcurl "$BRAIN_URL/health"echo "API key (shown once, only its hash is stored): $BRAIN_KEY"

Then remember something and ask about it, or point an MCP client at http://localhost:3030/mcp with Authorization: Bearer $BRAIN_KEY. BRAIN_VERSION takes X.Y (newest patch of that release) or vX.Y.Z; :latest is overwritten by the main-branch deploy. The first start downloads the local ONNX models into a volume, so the first write can take a few minutes; later ones do not. Hosted service, running from source, and production: Getting started.

Why not Mem0, Zep or Letta?

  • Mem0 is quicker to adopt: an add/search API, a managed platform and many framework integrations. Brain asks for more up front (a tenant, scoped keys, userId on personal memory) and in exchange keeps both valid time and knowledge time on every fact. A conflicting write supersedes the earlier fact or is parked as COMPETING; it does not silently overwrite.
  • Zep (Graphiti) is the closest design: Graphiti is also a temporal knowledge graph, and you can embed it as a Python library over a graph database. Choose it if you want memory inside your own process. Brain is a service: a separate database per tenant, API keys scoped to read, write and admin, PII controls, and GDPR forget_entity with tombstones.
  • Letta is an agent runtime in which the agent edits its own memory. Use it when you want the agent loop and its memory in one server. Brain is memory only: the agent stays in Claude Code, Cursor, Codex or your own code and reaches Brain over MCP (Streamable HTTP, or the stdio shim @inite/brain-mcp).
  • Answers can abstain. synthesize ends each claim with the id of the fact it rests on, a verifier checks the support, and strict mode returns no answer rather than an unsupported one. Each fact keeps a pointer to the conversation or document it came from.
  • No borrowed benchmark numbers. We do not set our memory-accuracy results against other systems' self-reported scores, which mostly use lenient judges. How we measure: docs/eval-protocol.md.

Part of the INITE Triad: Brain verifies the tokens INITE Auth issues, as INITE Billing does; the contract between them is the Triad contract. Run all three with one compose file: inite-ai/inite-triad.

What Brain is

Brain gives an agent memory between conversations: what was said, what changed, which entities are involved, and what supports an answer. A bitemporal graph stores structured facts and relationships; source episodes preserve context; scenes and beliefs capture events and evolving state. Domain Packs adapt that memory to a product's vocabulary and lifecycles without forking the engine.

Run Brain on your infrastructure or connect to the hosted service at brain.inite.ai. The web app provides memory search and exploration; REST and MCP provide the integration surface.

Why Brain

  • Memory with its context. Retrieve structured facts, source passages and, when enabled, scenes and beliefs. Follow provenance back to the supporting conversation, document or evidence fragment.
  • Changes stay inspectable. Facts carry valid time and knowledge time. Updates can supersede earlier facts; unresolved disagreements remain COMPETING. Retraction preserves history; administrative forgetting deletes associated records and leaves tombstones.
  • A model of your domain. Packs define typed predicates, extraction guidance, scene schemas, state transitions, verification and retention hints, and optional media capabilities and MCP tools.
  • Scope is explicit. Each tenant has a separate database. Personal memory uses userId; omitting it selects tenant-global memory. Key scopes, ABAC policies and PII controls further constrain access.
  • Answers can be checked. Hybrid search, graph retrieval and multi-hop gather evidence. Synthesis cites it and runs verification; strict guardrails can abstain when support is insufficient.

Architecture

Brain separates source material, derived memory and the read path. This is a conceptual view; individual ingestion routes and retrieval profiles activate different parts of it.

mermaid
flowchart LR  input["REST / MCP<br/>conversations · documents · facts"]  raw[("Source records<br/>documents · episodes · evidence")]  derive["Indexers and scene builders<br/>candidates · entity resolution · conflicts"]  memory[("Connected memory on SurrealDB<br/>facts + graph · scenes · beliefs")]  retrieve["Retrieval<br/>semantic + lexical · graph · multi-hop"]  answer["Synthesis + verification<br/>answer with citations or abstention"]  packs["Domain Packs<br/>vocabulary · memoryModel · tools"]  media["Evidence registration / upload<br/>scan hook · trusted processors"]  input --> raw  input --> derive  media --> raw  raw --> derive  derive --> memory  memory --> retrieve  raw --> retrieve  retrieve --> answer  packs -. "domain configuration" .-> derive  packs -. "capabilities and consent" .-> media
Memory layerWhat it preserves
Facts and entitiesTyped claims, canonical entities, relationships, confidence, source attribution and temporal history.
EpisodesSource turns and conversation context that derived memory can point back to or be rebuilt from.
ScenesBounded events with gists, entities, state changes and source links. Optional gist embeddings and a scene retrieval lane make them searchable alongside other evidence.
BeliefsDerived state with revision history and supporting scenes. Pack-projected state deltas can feed belief promotion.
EvidenceAssets, located fragments, processing runs and derived representations, with links to the memories they support.

Rebuildable memory. Derived worlds can be rebuilt from retained episodes in a staging version. Readers stay pinned to the previous world until promotion. Scene maintenance can process dirty conversations on a schedule, with budgets, leases and metrics; it can compose scenes and promote supported beliefs.

Configurable retrieval. Retrieval profiles select mechanisms for the corpus and question. Semantic and lexical search, graph expansion, reranking, raw passages, scene retrieval and belief retrieval are distinct capabilities. A known entity can enter through graph_retrieve; a question spanning relationships can use search_multi_hop.

Separate serving and background work. The NestJS service uses a SurrealDB-backed job queue, leases and worker-thread offloads. Run the image as one process or split PROCESS_ROLE=api|worker; see the operations guide.

The code includes capabilities that are opt-in, not a promise that every installation runs every layer. Scene construction, scene serving, belief promotion, evidence upload/processing and pack projections have separate gates. Check the architecture, operations and flag definitions for scenes, evidence and pack projections when enabling them.

Domain Packs

A pack is a versioned JSON manifest installed per tenant. It tells the engine how to interpret a domain's material. Pack-derived observations remain candidates for the core pipeline to validate and resolve.

A pack can declarePurpose
predicatesTyped vocabulary, value constraints, conflict semantics, decay and PII classes.
extractionProfile, evalFixturesDomain instructions, examples and extraction checks.
memoryModelScene schemas, state models and transitions, attention hints, verification rules and advisory retention hints. Also declares supported modalities, requested processor capabilities and raw-evidence policy.
indexer, seedDocumentsParticipation in document indexing and knowledge supplied with the pack.
mcpToolsAdditional agent tools, subject to explicit operator consent.

The industry pack library includes:

PackExample memory models
real_estateListings, tenancies and permits.
fintechLicenses and certifications.
medicalDrug ontology, prescription and approval lifecycles.
legalAgreements, obligations and legal matters.
insurancePolicy and claim lifecycles.
hrPositions and employee lifecycles.

For example, real_estate declares the listing path listed → under_offer → sold, as well as withdrawal and return-to-market transitions. It distinguishes viewing and closing scenes, with an ephemeral retention hint for a viewing and a durable hint for a closing.

The built-in code_memory pack covers engineering decisions, rationale, invariants, gotchas and change lifecycles. Use record_decision, why and recall_decisions to retain the reasons behind the code. The six industry packs are distributable; built-in code memory is part of the core seed.

Author and distribute. Scaffold with pnpm pack:init my_pack, validate, optionally sign, publish to a registry and install per tenant. Registry versions are immutable, installs are checksum-pinned, and signature requirements follow the server's trust policy. Registry and marketplace support discovery, publisher profiles, mirroring and optional billing.

Consent is part of installation. The current first-party industry packs declare media capabilities, so installing them requires reviewing that section and passing --accept-modalities. This authorizes the declared capabilities; it does not supply a missing processor or enable every server feature. Pack MCP tools have a separate consent path. Built-in code_memory media declarations also do not, by themselves, activate media processing.

Full authoring, signing and installation commands: Domain Packs standard · MCP pack tools · pack evaluation.

Getting started

Use the hosted service

Hosted brain is provisioned per company: a tenant (companyId) and scoped API keys. Sign in and issue one on the keys screen — it shows the key once, alongside ready-to-paste configuration for Claude Code, Claude Desktop, Cursor, VS Code, Codex CLI and Goose. If your workspace has not been provisioned yet, ask at [email protected].

bash
export BRAIN_URL="https://brain.inite.ai"export BRAIN_KEY="brain_YOUR_API_KEY"

Keys can also be issued over the API by any credential you already hold — POST /v1/keys mints one no wider than the caller's own scopes, and POST /v1/keys/{id}/revoke takes it back. The same endpoints work on a self-hosted deployment, so the env-var key below is only ever a bootstrap.

Run from source

Prerequisites: Node.js 24.9+, pnpm 10 and Docker Compose. The default model configuration needs an OpenAI API key. Local embeddings and alternative model providers are configuration choices; see operations.

bash
git clone https://github.com/inite-ai/inite-brain-service.gitcd inite-brain-servicepnpm install --frozen-lockfilecp .env.example .env# Set OPENAI_API_KEY in .env for the default model configuration.

Create a local read/write key. This appends a generated key and its registration to your development .env; Brain authenticates against the SHA-256 hash.

bash
node <<'JS'const { randomBytes, createHash } = require('node:crypto');const { appendFileSync } = require('node:fs');const key = 'brain_' + randomBytes(24).toString('hex');const keys = [{  keyHash: 'sha256:' + createHash('sha256').update(key).digest('hex'),  companyId: 'co_demo',  scopes: ['brain:read', 'brain:write'],}];appendFileSync('.env', '\nBRAIN_KEY=' + key + '\nBRAIN_API_KEYS=' + JSON.stringify(keys) + '\n');JS
docker compose up -d surrealdbpnpm start:dev

In a second terminal, from the same directory:

bash
export BRAIN_URL="http://localhost:3000"export BRAIN_KEY="$(node --env-file=.env -p 'process.env.BRAIN_KEY')"curl --fail-with-body "$BRAIN_URL/health"

For the full container setup, use docker compose --env-file .env up -d --build instead of pnpm start:dev. The app service publishes no host port — that is what lets --scale brain=N run several replicas — so copy docker-compose.override.yml.example to docker-compose.override.yml first; it maps host 3030, and BRAIN_URL=http://localhost:3030 then works for the requests below. The Compose defaults are for local development; production credentials and topology are covered in deployment.

Remember something, then ask about it

Text in, facts out. Brain captures the turn, extracts entities and claims, and runs each one through bitemporal conflict resolution:

bash
curl --fail-with-body -X POST "$BRAIN_URL/v1/ingest/mention" \  -H "Authorization: Bearer $BRAIN_KEY" \  -H "Content-Type: application/json" \  -d '{    "text": "Maria moved to Berlin in June and prefers morning appointments.",    "userId": "user_42"  }'
curl --fail-with-body -X POST "$BRAIN_URL/v1/search" \  -H "Authorization: Bearer $BRAIN_KEY" \  -H "Content-Type: application/json" \  -d '{ "query": "where does Maria live", "userId": "user_42", "limit": 5 }'

Use your application's stable user ID on both writes and reads. Omit userId on both only for tenant-global memory. The userId is also who is speaking: a first-person turn ("I moved to Berlin") lands on the user's own entity, and "where do I live?" on /v1/synthesize is answered to them. The memory learns the user's name from them — "I'm Maria" becomes a name fact on their own entity — or from your onboarding write: /v1/ingest/fact with entityRef: { "vertical": "user", "id": "user_42" }, predicate: "name", the same userId. (A speaker anchor { "vertical": "user", "id": "user_42", "role": "speaker", "name": "Maria" } on a mention names them too.) To relay someone else's words under the user's scope, anchor that person as the speaker instead. Until a name is learned, workspace_status and /v1/users/:userId/profile say so — ask once, record it.

Record a fact you already know

When the claim is already structured — a CRM field changed, an event fired — skip the extractor and state it. The response says what the resolver decided (INSERTED, SUPERSEDED, COMPETING…), not just that the write happened:

bash
curl --fail-with-body -X POST "$BRAIN_URL/v1/ingest/fact" \  -H "Authorization: Bearer $BRAIN_KEY" \  -H "Content-Type: application/json" \  -d '{    "entityRef": { "vertical": "rent", "id": "cust_42" },    "predicate": "complained_about",    "object": "late maintenance",    "validFrom": "2026-09-01T10:00:00Z",    "userId": "user_42",    "source": { "vertical": "rent", "messageId": "msg_1" }  }'

The local key above has no administrative scope; pack installation and forgetting require an appropriately scoped operator key. More: getting started.

Connect an agent

Claude Code — one command

bash
/plugin marketplace add inite-ai/inite-brain-service/plugin install inite-brain@inite

That installs the MCP server, the six skills, and the lifecycle hooks together: SessionStart injects what Brain already knows about the repo you are in, PreCompact and SessionEnd write the session back. Claude Code prompts for your API key at enable time and keeps it in the OS keychain. Details and switches: plugin README.

Prefer to wire it by hand?

bash
claude mcp add --transport http brain https://brain.inite.ai/mcp \  --header "Authorization: Bearer $BRAIN_KEY"

Gemini CLI — one command

bash
export BRAIN_API_KEY="brain_..."gemini extensions install https://github.com/inite-ai/inite-brain-service

MCP server, the six skills, and the agent memory guide loaded as context. The key stays in your environment — the manifest references ${BRAIN_API_KEY} and Gemini expands it at connect time.

Cursor and VS Code — one click

Those two publish an install URL scheme, so the badges at the top of this file do the work; replace the placeholder key in the client's own MCP settings afterwards. Every other client takes the URL https://brain.inite.ai/mcp (or ?tools=chatgpt for ChatGPT, whose connector contract is exactly search + fetch).

Every other harness

bash
curl -fsSL https://brain.inite.ai/install.sh | sh

Installs the skills into every agent it finds on the machine — Claude Code, Codex CLI, Gemini CLI, openclaw, opencode — and takes --target cursor,agents --scope project for the project-local ones. SKILL.md is a cross-agent format, so the same six skills work unchanged everywhere.

For clients that launch a stdio MCP server, use the first-party @inite/brain-mcp connector. This configuration fits clients with a mcpServers map, including Claude Desktop:

json
{  "mcpServers": {    "brain": {      "command": "npx",      "args": ["-y", "@inite/brain-mcp"],      "env": {        "BRAIN_API_KEY": "brain_YOUR_API_KEY",        "BRAIN_COMPANY_ID": "YOUR_COMPANY_ID"      }    }  }}

For the local setup, use company ID co_demo, the key from .env, and add "BRAIN_BASE_URL": "http://localhost:3000" to env (port 3030 for Compose). Node.js and npx must be available to the client.

Clients with native remote MCP support can connect directly over Streamable HTTP:

text
URL: https://brain.inite.ai/mcp          (tenant taken from the credential)     https://brain.inite.ai/mcp/<companyId>   (explicit, must match the key)Authorization: Bearer brain_<api-key>

Both spellings serve the same endpoint. Use the tenant-less one when the client only knows a URL — that is every OAuth-discovered connector, where the tenant arrives in the token's org claim rather than from the person pasting the config. An unauthenticated probe answers at /mcp/health (and /mcp/<companyId>/health), so a setup script can check reachability before any credential exists.

The key's scopes determine available tools; server flags and installed packs can extend the surface. The connector forwards tools and resources, and bridges MCP sampling when the client supports it. See the per-client setup guide.

Agent taskStart with
Find relevant memorysearch_knowledge, graph_retrieve, search_multi_hop
Answer with citationssynthesize
Resume after a gapmemory_diff, get_entity_timeline
Record informationrecord_fact for one claim; ingest_document for longer material
Inspect disagreementdetect_contradiction, get_competing_facts
Remember engineering rationalerecord_decision, why, recall_decisions
Find out what you just connected toworkspace_status

Read the agent memory guide for memory semantics and the skills guide for reusable agent workflows. Synthesis keeps fact references in citations and other evidence references (episodes, fragments, scenes and beliefs) in evidenceCitations; preserve both when presenting an answer.

Build with the SDK

bash
npm install @inite/brain
ts
import { createBrain, brainTools } from '@inite/brain'
const brain = createBrain({ apiKey: process.env.BRAIN_KEY!, userId: 'user_42' })await brain.remember('Maria moved to Berlin in June.')const { answer, citations } = await brain.answer('where does Maria live')

brainTools(brain) returns tool definitions the Vercel AI SDK takes directly, and createBrainStore(brain) is a LangGraph-shaped store over the same memory. One dependency (zod), no framework required: @inite/brain.

Using Anthropic's memory tool (memory_20250818)? Swap the filesystem backend for a tenant-fenced service without touching your agent loop: @inite/brain-memory-tool.

Feed it documents

Enable DOCUMENT_INGEST_ENABLED=1 on the server. Submit normalized text through Source → Indexer → Candidates → Brain:

bash
curl --fail-with-body -X POST "$BRAIN_URL/v1/ingest/document" \  -H "Authorization: Bearer $BRAIN_KEY" \  -H "Content-Type: application/json" \  -d '{    "kind": "markdown",    "title": "Acme maintenance review",    "text": "Customer cust_42 reported late maintenance. The team agreed to review response times next week.",    "occurredAt": "2026-09-01T10:00:00Z",    "userId": "user_42",    "contextRef": { "vertical": "rent" }  }'

Indexers stage candidates before the core resolves and commits facts. Stored content can be re-indexed after installing a new pack; external indexers can join over a pull work API. storeContent: false disables content retention for that document, so later re-indexing cannot reuse its text. Document pipeline · External indexers.

Or let the brain read what already exists: a folder, a bucket, a site, an MCP server — install a source pack (file_memory, web_memory), connect a source in Admin → Connections, sync; every fact carries the file's revision. For what lives on a laptop, a CI runner or a box on the LAN, the @inite/brain-agent walks it there — folders, a repository's committed docs, a local MCP server — and the brain keeps the books. Source plane.

Files and evidence

The evidence plane supports metadata/reference registration through POST /v1/ingest/evidence-asset and multipart blob upload through POST /v1/ingest/evidence-blob. Uploaded assets pass a scan hook and can be dispatched to trusted processors; outputs are derived representations, with fragment locators where supplied by the processor.

Current adapters include local image metadata decoding, PDF text-layer extraction and plain-text extraction. Image metadata is not visual scene understanding; PDF text extraction is not OCR. A modality declared by a pack is a capability request, not proof that a corresponding audio, video or vision processor is installed.

These paths require their evidence gates, storage configuration and applicable pack consent. Raw serving additionally checks scope and PII policy. Evidence contracts · Evidence configuration · Processor adapters.

Build on Brain

  • Extend the domain: author a pack, publish to the registry and install a reviewed version per tenant.
  • Connect an indexer: use the pull protocol and reference client.
  • Extend the agent: declare pack MCP tools, with separate consent for the added tool surface.
  • Inspect the API: OpenAPI 3.1 is generated with pnpm openapi:build from the platform contracts.

Quality and evaluation

Retrieval, answer accuracy and state-transition correctness measure different things. Published scores belong to a particular dataset, reader model, retrieval profile, token budget and code revision; they are not a general accuracy guarantee for the running service.

EvaluationWhat it probes
LoCoMoRepresentation quality when the source conversation fits in context.
LongMemEvalRecall and reasoning over longer conversation histories.
BEAMHow quality changes as history scales.
Memory fitness and state transitionsMechanical, judge-free checks of memory behavior and lifecycle changes.
Domain-pack and code-memory batteriesDomain extraction, entity identity, state and engineering-memory scenarios.

Conversational-memory results use a strict binary judge, our own full-context baseline, paired statistics and a held-out split. Read the evaluation protocol and methodology alongside any reported number; scores published under different protocols are not directly comparable.

CI: PRs run lint, formatting, type checking, builds, unit tests with coverage, socket and integration tests, plus frontend checks and supply-chain checks. The real-LLM quality eval runs nightly or by manual dispatch, not on every PR. The workflow is the source of truth: .github/workflows/ci.yml.

Battery guides: memory fitness · state transitions · domain packs · code memory.

Stack

Node.js 24 · NestJS · TypeScript · SurrealDB 3.x · configurable embedding and LLM providers · local BGE-M3 option · configurable reranking · SurrealDB-backed jobs and leases · worker threads · OpenTelemetry. The web app and docs use Next.js, React and Tailwind CSS.

Documentation

Documentation hub · Web docs, EN/RU

Contributing

Contribute with an AI agent

[Open in GitHub Codespaces]

You don't need to be an engineer. Open the repo (Codespaces above gives a ready environment with SurrealDB running), start your coding agent and describe the idea in plain words:

  • Claude Code: /contribute — it restates the idea, writes a short spec, builds it with tests, runs the gates and opens a PR. /spec-idea only files the idea as an issue.
  • Any other agent (Cursor, Codex, Copilot, Gemini CLI, Windsurf…): "Read AGENTS.md and help me add …".

AGENTS.md is the source of truth for agents: commands, zones (what is safe to change and what needs a maintainer first) and the idea → PR loop. Prefer to just propose? Use the Product idea form.

The workflow

See CONTRIBUTING.md for the workflow and CODE_OF_CONDUCT.md for community guidelines.

bash
pnpm lint:cipnpm format:checkpnpm typecheckpnpm buildpnpm testpnpm test:socket# Integration suites require Docker:pnpm test:e2epnpm test:e2e:jobs

Choose additional evals for the behavior you change; real-model runs require provider credentials. Database changes belong in new numbered migrations in src/db/migrations/. For vulnerability reports, follow SECURITY.md.

Roadmap

Follow issues and releases for current work. Design notes and earlier experiments remain in docs/roadmap; read their dates and status before treating an item as shipped or pending.

License

AGPL-3.0-or-later.

Source: README.md at commit ff8dfe9

Tools

30

about_brain

About this memory server

What this server is and what it can do, before you connect. Reads nothing and stores nothing.

Takes no parameters.

how_to_connect

How to connect to this server

The two ways to authenticate, and what each is for. Reads nothing and stores nothing.

Parametersclient

search_knowledge

Search company knowledge

Semantic search over the company knowledge graph: the facts the query is about, the links between their entities and what was left out. Apply asOf for historical "what was true on X" queries. Embedding model on this tenant: set per workspace.

ParametersasOflimitqueryrequireddetailuserIdpredicatesminConfidence

search_multi_hop

Multi-hop search across the knowledge graph

Planner-LLM decomposes the query into ≤ maxHops anchored sub-queries; later hops are anchored to the running entity set. Built for questions that combine evidence across turns / sessions, or that require reasoning over multiple entities ("tenants who complained in April AND upgraded after"). Set synthesize=true to get a grounded answer with citations alongside the per-hop trace. Returns the hops, the answer when asked, and the evidence as focus lines. Embedding model on this tenant: set per workspace.

ParametersasOflimitqueryrequireddetailuserIdmaxHopspredicatessynthesizesynthesisGuardrails

graph_retrieve

Graph-first retrieval around named entities

Resolves the named entities by canonical name, walks their 1-hop neighbourhood over knowledge_edge, and returns facts across seeds ∪ neighbours, optionally filtered by predicate hints. Works from entities named up front and returns what the graph holds around them ("who runs engineering at Acme" — the answer lives on a neighbour, not on Acme itself). Seeds score 1.0, neighbours 0.7; soft-fails to an empty result.

ParametersasOfqueryuserIdentityNamesrequiredpredicateHints

synthesize

Synthesize a grounded answer from retrieved facts

Runs hybrid search then feeds the retrieved facts to a generator LLM that produces a citation-bearing answer (each claim ends with [factId]); a verifier LLM then judges whether every claim is supported. Three guardrail modes: strict (default) returns null on partial / unsupported / verifier outage (fail-closed); lenient returns the answer alongside the verifier verdict; off skips the verifier. Returns a direct natural-language answer rather than raw search results. Embedding model on this tenant: set per workspace.

ParametersasOflimitqueryrequireddetailuserIdpredicatesminConfidencesynthesisGuardrails

memory_diff

Diff brain memory between two points in time

Returns everything brain learned, unlearned, or replaced between two ISO 8601 cursors [from, to). createdFacts = new active facts; retractedFacts = facts marked retracted in-window with no successor; changedFacts = facts that were superseded by another (carries before+after); newEntities = entities created in-window; forgottenEntities = GDPR-erased tombstones; lapsedExpectations = temporary states (ill, away) whose expected end passed in-window with nothing confirming or ending them — worth asking about. Driving use case: "what changed since the last conversation?" Scope with entityIds and/or predicates to narrow the diff to a feature surface. Window is half-open; consecutive diffs over adjacent windows never double-count.

ParameterstorequiredfromrequireddetailuserIdentityIdspredicates

get_entity_profile

Get entity profile

One entity: canonical name, type and what brain holds about it now; detail "full" adds externalRefs, the ids of its records in the originating vertical.

ParametersasOfdetailuserIdentityIdrequired

get_entity_timeline

Get entity timeline

Chronological audit of all facts brain has learned about this entity, including retracted ones. Useful for "what did we know when" investigations.

ParameterssinceuntildetailuserIdentityIdrequired

summarize_entity

One-line briefing for an entity

Returns a short one-line briefing about the entity — name, type, the most-confident active facts, external refs — suitable for dropping into an LLM context window. Caches in-process (per companyId / entityId / asOf / styleHint) so a hot entity touched across many turns doesn't reload the profile. styleHint='neutral' | 'sales' | 'support' are template-rendered (no LLM call). styleHint='client_llm' opts into MCP SAMPLING: brain asks the connected client (Claude Desktop / agent runtime) to write the one-liner with its own model — zero brain-side OpenAI cost, perfect for self-hosters who don't want brain holding an LLM key. Falls back to neutral template + sampledBy='local_template' when the client doesn't advertise sampling capability. A briefing in place of the full profile, timeline and competing facts.

ParametersasOfuserIdentityIdrequiredstyleHint

get_competing_facts

List competing facts for an entity

Returns facts in COMPETING status — those the conflict resolver couldn't auto-supersede because two same-predicate bitemporal facts overlap in valid-time and are too cosine-close within margin. Grouped by (entityId, predicate); 2-fact groups are pairs the resolver left for adjudication, 3+-fact groups are multi-way disagreements escalated for human review. Answers "is this entity already conflicted on this predicate?" and can drive an in-product reviewer queue. asOf filters to disagreements that were live at that moment.

ParametersasOfuserIdentityIdrequiredpredicate

detect_contradiction

Predict the conflict-resolver outcome for a candidate fact

Dry-run preflight against fn::resolve_fact. Answers "if I were to record this fact right now, what would the resolver decide?" without writing to the database. wouldOutcome ∈ {INSERTED, SUPERSEDED, COMPETING, REJECTED}; reasoning explains which rule fired (semantics class, score gap vs margin, cosine threshold, etc); opposingFacts lists the same-predicate priors the resolver would have weighed against. Useful where the cost of a contested write is high (e.g. agent loops that pay an ingest credit). Fidelity: this preflight uses the SEED source-trust table and authority 0 — the live resolver scores opponents with the learned domain-scoped rates (migration 0045) and declared source authority (migration 0046), so predictions can differ for sources with conflict history or a registered authLevel.

ParametersobjectrequireduserIdentityRefrequiredpredicaterequiredvalidFromrequiredconfidencevalidUntilsourceVerticalrequired

get_fact

Get one fact by id

Read a single fact as stored — predicate (aspect), object (statement), confidence, validity window, source attribution (vertical / recorder / conversationId), and lifecycle state. Retracted facts still resolve (retracted: true) — "why did I stop remembering this" is part of the trust story; only visibility fences turn into not-found. groundingStatus (grounded | ungrounded) appears on facts stamped by the claim-grounding plane (EVIDENCE_GROUNDING_STAMP); legacy rows carry no key. Same shape as GET /v1/facts/:id. Takes a factId as returned by searches and writes and returns the full trust record behind it.

ParametersfactIdrequireduserId

get_fact_provenance

Show why a fact is remembered (grounding provenance)

Return the grounding provenance behind one fact: the verbatim conversation turns it was derived from (episodes, chronological, with char-span quotes when the deriver stamped them). When the server runs with the recursive-closure flag the response additionally carries derivedFacts + closure (the transitive derivedFrom support graph); a plain deployment returns episodes only — the response is a passthrough of GET /v1/facts/:id/provenance, no field filtering. Traversal depth is a server-side policy (flag + caps), not a caller knob. Lets a surprising fact be audited before it is trusted or retracted.

ParametersfactIdrequireduserId

match_procedure

Match procedural memory against a context query

Cosine-matches procedural memory (curated 'how to' patterns the operator recorded) against a free-text context query. Returns top-K procedures sorted by similarity DESC then priority ASC. Surfaces the behaviour rules that apply to a context — e.g. "user asks about pricing" → "mention they're on platinum tier; they get 20% off". Procedural memory is the third tier alongside facts (semantic) and episodes (timeline).

ParameterslimitqueryrequiredminSimilarity

list_procedures

List recorded procedural memory entries

Paginated listing of procedural memory for admin/review UIs. Sorted by priority ASC, createdAt DESC. Set includeRetired=true to see soft-deleted rows.

ParameterslimitincludeRetired

search_communities

Search topic communities (coarse retrieval scope)

Cosine-matches the query against topic-community summaries — the coarse retrieval scope. A community is a cluster of related entities (label propagation over the entity graph) with one rolled-up summary. Suited to broad questions ("what do we know about X domain"): it returns an overview of a domain rather than individual facts. Communities are (re)built off-hours by the dreams loop; an empty result means clustering has not run or the graph is too sparse.

ParameterslimitqueryrequiredminSimilarity

list_communities

List topic communities

Paginated listing of topic communities, largest first. Each row carries a label, a rolled-up summary, and the member count. Gives the knowledge map at a glance.

Parameterslimit

find_entity_communities

Find the communities an entity belongs to

Returns the topic communities a given entity is a member of. Places an entity in its broader context — which clusters / themes it participates in — and leads from one entity to the wider neighbourhood the cluster summarises.

ParametersentityIdrequired

why

Recall the recorded "why" behind a code symbol

Return the design decisions, rationale, invariants and gotchas recorded against a code anchor — the non-derivable engineering "why" a parser cannot recover from source. The anchor is a SCIP-style symbol string ("pkg/namespace/symbol") or a file path ("repo/path/file.ts"). Pass asOf to recall what was known at a past instant (bitemporal). Returns found:0 with empty memory when nothing is recorded.

ParametersasOfsymbolrequireduserId

recall_decisions

Semantically recall code-memory across the codebase

Find recorded design decisions / rationale / invariants / gotchas by NL topic ("why do we resolve facts through one gateway?"), across ALL code anchors — a semantic search over code-memory, rather than one known anchor. Returns matches with their code anchor + kind, ranked by relevance.

ParameterslimitqueryrequireduserId

get_source_reputation

Inspect the reputation of a fact source

Return everything brain knows ABOUT a source (not its facts): the operator-declared identity (type, authLevel — authority in conflict resolution), the learned per-domain agreement rates (domain = predicate; null domain = the global blended rate; rates need >=8 samples before the resolver trusts them over the neutral 0.5), and the reputation-over-time history. sourceKey is `vertical:recorder` (recorder falls back to `_`) — the same key facts carry in trustSnapshot.sourceKey. Shows how much weight a fact whose trustSnapshot looks surprising deserves.

ParameterssourceKeyrequired

workspace_status

What this connection is attached to, and what is left to set up

The tenant this credential writes to (companyId, its display name, whether it is a personal workspace), what is already in its memory (entities, active facts, facts recorded in the last 7 days), how many Domain Packs are installed, for a user-bound connection who the user is in this memory (`user.name` — the name the memory has learned from them, null until it has), and `nextSteps` — the setup actions that would actually change something, derived from that state rather than a stored checklist (including asking the user how to address them, once, and recording it). Answers "which workspace am I writing to?" and explains why memory answers may look emptier than expected.

Takes no parameters.

record_fact

Record a fact about an entity

Records one fact about an entity directly; the memory settles it against the facts it holds (INSERTED / SUPERSEDED / COMPETING). Most facts arrive through ingestion.

ParametersobjectrequireduserIdevidenceentityRefrequiredpredicaterequiredvalidFromrequiredconfidencevalidUntilexpectedUntilconversationIdsourceVerticalrequired

retract_fact

Retract a fact

Mark a fact as no longer believed. Cascades to facts derived from this one. Does not delete; the row remains for audit.

ParametersfactIdrequiredreasonrequiredretractedBy

record_procedure

Record a procedural memory (behaviour rule)

Record a 'how to' pattern that is surfaced when a similar context appears later. trigger = the context phrase the rule should match against (e.g. "user asks about pricing"); action = the behaviour to apply (e.g. "mention they're on platinum tier; they get 20% off"). priority orders ties when multiple procedures match the same context (lower is higher priority; default 100). decayHalfLifeDays is a forward hook for v0.2 relevance decay; v1 ignores it at read time.

ParametersactionrequiredtriggerrequiredprioritysourceKinddecayHalfLifeDays

retire_procedure

Soft-retire a procedural memory entry

Mark a procedural memory row as retired (sets retiredAt). A retired procedure is no longer matched or listed by default. For a rule that no longer applies — distinct from a hard delete because the row stays for audit.

ParametersprocedureIdrequired

record_decision

Record a code-memory decision / rationale / invariant / gotcha

Capture the non-derivable engineering "why" about a code location: a design decision, its rationale, an invariant that must hold, or a gotcha. Anchored to a SCIP-style symbol or file path (NOT line numbers — survives edits). Stored as a bitemporal typed fact: re-recording a `decided` / `invariant` for the same anchor SUPERSEDES the prior one (decision evolution over time), while `because` / `gotcha` accumulate. Attach commit / location for provenance.

ParameterskindrequiredtextrequiredcommitsymbolrequiredlocationvalidFromconfidence

Version history

5
  1. v2.7.0LatestNov 3, 2026
  2. v2.6.0Oct 29, 2026
  3. v2.4.0Oct 16, 2026
  4. v2.3.0Sep 24, 2026
  5. v2.2.0Sep 16, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts

Other Brain integrations