Cortex documentation
Cortex builds and runs business applications. AI agents do the engineering under human control: a team describes what an application must do, and cortex derives requirements, proposes a design, builds the software in the runtime the requirements call for, writes tests that keep proving those requirements, and delivers a package the customer runs on their own. Agents on the platform are configured as data, act only through typed tools and answer under safeguards the platform enforces.
These pages describe the platform at the product and architecture level for the build named in the header. Details that change from build to build are left out.
The pages
| Page | Covers |
|---|---|
| Platform overview | The objects cortex is made of and how they connect. A project is a customer's workspace with its own engine fork |
| Getting started | Organisations, roles, projects, the navigation, the first week |
| Architecture and components | The three planes, components by responsibility, stores by role, model access, hosting, CI/CD, security posture |
| Data governance and pipelines | Versioned source configuration, mappings, rules and targets executed as a typed pipeline with an audit trail; nodes, runs, versioning, access policies, analytics |
| Applications | App services: whole applications in their own containers, in any runtime, framed by cortex through an optional SDK; views, companions, sharing, guides, changing an app |
| Agents and MCP | Manifests naming a persona, tools (fork endpoints) and safeguards; the process model, isolation, MCP surfaces, external MCP clients |
| Business workflows | Processes with steps for roles, people, agent actors and code; definitions, triggers, live runs, human gates, a human inbox |
| Models and machine learning | A shared machine-learning engine (tabular and time series), extensible per project, usable in pipelines and workflows |
| Safeguards and correctness | Capability safeguards by construction; correctness safeguards as data, enforced after every answer, recorded and tested |
| Requirements and knowledge | Sources to requirements to preview to tasks to evidence, with provenance re-derived by the platform; knowledge pages, the summary |
| Tests and health | Requirement-linked declarative tests, one portable runner, a health verdict per project, the Status page, the watchdog |
| Independent applications | Why a generated application does not depend on cortex |
| Delivery lifecycle | From sources to a delivered application, step by step |
| Deployments and environments | Environments, exports, promotion, and the customer archive: ordinary source, containers, manifests, runbook and tests |
| Security and operations | Isolation, access, audit, secrets, observability, compliance |
| Integrations and API | REST API, MCP surfaces, access tokens, single sign-on, webhooks, connectors, the app SDK, intake and alert channels |
| Glossary | The vocabulary in one table |
Where to start, by role
| You are | Start with | Then |
|---|---|---|
| A decision maker evaluating the platform | Platform overview, Independent applications | Delivery lifecycle, Security and operations |
| A team lead setting up a customer organisation | Getting started | Requirements and knowledge, Applications |
| A data steward | Data governance and pipelines | Models and machine learning, Tests and health |
| An architect or integrator | Architecture and components | Agents and MCP, Integrations and API |
| An operator receiving a delivery | Deployments and environments | Tests and health, Security and operations |
Three principles
The platform is separate from the product it builds. Mindshine operates the platform. The application built for a customer belongs to the customer: source, containers, data and tests. The platform builds it, changes it and keeps proving it works, and is never a runtime dependency of it.
Capabilities are endpoints, and endpoints are tools. A capability is added to a project once, as an endpoint on its engine fork. That endpoint is then usable by people through the UI, by code through the API and by agents as a typed tool.
Agents are configuration. An agent is a document with a persona, a list of tools by endpoint name, a model and optional safeguards. Adding a tool means adding an endpoint and one line. Changing what an agent may say means editing its safeguards on a page.
Conventions
- Pages, buttons and sections are named as they appear in the product: Dashboard, Alerts, Board, Feed, Apps, Agents, Docs, Build, Data Governance, Operations, Admin, Settings.
- "Safeguards" are the rules that bound what an agent may do and say. "Business workflows" are the processes with human and agent steps. "Agent runtimes" and "external MCP clients" are programs outside cortex that connect to its tools.
- Open standards are named (MCP, Streamable HTTP, OAuth 2.1, OpenID Connect, JSON, Kubernetes, containers, git). Internal technologies are described by their role, such as "the versioned configuration store", so the pages stay true when an implementation changes.
- Wherever a model is involved, the pages say "the configured model provider". Cortex does not depend on one model vendor.