Zombie Brains Docs

Persistent memory for AI — context that won't stay dead.

Overview

Zombie Brains gives AI persistent memory across sessions. Connect via MCP (Claude, ChatGPT) or REST API (scripts, bots, SaaS integrations). Memories are stored, embedded, linked, and retrieved using a neuroscience-inspired cognitive architecture — no LLM on our side.

Base URL: https://mcp.zombie.codes (also: https://api.zombie.codes)

Authentication

Three auth methods, each scoped to different capabilities:

API Key (memory operations)

curl https://mcp.zombie.codes/v1/memory/search?q=architecture \
  -H "Authorization: Bearer cm_a1b2c3d4e5f6g7h8i9j0..."

Full access to memory read/write for the associated brain. Get keys from the brain management interface.

Webhook Token (ingest only)

curl -X POST https://mcp.zombie.codes/v1/ingest \
  -H "Authorization: Bearer zwh_a587259ed0214497b8b200da..." \
  -H "Content-Type: application/json" \
  -d '{"content": "Meeting notes..."}'

Connector-scoped. Can only access /v1/ingest — returns 403 on all other endpoints. Generated when creating a connector.

OAuth Token (brain management)

curl https://mcp.zombie.codes/v1/brains \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIs..."

Required for brain management endpoints (create/delete brains, invite members, analytics). Obtained via the Auth0 OAuth flow — the same token the MCP connection uses.

Quick Start

Store your first memory in 30 seconds:

# 1. Store a memory
curl -X POST https://mcp.zombie.codes/v1/memory/add \
  -H "Authorization: Bearer cm_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "We chose Postgres over Neo4j because graph sizes per brain are small and recursive CTEs handle traversal",
    "type": "decision",
    "salience": "elevated"
  }'

# 2. Search for it
curl "https://mcp.zombie.codes/v1/memory/search?q=database+choice" \
  -H "Authorization: Bearer cm_YOUR_API_KEY"

Store a Memory

POST

POST /v1/memory/add
Content-Type: application/json
Authorization: Bearer cm_YOUR_API_KEY

{
  "content": "We decided to use Thompson Sampling for play card selection because it balances exploration vs exploitation",
  "type": "decision",
  "salience": "elevated",
  "target_brain_id": "11c6dc92-4d25-...",
  "triggers": [
    {
      "condition": "working on play card selection or A/B testing",
      "reason": "Thompson Sampling is the chosen algorithm — don't switch to UCB without re-evaluating"
    }
  ]
}

Response:

{
  "id": "a1b2c3d4-...",
  "type": "decision",
  "salience": "elevated",
  "topics": ["Thompson", "Sampling", "play", "card", "selection"],
  "auto_linked_to": ["f5e6d7c8-..."],
  "message": "Stored elevated decision. This connects to 1 related memories.",
  "routing_check": {
    "stored_in": { "brain": "Outbound Bot Brain", "confidence": 0.48 },
    "alternatives": [
      { "brain": "AI Org Brain", "confidence": 0.42 },
      { "brain": "Engineering Brain", "confidence": 0.31 }
    ]
  }
}

Field	Type	Required	Description
`content`	string	yes	The memory content in natural language
`type`	string	no	`decision` / `constraint` / `fact` / `preference` / `observation` (auto-inferred)
`salience`	string	no	`normal` / `elevated` / `critical` (auto-inferred)
`target_brain_id`	uuid	no	Route to a specific brain. Omit for personal brain.
`triggers`	array	no	Conditions that should proactively surface this memory
`session_id`	string	no	Session ID from load_brain (enables reconsolidation)

Search Memories

GET

GET /v1/memory/search?q=database+architecture&limit=5&offset=0&source=auto_ingested
Authorization: Bearer cm_YOUR_API_KEY

Response:

{
  "memories": [
    {
      "id": "a1b2c3d4-...",
      "content": "We chose Postgres over Neo4j because...",
      "type": "decision",
      "salience": "elevated",
      "relevance_score": 0.05,
      "semantic_similarity": 0.72,
      "stored_by": "Robert Sellman",
      "brain_name": "Engineering Brain",
      "topics": ["Postgres", "Neo4j", "database"],
      "triggers": [...]
    }
  ],
  "graph_connections": [...],
  "pagination": { "offset": 0, "limit": 5, "total_available": 12, "has_more": true }
}

