CortexDocumentation
Architecture · Overview

Cortex architecture

How Cortex turns AI coding activity into organizational memory: what runs where, what talks to what, and which primitives it is built on.

  • Capture to contextFour stages turn signed activity into organizational memory
  • PostgreSQL spineDurable facts, read models, and vector memory
  • Isolated environmentsIndependent production and staging stacks
Cortex platform layers
Cortex platform architecture from clients through services to storage

Cortex has one job: turn your company's AI coding activity into organizational memory. A lightweight Sensor on each developer machine relays AI provider traffic unchanged and uploads signed evidence of every session. Everything downstream is derivation.

Service names on these pages are descriptive. Internal identifiers, hostnames and repository names are intentionally omitted.

The four stages

  1. Capture. The Cortex Sensor, a native binary, sits in front of the developer's AI coding tools — Claude Code, Codex CLI, Cursor and other supported sources. Provider traffic passes through unchanged; every upload is signed by the device.
  2. Ingest. The Capture API verifies each signed batch and writes structured provider events into the environment's database.
  3. Derive. Four lanes work off that record: Memory Pipelines build canonical read models, work streams and cost analytics; Memory Foundry compiles retrievable memory pages with vector search; the Agent Runtime runs the business agents; and the Application API serves the web app and its API.
  4. Connect. The Application API enriches memory with context from the team's collaboration tools: Slack, Jira, GitHub and Notion.

Design principles

  • PostgreSQL is the spine. Every durable fact lives in the environment's single database — capture events, read models and vector memory alike.
  • One broker, one purpose. The only message broker (Valkey streams) carries live agent streaming, nothing else.
  • No hidden queues. Batch derivation workers coordinate through watermarked queue tables in the database, so the batch path needs no message broker at all.
  • Two mirrored environments. Production and staging are fully independent: one cluster, one database and one cache each, with no shared datastore between them.
Was this helpful?