Cortex documentation
Cortex is a platform for building and running business applications with AI agents doing the engineering work under human control. A team states what an application must do, in documents or in plain requests. Cortex turns that into requirements, a reviewed design, working software, tests that keep proving the requirements, and a delivery the customer can run and support on their own. Agents on the platform are configured as data, act only through typed tools, and answer under guardrails the platform enforces. This site is written for a technical evaluation. Every statement on it is drawn from the code and configuration of the cortex repository, branch dev, September 2026.
Read this first
The evaluation asked five things. Each has a page; the short answers are here.
| Question | Short answer | Page |
|---|---|---|
| What is the stack, where does everything live, what is it written in, which third parties (Kubernetes)? | Node.js and TypeScript services plus one React SPA on AWS EKS, with Dolt, Postgres, MongoDB, Redis and S3 as stores, models through Amazon Bedrock. Every component, version and vendor is listed. | Technology stack |
| Does the cortex stack constrain the stack of an application it builds? | No. A generated application is an arbitrary Dockerfile plus source tree in the language and framework the requirements call for. .NET 8, Node and Python are proven; a Go binary or an nginx is the same shape. | Independent applications |
| Can a generated application live without cortex? | Yes. The customer archive contains ordinary source code, containers, compose and optional Kubernetes or Azure manifests, a generated runbook and portable tests. It contains no cortex runtime unless a cortex companion was explicitly ordered. | Independent applications |
| We run Bedrock, AgentCore and LangGraph and are moving to MCP tools. How does this fit? | Cortex agents run on Bedrock today. Cortex has its own orchestration layer (workflows with agent actors and human gates), so a cortex project needs no external framework; the frameworks you already run consume cortex tools and agents over MCP with an access token minted in Settings. | Agentic workflows, Agents and MCP |
| Most of our agent effort goes into the support around agents (APIs, configuration) and into guardrails so an agent never gives an incorrect answer. | Tools are endpoints named in a JSON manifest, configuration is injected per project, and an agent's correctness contract (scope, tools-only grounding, a verifier pass, a tool budget, a refusal text) is data on the manifest, enforced after every answer, recorded in a ledger and asserted by tests that run on a schedule. | Guardrails and correctness |
How the site is organised
- Platform overview. The objects cortex is made of and how they relate: projects, the engine fork behind each project, endpoints as tools, agents, the agent fleet, the requirements chain, tests, delivery.
- Technology stack. Components, languages, frameworks, data stores, model access, infrastructure, CI/CD, where the code lives.
- Agents and MCP. How an agent is defined, what it can and cannot touch, where its process runs, and how external frameworks connect.
- Agentic workflows. Processes with steps for roles, people, agent actors and code; triggers, live runs, the human inbox; why no external orchestration framework is needed.
- Guardrails and correctness. Capability guardrails and correctness guardrails, the verifier, the ledger, agent tests, the watchdog.
- Independent applications. What a generated application is, what the customer receives, what "supportable without cortex" means.
- Delivery lifecycle. From a requirements document to a running, tested, delivered application, and what a team does at each step.
- Security and operations. Isolation, access control, audit, secrets, observability, compliance posture.
- Evaluation FAQ. The questions from the evaluation answered one by one, with pointers into the code.
Two facts to keep in mind while reading
Cortex separates the platform from the product it builds. The platform (this stack) is Mindshine's. The product (the application built for a customer) is the customer's: its source, its containers, its data, its tests. The platform is used to build and change the product faster and to keep proving it works; it is not a runtime dependency of the product.
Agents in cortex are configuration, not code. An agent is a JSON document: a persona, a list of tools by endpoint name, a model, optional guardrails. Adding a tool is adding an endpoint and one line. Changing what an agent may say is editing its guardrails on a page. This is why the support work around agents is small and why correctness can be enforced by the platform rather than hoped for from the prompt.