Param	Type	Default	Description
`q`	string	—	Search query (required)
`limit`	int	10	Results per page (max 20)
`offset`	int	0	Skip N results for pagination
`source`	string	—	`auto_ingested`, `human`, or source name (`gmail`, `make:gmail`)

Bulk Import

POST

POST /v1/memory/add/bulk
Content-Type: application/json
Authorization: Bearer cm_YOUR_API_KEY

{
  "target_brain_id": "11c6dc92-4d25-...",
  "memories": [
    { "content": "Email templates use Handlebars syntax with {{variable}} placeholders", "type": "fact" },
    { "content": "Never fabricate claims about a prospect's organization", "type": "constraint", "salience": "critical" },
    { "content": "CauseIQ revenue field maps to annual_revenue in our scoring model", "type": "fact" }
  ]
}

Response:

{ "stored": 3, "memories": [{ "id": "...", "type": "fact" }, ...] }

Limits: 100 memories per request. Each memory gets embedded individually (~0.5s each). For 70k items, batch into 700 requests with 1-2s delay between batches.

Archive a Memory

POST

POST /v1/memory/archive/a1b2c3d4-e5f6-7890-abcd-ef1234567890
Content-Type: application/json
Authorization: Bearer cm_YOUR_API_KEY

{
  "reason": "Decision reversed — switching to UCB algorithm after testing",
  "superseded_by": "f5e6d7c8-..."
}

Link Memories

POST

POST /v1/memory/link
Content-Type: application/json
Authorization: Bearer cm_YOUR_API_KEY

{
  "source_memory_id": "a1b2c3d4-...",
  "target_memory_id": "f5e6d7c8-...",
  "relationship_type": "depends_on"
}

Relationship types: depends_on, conflicts_with, supersedes, relates_to, decided_because_of, refines

Note: Most links are created automatically — relates_to on store, supersedes on archive. Only use this for depends_on and conflicts_with which require reasoning.

Load Brain

POST

POST /v1/brain/load
Authorization: Bearer cm_YOUR_API_KEY

Response includes: brain info, session_id, recent sessions, critical memories, active context, triggered memories, stats, constellations (topic clusters), accessible_brains (with IDs, descriptions, routing_rules), inherited policies from parent brains, and documentation URLs.

Brain Overview

GET

# All brains — big picture
GET /v1/brain/overview?days=7

# Single brain — island mode
GET /v1/brain/overview?days=7&brain_id=a8cb5930-...

# Brain + all children — family mode
GET /v1/brain/overview?days=7&brain_id=a8cb5930-...&include_children=true

# Multiple specific brains
GET /v1/brain/overview?days=7&brain_id=a8cb5930-...,dbaac3d8-...

Returns: period, memories_created, decisions, constraints, constellations, ingestion stats, priority ingredients, conflicts.

Log Session

POST

POST /v1/session/log/e3682a47-f644-...
Content-Type: application/json
Authorization: Bearer cm_YOUR_API_KEY

{
  "summary": "Built the auto-ingestion pipeline. Deployed /v1/ingest with two-signal routing. Tested multi-brain auto-routing (3/3 correct). Still need to wire Make.com Gmail trigger."
}

List Brains

GET

# API key — discovery endpoint (returns brain hierarchy)
GET /v1/brains
Authorization: Bearer cm_YOUR_API_KEY

# OAuth — full details with member counts
GET /v1/brains
Authorization: Bearer eyJhbGciOiJS...

Response:

{
  "brains": [
    {
      "id": "16e36a79-...",
      "name": "Company Brain",
      "description": "Company-wide strategy and cross-cutting decisions",
      "routing_rules": "Product-specific → product brains. Engineering → Engineering Brain.",
      "parent_brain_id": null,
      "access_level": "admin",
      "memory_count": 142,
      "member_count": 5
    },
    {
      "id": "b8f0912d-...",
      "name": "AI Org Brain",
      "description": "Shared AI infrastructure and cross-product strategy",
      "parent_brain_id": "16e36a79-..."
    }
  ],
  "count": 8
}

Create Brain

POST

(OAuth only, Pro tier+)

POST /v1/brains
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJS...

{
  "name": "Deal Support",
  "description": "Call scripts, objection handling, competitive intel, deal qualification frameworks",
  "parent_brain_id": "b8f0912d-..."
}

Response:

{
  "brain_id": "890a1c97-...",
  "name": "Deal Support Brain",
  "your_role": "admin",
  "message": "Brain created. Invite members with POST /v1/brains/890a1c97-.../members"
}

