Platform overview

Cortex is organised around a small number of objects. A project is a customer's workspace. Every project has an engine fork: its own catalogue of endpoints and services in the Flow engine, inherited from a shared prototype and extended per project. Endpoints are typed operations on the fork; every endpoint is also an MCP tool. Agents are JSON manifests that name a persona, tools and guardrails. The agent fleet is the pool of coding sessions that builds and changes software from requirement cards. The requirements chain links documents to requirements to tasks to evidence. Tests prove requirements on a schedule. Delivery exports the application the customer runs. This page explains each object and how they connect.

Projects and forks

A project in cortex is paired one to one with a fork in the Flow engine. The prototype fork (core) carries the shared engine: the data-pipeline operations, the workflow engine, the ML engine, the RAG engine, the report renderer, the requirement masters. A project's fork inherits all of it and adds what is specific to the project: its own endpoints, its own function services (Node.js or Python handlers), its own app services (whole applications in their own containers), its own agent manifests and its own environment variables.

Project configuration that is business data (data sources, targets, processing rules, reference lists, data elements) lives in Dolt, a versioned SQL database. Every write is a commit with the author's identity, so the history of a project's configuration is an audit trail. Platform state (users, organisations, projects, the agent registry, jobs, test runs, alerts) lives in a Postgres database named cortex_ops. The engine's own catalogue (forks, endpoints, services, app services) lives in MongoDB.

Endpoints are tools

An endpoint is a flow graph on the fork: an input node, function or service nodes, an output node. Endpoints have names (cortex.dq.exceptions.list), typed inputs and JSON outputs. They run in the engine process, with the project's environment injected through a per-fork wrapper (cortex.invoke_engine), so an inherited operation runs against the project's own databases and buckets without any per-project code.

Every endpoint on a fork can be exposed to an AI client as an MCP tool. The cortex assistant serves MCP over Streamable HTTP at /mcp/p/<project>/b/<branch> with OAuth 2.1 bearer authentication, and inside the platform an agent's tools are exactly the endpoints its manifest names. This is the central design choice: there is one way to add a capability to the system (an endpoint on the fork), and that capability is immediately available to people (through the UI), to code (through the API) and to agents (as a tool). See Agents and MCP.

Agents

An agent is a manifest: an endpoint named cortex.agent.<name>.manifest on the project's fork that returns a JSON object with display_name, persona_prompt, tools (each a name, a description, an input schema and the endpoint it calls), an optional model, an optional actor block for workflow steps and an optional guardrails block. The manifest is validated strictly at discovery; a malformed one is skipped rather than half-registered.

Agents are edited on the Agents page as data: identity, persona, model, tools (reword, remove, attach an existing endpoint) and guardrails. They are reached three ways: pinned in the project chat ("Chat with agent"), as a delegate of the project's orchestrator chat (delegate_to_<agent>), and as a workflow actor assigned to a process step. Externally, the same delegates are MCP tools on the orchestrator endpoint. How an agent process runs and what isolates it is on the Agents and MCP page; what keeps its answers correct is on the Guardrails page.

The agent fleet

The fleet is a separate deployment of worker processes that claim cards from the project's Board and do engineering work: build an application from approved requirements, change an application, write tests, review tests, run browser tests, audit a project. Each card runs in a fresh coding-CLI session in its own process group with a leased model key, against a checkout of the repository, and hands back commits, evidence and a completion record. The fleet is vendor-pluggable: two coding CLIs are wired today and the model for each lane is a registry row, not code. The fleet never edits production data directly; it produces code, configuration and evidence that people accept.

The requirements chain

Cortex keeps a chain from the source of a requirement to the proof that it holds.

Requirement sources: every uploaded document and every typed request, versioned as a set.
Requirements: what the project does, derived from the sources by a schema-constrained generation and pinned to the sources version they came from. Every requirement carries an origin: a verbatim quote re-found in the source text by the backend (never trusted from the model), or the live application that implements it. Text in the sources that asks for nothing is linked to a "not a requirement" row, so no passage is silently ignored.
Tasks: work filed from a requirement to the Board, done by the fleet or by people.
Evidence: screenshots, commits, test results attached to an implemented task. Evidence is what separates "implemented" from "verified".

Before anything is built, a build preview proposes variants with screen mockups; a person approves one, and that approval is what files the build. After a build, an optional analysis reworks the affected requirements against what was actually built.

Tests

Every requirement can carry declarative tests in a portable format (cortex-tests/1): endpoint calls, HTTP calls, SQL queries, browser scenarios (steps over selectors, never code) and agent questions (what an agent answered, and the guardrail verdict recorded over the answer). One runner executes the same tests inside cortex, inside every customer archive and on any machine. The backend runs every project's suite every 15 minutes and after each deploy, folds the results into one health verdict per project and posts a Slack alert on a transition. A red suite blocks a push of a project copy to another environment.

Delivery

A project is delivered as a customer archive: the app services' Dockerfiles and source trees verbatim, a compose file, optional Kubernetes and Azure Container Apps manifests, optional CI pipelines, a generated runbook and README, per-archive secrets, and the tests. Cortex companions (chat, workflows, guides, models, pipeline, governance, docs) are included only when explicitly ordered; by default the customer receives exactly the application. See Independent applications and Delivery lifecycle.

How the pieces connect

requirement sources ──► requirements ──► preview ──► build card ──► agent fleet ──► commits + evidence
        ▲                     │                                           │
        │                     └──────────► tests (endpoint/http/sql/browser/agent) ◄── watchdog every 15 min
        │                                                                 │
   people decide                                          engine fork: endpoints = tools = MCP
                                                                          │
                                       agents (manifests) ◄── guardrails ─┘── chat, workflows, external MCP clients
                                                                          │
                                                          customer archive (no cortex runtime by default)

The three human decision points are the approval of the preview, the acceptance of a build (evidence and green tests) and the choice of what to distribute in the delivery. Everything between them is done by the platform and its agents, under the constraints the following pages describe.