Alice is a sales rep at Initech. She uses an AI agent — support_bot — for note-taking, follow-ups, and recall.

Alice doesn't talk to CortexDB. She talks to her agent. Her agent talks to CortexDB.

support_bot packages that single sentence as an experience envelope and submits it.

POST /v1/experience
Authorization: Bearer ***
X-Cortex-Actor: agent:support_bot

{
  "scope": "org:initech/dept:sales/team:enterprise/user:alice",
  "observed_actor": {"id":"user:alice", "type":"user"},
  "subject":        {"id":"user:alice", "type":"user"},
  "modality": "conversation",
  "content": {
    "kind": "message", "role": "user",
    "text":  "Just got off a call with Priya..."
  },
  "context": {
    "observed_at": "2026-05-08T13:14:00Z",
    "intent":     "deal_status_update",
    "labels":     ["acme", "sales", "q3-launch"]
  },
  "directives": { "extract": ["facts", "entities", "beliefs"] },
  "idempotency_key": "alice-chat-2026-05-08-001"
}

POST /v1/recall
{
  "scope": "org:initech/.../user:alice",
  "view":  "holistic",
  "query": "What's the current status of the Acme deal?",
  "include": ["beliefs", "facts", "episodes"],
  "temporal": { "natural": "last 30 days" },
  "budgets": { "max_tokens": 2000,
               "per_layer_limits": {
                  "facts": 8,
                  "beliefs": 3,
                  "episodes": 2 } },
  "citation_mode": "inline_with_markers",
  "diagnostics":   "summary"
}

"context_block":
  "Acme Corp signed this afternoon for 200 seats [1].
   The deal stage went from poc_complete to signed
   at 3:42pm [2]. The will_close_q3 belief revised
   from uncertain (0.42) to supported (0.94) as a
   result [3]. Primary contact remains Priya..."

"layers": {
  "beliefs":  [/* will_close_q3 @ 0.94 */],
  "facts":    [/* deal_stage=signed, seats=200, ... */],
  "episodes": [/* ep_01HX_acme_deal */]
}

"provenance": {
  "trail": [/* ARIL → hybrid → score → mmr */],
  "citations": {
    "[1]": { "layer":"fact",    "id": "fact_seats_200" },
    "[2]": { "layer":"fact",    "id": "fact_signed"    },
    "[3]": { "layer":"belief",  "id": "belief_01HX_a" }
  } }

The sales manager presses harder: "Why did will_close_q3 jump from 0.42 to 0.94?"

GET /v1/beliefs/why?belief_id=belief_01HX_a

Returns a full support graph — nodes for the belief, the supporting facts and episodes, the events those came from. Each edge labeled. Each weight shown. Plus a natural-language narrative on top.

Four time fields per record

The query "what did the system believe about Acme on April 15, when looked at from May 1?" needs both axes. Single-axis systems can only answer one or the other.

// Sarah, after the deal signed:
// "What did we believe about Acme
//  at lunch on May 12, before the signature?"

POST /v1/recall
{
  "scope":    "org:initech/.../user:alice",
  "view":     "holistic",
  "query":    "What did we know about Acme?",
  "include":  ["beliefs", "facts"],
  "temporal": { "as_of": "2026-05-12T12:00:00Z" }
}

// returns the pre-signature state:
//   deal_stage = poc_complete
//   will_close_q3 = uncertain @ 0.42
// Same data. Different temporal lens.

Alice writes a Slack post about Acme that ends with "honestly I think Priya might leave the company soon." Her agent extracts a belief. That night she realizes she shouldn't have said it. She asks her agent to forget.

POST /v1/forget
{
  "scope":  "org:initech/.../user:alice",
  "layers": ["beliefs"],
  "selector": { "memory_ids": ["belief_01HX_b"] },
  "cascade": "derived_only",
  "audit_note": "User retracted speculation"
}

The belief is gone. The underlying event — Alice's Slack post — is not. That distinction is load-bearing.

Two weeks later, if Priya genuinely starts hinting at leaving, the new event + the retained old event might re-derive the belief. The system isn't pretending the past didn't happen — it's saying "the conclusion was premature."

Three modes, gated separately

Five rules to internalize