Always provide a description. The AI uses it for routing — without a description, memories can't be routed to this brain by confidence scoring.

Update Brain

PATCH

(OAuth only, admin)

PATCH /v1/brains/890a1c97-...
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJS...

{
  "description": "Updated description...",
  "routing_rules": "Call scripts stay here. Competitive intel → Market Intel Brain."
}

Members

Invite a Member

POST

POST /v1/brains/890a1c97-.../members
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJS...

{ "email": "sarah@company.com", "access_level": "editor" }

Response (existing user):

{ "status": "granted", "email": "sarah@company.com", "access_level": "editor" }

Response (new user):

{ "status": "invited", "email": "sarah@company.com", "message": "Will auto-join on first login" }

List Members

GET

GET /v1/brains/890a1c97-.../members
Authorization: Bearer eyJhbGciOiJS...

Remove Member

DELETE

DELETE /v1/brains/890a1c97-.../members/user-uuid-here
Authorization: Bearer eyJhbGciOiJS...

Soft delete. Memories stay in the brain with attribution. Knowledge doesn't walk out the door.

Change Access Level

PATCH

PATCH /v1/brains/890a1c97-.../members/user-uuid-here
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJS...

{ "access_level": "admin" }

Access levels: viewer (read-only), editor (read + write), admin (manage members + configure brain).

Analytics

Brain Analytics (admin)

GET

GET /v1/brains/890a1c97-.../analytics
Authorization: Bearer eyJhbGciOiJS...

Returns: total memories, type breakdown (decisions/facts/constraints), total recalls, high-impact memories, top contributors, daily activity.

Org Analytics (Business tier, admin)

GET

GET /v1/brains/16e36a79-.../analytics/org
Authorization: Bearer eyJhbGciOiJS...

Returns: child brains, total memories across hierarchy, unique contributors, per-brain breakdown, cross-brain conflicts.

SCIM Provisioning

POST

(OAuth only, admin)

POST /v1/provision
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJS...

{
  "users": [
    { "email": "sarah@company.com", "name": "Sarah", "brain_id": "890a1c97-...", "access_level": "editor" },
    { "email": "mike@company.com", "name": "Mike", "brain_id": "890a1c97-...", "access_level": "viewer" }
  ]
}

Up to 100 users per request. Creates user + personal brain if new. Grants access to target brain.

Team Brains: End-to-End Workflow

Complete example: create a brain hierarchy, invite members, store with routing, search across brains.

Step 1: Create the hierarchy

# Create parent brain (OAuth required)
curl -X POST https://mcp.zombie.codes/v1/brains \
  -H "Authorization: Bearer eyJhbGciOiJS..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Sales Division",
    "description": "Cross-team sales strategy, pipeline metrics, territory planning"
  }'
# Response: { "brain_id": "aaa-111-...", "name": "Sales Division Brain" }

# Create child brains under it
curl -X POST https://mcp.zombie.codes/v1/brains \
  -H "Authorization: Bearer eyJhbGciOiJS..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Outbound",
    "description": "Cold outbound email pipeline, targeting, templates, A/B testing",
    "parent_brain_id": "aaa-111-..."
  }'
# Response: { "brain_id": "bbb-222-...", "name": "Outbound Brain" }

curl -X POST https://mcp.zombie.codes/v1/brains \
  -H "Authorization: Bearer eyJhbGciOiJS..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Deal Support",
    "description": "Call scripts, objection handling, competitive intel, deal qualification",
    "parent_brain_id": "aaa-111-..."
  }'
# Response: { "brain_id": "ccc-333-...", "name": "Deal Support Brain" }

Step 2: Add routing rules

curl -X PATCH https://mcp.zombie.codes/v1/brains/aaa-111-... \
  -H "Authorization: Bearer eyJhbGciOiJS..." \
  -H "Content-Type: application/json" \
  -d '{
    "routing_rules": "Email pipeline and targeting decisions → Outbound Brain. Call scripts and objection handling → Deal Support Brain. Only cross-team sales strategy stays here."
  }'

Step 3: Invite team members

# Invite to parent — they inherit access to children if cascades=true
curl -X POST https://mcp.zombie.codes/v1/brains/aaa-111-.../members \
  -H "Authorization: Bearer eyJhbGciOiJS..." \
  -H "Content-Type: application/json" \
  -d '{ "email": "sarah@company.com", "access_level": "editor" }'

