Org memory: the Cortex

The Cortex is the workspace's operating truth — doctrine, strategy, authority, guardrails, playbooks and knowledge — kept as one searchable index. It is a projection, not a second store: each entry resolves to its live source (a policy, a charter section, a strategy stream, a ledger event) with its version and provenance, so the index can cite but never drift.

The Cortex with its seven sections and entry cards
Cortex

The seven sections

The left rail lists seven sections — Doctrine, Strategy, Authority, Guardrails, Playbooks, Knowledge, Ledger — each projecting one or more of the nine underlying memory classes (framework, constitution, strategy, policy, org graph, SOPs, glossary, sources, ledger). Pick a section to see its entries as cards: title, summary, version, scopes, and who last touched it, human or AI. The Knowledge section also surfaces Sources — the files and references entries derive from.

Each section has its own search box; matching filters the cards live. Open a card for the detail view: full amend history (v1, v2 … with author and note per revision) and the pointer to the live source it resolves to.

Add to a section

  1. Choose the section and select Add

    A multi-class section files your entry into its canonical class.

  2. Title, summary, scopes

    Scopes narrow who and what the entry applies to; leave them empty for org-wide truth.

  3. Save

    The entry is written with your provenance and a spine event — versioned from v1.

Amend an entry

Amending opens the same composer over the existing entry. An amendment requires a revision note — the change must be auditable — and bumps the version, with the previous state kept in the entry's history.

Proposals: agents suggest, you merge

Agents do not amend the Cortex directly. An agent that wants to change an entry proposes an amendment; the proposal waits on the entry, marked pending, with the proposer and their note. Accept & merge versions the entry with the proposal's content — the role check and the no-self-merge rule are enforced server-side, and a refused merge states its reason inline. A proposal you do not merge stays pending on the entry.

What ends up remembered

The Cortex indexes what the org has authored: frameworks, policies, SOPs, glossary terms, strategy, the org graph and the decision ledger — plus entries you and agents add here. Day-to-day traffic (mail, messages, calls) is not Cortex material; it feeds agent memory below.

How agents recall

Alongside the Cortex, the workspace keeps a unified agent memory over its actual activity — interactions, actions, and consolidated digests of channels, calls and work. When an agent (or the assistant) needs context, recall runs server-side:

  • Scoped — to the whole org, the agent's own perspective, one channel, or one entity; a channel scope matches the channel's digest and the threads, tasks and ended calls inside it.
  • Layered — broad questions surface consolidated summaries first; specific ones surface the raw items, each with drill-down pointers to what it was derived from.
  • Access-floored — every result is filtered by the same visibility rules you hold: restricted channels and named-only records stay absent from an agent's recall exactly as they are absent from its lists. Cortex entries are re-verified against the live entry at recall time, so a narrowed or archived entry stops surfacing immediately.

There is nothing to configure here — recall is how grounded answers across the workspace (ask-the-sheet, ask-the-pipeline, agent briefs) find their context.