CortexDocumentation
Architecture · Platform

Containers and data paths

Every Cortex service, layer by layer, and the two hot paths that carry the platform: capture ingest and agent streaming.

  • Layered servicesClients, edge, entry, services, scheduled work, and storage
  • Capture ingestSigned batches become structured provider events
  • Agent streamingValkey streams carry live requests and replies
Review the layers
Containers and data paths
Container diagram of Cortex services and data paths

Flow runs top to bottom: clients, edge, entry services, the streaming bus, internal services, the scheduled plane, storage. Blue paths are the two hot paths — capture ingest and agent streaming.

Container diagram of the Cortex platform, from clients at the top to storage at the bottom

The layers

LayerWhat lives there
ClientsThe Cortex Sensor on each developer machine and the Cortex web app in the browser
EdgeDNS, CDN and TLS for all public hosts
EntryThe Application API (web app, API, live streaming relay) and the Capture API (capture ingest, device control plane)
BusValkey streams: request queues, per-session reply streams, cancellation broadcasts
ServicesThe Agent Runtime, Memory Foundry, the optional PII redaction stage, and the Model Gateway — the single exit for model calls
ScheduledMemory Pipelines, scheduled jobs, model routing and open-weights inference
StoragePostgreSQL (one cluster per environment) and object storage

Hot path 1: capture ingest

1
The Sensor batches captured activity locally and uploads it as signed batches.
2
The Capture API verifies each batch and writes structured provider events to PostgreSQL.
3
Derivation lanes pick the events up from there — no broker in the batch path.

Hot path 2: agent streaming

1
The browser opens a streaming session against the Application API.
2
The Application API places the request on a Valkey stream; the Agent Runtime consumes it.
3
The Agent Runtime streams the reply back over a per-session stream; the Application API relays it to the browser as server-sent events.
4
Model calls made along the way leave through the Model Gateway only.

Everything else is plain HTTP between named internal services.

Was this helpful?