# Invite to specific child only
curl -X POST https://mcp.zombie.codes/v1/brains/bbb-222-.../members \
  -H "Authorization: Bearer eyJhbGciOiJS..." \
  -H "Content-Type: application/json" \
  -d '{ "email": "mike@company.com", "access_level": "viewer" }'

Step 4: Store memories with routing

# Store to a specific brain using target_brain_id (API key)
curl -X POST https://mcp.zombie.codes/v1/memory/add \
  -H "Authorization: Bearer cm_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "We chose Thompson Sampling over UCB for play card selection because it naturally balances exploration vs exploitation without manual tuning",
    "type": "decision",
    "salience": "elevated",
    "target_brain_id": "bbb-222-..."
  }'

# The routing_check in the response confirms it landed correctly:
# { "routing_check": { "stored_in": { "brain": "Outbound Brain", "confidence": 0.48 },
#   "alternatives": [{ "brain": "Sales Division Brain", "confidence": 0.31 }] } }

Step 5: Search across all brains

# Search finds memories from ALL accessible brains automatically
curl "https://mcp.zombie.codes/v1/memory/search?q=play+card+selection" \
  -H "Authorization: Bearer cm_YOUR_API_KEY"

# Results include brain_name for provenance:
# { "memories": [
#   { "content": "Thompson Sampling for play cards...", "brain_name": "Outbound Brain" },
#   { "content": "Sales strategy requires data-driven...", "brain_name": "Sales Division Brain" }
# ] }

Step 6: Get the big picture

# Family mode — Sales Division + all children as one view
curl "https://mcp.zombie.codes/v1/brain/overview?brain_id=aaa-111-...&include_children=true&days=7" \
  -H "Authorization: Bearer cm_YOUR_API_KEY"

# Returns aggregated: memories_created, decisions, constraints, constellations
# across Sales Division + Outbound + Deal Support as one unified view

Auto-Ingest

POST

POST /v1/ingest
Content-Type: application/json
Authorization: Bearer zwh_YOUR_WEBHOOK_TOKEN

{
  "content": "Fathom transcript: Q3 planning meeting. Decided to prioritize mobile over desktop...",
  "source_channel": "fathom",
  "source_user": "ceo@company.com",
  "source_id": "meeting_q3_planning"
}

Response:

{
  "id": "d590a361-...",
  "brain_id": "b8f0912d-...",
  "brain_name": "AI Org Brain",
  "source": "webhook",
  "source_channel": "fathom",
  "source_user": "ceo@company.com",
  "source_label": "webhook:fathom:ceo@company.com",
  "auto_routed": true,
  "routing": { "method": "confidence", "confidence": 0.45 },
  "dedup": { "action": "created" }
}

Field	Type	Required	Description
`content`	string	yes	The content to ingest
`source_channel`	string	no	Sub-source: `gmail`, `fathom`, `#engineering`
`source_user`	string	no	Author identity: `user@company.com`
`source_id`	string	no	Dedup key (thread_id). Same source_id = supersede previous
`target_brain_id`	uuid	no	Skip auto-routing — place directly in this brain

Connectors

Connectors control which brains an ingestion source can write to, what attribution model to use, and generate the webhook token for auth.

Create a Connector (via MCP)

// In a conversation with Zombie Brains connected:
manage(action: "create_connector",
       name: "Company Gmail",
       source: "gmail",
       brain_id: "16e36a79-...",
       connector_type: "personal",
       connector_config: '{"allowed_brain_ids": ["16e36a79-...", "b8f0912d-...", "11c6dc92-..."], "default_brain_id": "16e36a79-..."}'
)

// Response:
{
  "connector_id": "50c7c464-...",
  "name": "Company Gmail",
  "webhook_token": "zwh_b45379ea20214497b8b200da...",
  "allowed_brain_ids": ["16e36a79-...", "b8f0912d-...", "11c6dc92-..."],
  "auth_header": "Authorization: Bearer zwh_b45379ea20214497b8b200da..."
}

Connector Types

Type	stored_by	Use case	Retrieval behavior
`personal`	Connector owner	Gmail, Outlook — one person's content	User-biased retrieval boosts for owner
`shared`	null	Fathom, Slack — team content	Equal relevance for everyone

Channel Mappings (multi-channel sources)

