Delivery lifecycle

A cortex project goes from requirement sources to a running, tested application in a sequence of steps that each end in something a person can inspect and approve. This page walks the sequence, names who does what at each step, and shows why the work that usually surrounds an agent project (APIs, configuration, environments, glue) is not on the list.

1. Requirement sources

A team uploads documents (specifications, change requests, meeting notes, recordings) or types requests. Sources are versioned as a set: any addition mints the next version and snapshots the item set, so a past version renders exactly as it was. Intake handles docx, PDF, audio transcription and images.

People do: upload, type, decide when a version is complete.

2. Requirements

A schema-constrained generation derives the requirements from the sources: what the project does, each with a kind (functional, quality, constraint, design, non-goal, noise), use cases, and an origin. A material origin is a verbatim quote that the backend re-finds in the source text and positions; an as-built origin is the live application that implements it. The generation must cover all of the text: passages that ask for nothing are linked to a "not a requirement" row, and the Requirement sources tab paints uncovered passages until nothing is left. Requirements are never regenerated once they exist; a new sources version yields a delta review of only the changed passages, and a person can ask "what are the requirements of this passage" on any selection.

People do: read, correct, set a status manually where they know better (manual statuses survive reviews).

3. Build preview

The first sources version opens a build preview: a short fleet generation designs a few variants that differ in shape, never in scope, each shown as two screen mockups first, then a plain-language summary, a size estimate and a folded technical inventory (data, services, screens, workflows, agents, models, pipeline, exclusions). A person comments, regenerates with a steer, edits any text, and approves one variant. The approval adds the design and its pictures to the requirement sources and files exactly one build card. Later versions skip the preview and book a delta review instead.

People do: choose the shape of the application. This is the first hard decision point.

4. Build

The agent fleet claims the build card and builds the application as app services from a scaffold: a React module and a Node server by default, or the runtime the requirements call for (a .NET identity service, a Java API, a database engine), each with its own Dockerfile and source tree. Services are built in-cluster and published at their own hostnames. The fleet writes the agent manifests and tool endpoints the design named, the workflows, the guides, and ends every build by authoring and running tests for the requirements it made true. Everything lands as versions on the fork and as a completion record with evidence on the card.

People do: watch the Board, read the evidence, accept or file a change. A change is a card again; the fleet changes the running service through read, update, build.

5. Tests and the watchdog

Every requirement carries tests in a portable format: endpoint, HTTP, SQL, browser (steps over selectors) and agent (what an agent answered and the guardrail verdict). One runner executes them inside cortex, inside every customer archive and on a laptop. The backend runs every project's suite every 15 minutes and after each deploy, folds results into one health verdict per project, files an alert and posts to Slack on a transition. Agent-written tests are reviewed by a second session. A red suite refuses a push of the project to another environment.

People do: read the Status page; nothing else, unless it turns red.

6. Delivery

The Deployments page exports the project. The customer archive contains the application as ordinary source: app-services/<name>/ with each Dockerfile and tree verbatim, a compose file with an acyclic start order, optional Kubernetes manifests, optional Azure Container Apps Bicep, optional GitHub Actions or Azure Pipelines, a generated runbook and README, per-archive secrets, the tests as a compose service, and the project's knowledge pages. Cortex companions (chat, workflows, guides, models, pipeline, governance, docs) are included only when a flag on the Delivery card says so; by default the customer receives exactly the application. See Independent applications.

People do: choose what to distribute. This is the last hard decision point.

Where the "support work" went

The evaluation named the cost that dominates agent projects: building the support around the agent, such as APIs and configuration handling, and establishing guardrails. In cortex each of those is a property of the platform rather than a task of the project.

What a team looks like

A cortex project needs a product owner who decides at the three decision points, a domain expert who reads requirements and evidence, and an engineer who reviews endpoints and services when the fleet's work touches something sensitive. The reference for size and pace is the eSpace identity service: a Duende IdentityServer STS with an operator console, a sample relying party, a SQL Server stand-in, health checks, documentation, runbook, Kubernetes, Container Apps and Azure Pipelines definitions and a customer archive, built through twenty fleet cards over four days, at roughly eight hours of machine time, with two to three person-days of specification and review.