1. Personal scopes are the default home. Every human and agent has one. Nothing else reads it without explicit grant.
2. Shared work goes in workspaces. A workspace is just a scope. Maya writes to ws:acme-account, not "hoping" the CSM can read her personal scope.
3. Reads walk up; writes go in. Sarah's recall view=descend aggregates her team's scopes. Sarah doesn't write into them.
4. Scopes auto-register on first write. No "create database" step. Explicit POST /v1/scopes is for adding members or custom policy.
5. GDPR is reference-counted. Personal-only events delete. Cross-scope-referenced events redact. Shared workspaces don't break.

How a request flows

Every API call is evaluated through all four tiers. Each can only restrict — none can re-expand.

• Deployment — operator-set at startup. On-prem allows everything; cloud-multi-tenant denies cross-tenant by default.
• Tenant — Initech's own config (Lana the DPO). E.g., "no employee reads another's personal scope without explicit grant."
• Scope — set by the scope owner. ws:acme-account lists exactly six humans and three agents as members.
• Actor — set per token at issue time. csm_bot is scoped to dept:cs/*, denied forget.gdpr.

X-Cortex-Policy: tier=scope; decision=deny;
                  capability=scope.read.holistic

A workspace like ws:acme-account is structurally identical to user:alice. It differs only in convention and membership:

• Typically not nested under a user/org tree — its own top-level namespace
• Usually has multiple members, declared via POST /v1/scopes
• Often registers a custom consolidation policy

There is no API distinction. A scope is a scope. This single design choice is what lets multiple departments share a customer account, an incident war room, or a project workspace without inventing a separate "workspace" concept.

POST /v1/scopes
{
  "path": "ws:initech-acme-account",
  "members": [
    {"actor": "user:alice",           "role": "owner"},
    {"actor": "user:bob",             "role": "writer"},
    {"actor": "agent:support_bot",    "role": "writer"},
    {"actor": "agent:bob_bot",        "role": "writer"}
  ],
  "policies": {
    "consolidation":       "merge_compatible_beliefs",
    "conflict_resolution": "latest_wins_within_confidence_band",
    "inherit_from":        [],
    "audit":               "full"
  }
}

When Alice's agent and Bob's agent both submit beliefs about Acme into this workspace, the workspace's conflict_resolution policy — not the agents — decides how to merge. Each agent's submissions need not agree; the workspace presents a coherent view.

What RCA-Copilot does

1. Construct a timeline of what happened, as it happens
2. Surface what the system already knew that might be relevant
3. After resolution, write a structured postmortem — as memory, not as a Confluence page
4. Update beliefs and understanding so the next incident is faster to resolve

Without CortexDB: dump Slack logs into Confluence, write a postmortem nobody re-reads, repeat. With CortexDB: the postmortem is a first-class memory that the next incident retrieves automatically.

Workspace setup

POST /v1/scopes
{
  "path": "ws:incident-2027-01-15-payments",
  "members": [
    {"actor": "user:diego",         "role": "owner"},
    {"actor": "user:on_call_alice", "role": "writer"},
    {"actor": "agent:oncall_bot",   "role": "writer"},
    {"actor": "agent:rca_copilot",  "role": "writer"}
  ],
  "policies": {
    "inherit_from": ["dept:engineering/team:sre"],
    "audit": "full"
  }
}

inherit_from is doing real work — it tells CortexDB that recalls against this fresh war room can also pull from the SRE team's accumulated knowledge. The room doesn't start from zero.

It's March. A different team, a different service. notifications-api starts misbehaving. The on-call engineer is a new hire — three weeks in, has never seen the payments incident.

RCA-Copilot fires. Its very first recall against the new war-room workspace pulls in the payment_retry_storm concept. The concept's supported_by array now includes the January postmortem.

The new engineer skips ten minutes of confused debugging and goes straight to the retry config.

Read

• API_DESIGN_V1.md — narrative walkthrough (Alice, one week)
• API_REFERENCE_V1.md — exact contract: endpoints, capabilities, errors
• CORTEXDB_FOR_THE_ENTERPRISE.md — what this deck distills
• schemas/ — normative JSON schemas; both docs are explanatory views
• enterprise_runbooks.md — backup, PITR, SSE delivery, MFA

Build

• SDKs: pip install cortexdbai · npm install cortexdbai
• MCP server: cortexdb-mcp on PyPI — any MCP-capable agent gets memory tools without writing code
• Connectors: Slack · GitHub · Jira · PagerDuty · Confluence — auto-ingest experiences
• Importers: Mem0 · Zep · Letta · OpenAI memory · JSONL
• Local-first: docker run -p 3141:3141 cortexdb/cortexdb — single-node, zero external deps