// For Slack/Discord — map channels to specific brains
manage(action: "configure_connector",
       connector_id: "50c7c464-...",
       connector_config: '{"channel_mappings": {"#engineering": "a08510f2-...", "#sales": "890a1c97-...", "#random": null}}'
)

// #engineering messages → Engineering Brain
// #sales messages → Deal Support Brain  
// #random → excluded (null = drop)

List and Manage Connectors

// See all your connectors
manage(action: "list_connectors")

// Update a connector's config
manage(action: "configure_connector",
       connector_id: "50c7c464-...",
       connector_config: '{"allowed_brain_ids": ["16e36a79-...", "NEW_BRAIN_ID"]}'
)

Dedup & Source Hierarchy

Sources use a three-level hierarchy: platform:channel:identity

make:gmail:user@company.com      — Make.com pulling from Gmail
zapier:fathom:user@company.com   — Zapier pulling from Fathom
webhook:crm:deal_updates         — Custom webhook from CRM
slack:#engineering:@sarah         — Slack message from Sarah

Dedup: Same source_id in the same brain = supersede. Email threads: one memory per thread_id, updated on each new reply. The source filter in search supports hierarchy: source=make:gmail matches platform + channel.

Make.com

Create a reusable Make Tool, then wire any trigger to it. Here is the complete, copy-paste-ready tool creation call:

Complete Make Tool Configuration

// Use Make:tools_create with these exact values
{
  "name": "Zombie Brains: Ingest Memory",
  "description": "Sends content to Zombie Brains for auto-routing.",
  "teamId": YOUR_TEAM_ID,
  "inputs": [
    { "name": "content",        "type": "text", "required": true,  "description": "The content to ingest" },
    { "name": "source_channel", "type": "text", "required": false, "description": "Sub-source: gmail, fathom, etc." },
    { "name": "source_user",    "type": "text", "required": false, "description": "Author identity" },
    { "name": "source_id",      "type": "text", "required": false, "description": "Dedup key (thread_id)" }
  ],
  "module": {
    "module": "http:ActionSendData",
    "version": 3,
    "parameters": {
      "handleErrors": true
    },
    "mapper": {
      "url": "https://mcp.zombie.codes/v1/ingest",
      "method": "post",
      "bodyType": "raw",
      "contentType": "application/json",
      "data": "{\\"content\\":\\"{{var.input.content}}\\",\\"source_channel\\":\\"{{var.input.source_channel}}\\",\\"source_user\\":\\"{{var.input.source_user}}\\",\\"source_id\\":\\"{{var.input.source_id}}\\"}",
      "headers": [
        { "name": "Authorization", "value": "Bearer zwh_YOUR_WEBHOOK_TOKEN" },
        { "name": "Content-Type",  "value": "application/json" }
      ],
      "parseResponse": true,
      "serializeUrl": false,
      "followRedirect": true,
      "followAllRedirects": false,
      "shareCookies": false,
      "rejectUnauthorized": true,
      "useQuerystring": false,
      "gzip": true,
      "useMtls": false,
      "timeout": 30,
      "qs": []
    },
    "metadata": { "designer": { "x": 0, "y": 0 } }
  }
}

Why these exact fields matter:

Module is http:ActionSendData v3 — NOT http:MakeRequest v4 (different module entirely)
Body field is data — NOT rawBodyContent (that’s MakeRequest v4)
followAllRedirects is mandatory when followRedirect is true — omitting it causes BundleValidationError
handleErrors: true goes in parameters (static config), NOT in mapper (dynamic config)
Every mapper field shown above is required — omitting any causes validation failure

Wiring a Gmail Trigger

Create a Make.com scenario: Gmail “Watch Emails” trigger → your Zombie Brains tool:

// Field mapping in Make.com scenario
content        → {{1.textPlain}}         // email body text
source_channel → "gmail"                 // hardcoded string
source_user    → {{1.from.address}}      // sender email
source_id      → {{1.threadId}}          // enables dedup on replies

Validate Before Creating

// Always validate first to catch errors
Make:validate_module_configuration({
  "appName": "http",
  "appVersion": 3,
  "moduleName": "ActionSendData",
  "organizationId": YOUR_ORG_ID,
  "teamId": YOUR_TEAM_ID,
  "parameters": { "handleErrors": true },
  "mapper": { /* same mapper object as above */ }
})

// Success: { "valid": true, "errors": [], "warnings": [] }
// Failure: { "valid": false, "errors": [{ "path": "followAllRedirects", "message": "Field is mandatory." }] }

Zapier

Everything is configured via the Zapier web dashboard — no code needed.

Path 1: MCP Tool (AI can call it from chat)

// Setup at mcp.zapier.com:
1. Click + Add tool
2. Search "Webhooks by Zapier" → select POST
3. Configure:

   URL:          https://mcp.zombie.codes/v1/ingest
   Payload Type: JSON

   Headers:
     Authorization    Bearer zwh_YOUR_WEBHOOK_TOKEN
     Content-Type     application/json

   Data fields:
     content          [Set to "Have AI fill in"]
     source_channel   [Set to "Have AI fill in"]
     source_user      [Set to "Have AI fill in"]
     source_id        [Set to "Have AI fill in"]

4. Save → tool appears in Claude/ChatGPT

Path 2: Traditional Zap (runs automatically)

// Create a Zap at zapier.com:
1. Trigger: Gmail "New Email" (or Slack, Fathom, etc.)
2. Action: Webhooks by Zapier → POST

   URL:          https://mcp.zombie.codes/v1/ingest
   Payload Type: JSON

   Headers:
     Authorization    Bearer zwh_YOUR_WEBHOOK_TOKEN

   Data:
     content          {{body_plain}}           // from Gmail trigger
     source_channel   gmail                    // hardcoded
     source_user      {{from_email}}           // from Gmail trigger
     source_id        {{thread_id}}            // from Gmail trigger

3. Turn on → new emails auto-ingest into the best brain

Brain Hierarchy

Core principle: search crosses brain boundaries. A bot connected to a child brain automatically inherits knowledge from all parent brains. Shared knowledge goes UP (parents), specific knowledge goes DOWN (children).

🏢 Company Brain (universal knowledge — every bot finds this)
├── 🤖 AI Org Brain (shared AI patterns — all AI bots find this)
│   ├── 📧 Outbound Bot Brain (email pipeline — only outbound bot)
│   ├── 💬 Assistant Brain (conversational AI — only assistant bot)
│   └── 🔍 Deal Support Brain (call scripts — only deal support bot)
└── ⚙️ Engineering Brain (shared infra — all engineering bots)
    ├── 📺 Product A Brain
    └── 📱 Product B Brain

Create brains for ownership boundaries, not topics. A brain = a team, product, or organizational unit with its own decision-making authority.

KB Migration

Migrating a central knowledge base into a brain hierarchy:

Discover brains: GET /v1/brains to see IDs and descriptions
Map categories: Your source system tags each item with the target brain ID
Bulk import: POST /v1/memory/add/bulk with target_brain_id, 100 per request
Unsure items → parent brain: The AI re-routes organically during sessions
After import: Auto-routing works for ongoing ingestion (brains now have content to compare against)

Day-1 problem: Auto-routing can't work with empty brains — there's nothing to compare against. Always use explicit target_brain_id for initial imports.

AI Discovery

How any AI finds its way around:

MCP: load_brain returns accessible_brains[] with IDs, names, descriptions, routing_rules + documentation{} with URLs
REST: GET /v1/brains returns the full hierarchy
Skill file: GET /skill returns the comprehensive behavioral guide + full API reference

Tier Comparison

Capability	Free	Pro	Business	Enterprise
Personal brain	✓	✓	✓	✓
Team brains	—	Unlimited	Unlimited	Unlimited
Members per brain	—	Invite + roles	Invite + roles	Invite + roles
Brain hierarchy	—	2 levels	Unlimited depth	Unlimited depth
Admin dashboard	—	✓	✓	✓
Brain analytics	—	Per-brain	Per-brain + org-wide	Per-brain + org-wide
SCIM provisioning	—	—	✓	✓
Auto-ingestion connectors	1	Unlimited	Unlimited	Unlimited
SSO (SAML/OIDC)	—	—	—	✓
Dedicated support	—	—	—	✓
Custom data retention	—	—	—	✓
SLA	—	—	—	99.9%
API rate limits	Standard	Elevated	High	Custom

Security

Auth: Three methods — OAuth 2.0 (MCP + brain management), API keys (memory ops), webhook tokens (ingest-only)
Brain isolation: Every query scoped to brain_id. No cross-brain leaks.
Audit logging: Every operation logged (who, what, which brain, when).
Encryption: TLS in transit, encrypted at rest (Railway).
SOC 2: Railway is SOC 2 Type II certified. Application controls deployed.

Privacy · Skill File · support@zombie.codes