Agentic workflows

Cortex ships its own orchestration layer: business workflows. A workflow is a process drawn on a canvas, with steps assigned to roles, people, agent actors or code, decisions with outcomes, triggers that start runs, live animated runs with a reviewable output, and an inbox for the humans in the loop. An agent actor on a step is a cortex agent (a manifest) with an execution contract; it does the step, records its output, and the process moves on or waits for a person. Everything about a workflow is data: a new process, trigger or actor needs no code. This is what an "agentic workflow" is in cortex, and why a project built on cortex does not need a separate orchestration framework.

The objects

Object	What it is
Definition	The process: task, decision and end nodes with edges, drawn in the Workflows canvas. Versioned in an append-only history; publish and unpublish are explicit.
Step assignment	Every task or decision is assigned to exactly one of: a role (any member holding it may act), a person, an agent actor, an endpoint (a code step on the fork), or a sub-process (a reusable definition, for example an approval chain).
Trigger	A listener that starts a run: an email that matches a query, an in-product form (a document upload), a schedule, or a data condition on the project's database. Events are de-duplicated on a key; the triggering document or message lands in the run's context.
Run	A live instance. The canvas animates the current node; agent steps post progress lines while they work; each completed step keeps its output (`form_data`) for the steps after it.
My Work	The inbox of human steps assigned to the signed-in person or their roles. Completing a task is one form.
Actor	An agent whose manifest carries an `actor` block (capabilities: which connectors it may use, or judgment only) and an execution contract in its persona: what to produce for each step it owns, the exact output keys, and the degradation rule when a connector is not available.

The engine is a Flow endpoint family on the shared prototype (cortex.workflows.api); state lives in wf_* tables in the project's own Postgres target. The UI reaches it through one thin backend proxy with an action allow-list and server-side identity stamping, so a browser can never act as someone else, and a shared application gets only the run surface (start, complete, read), never authoring.

How an agent step executes

A run reaches a step assigned to an actor. The engine files an agent task with the step's inputs: the task text, the outcomes it may choose, the triggering event and the outputs of earlier steps.
A worker claims the task and fetches the actor's manifest. The execution contract in the persona says what to produce; the tools are fork endpoints the worker may call for data; actor.capabilities say whether it may touch a connector (mail, calendar) or is judgment only.
The worker grounds its answer in the project's data (read-only queries, tool calls), posts progress lines the canvas shows on the pulsing node, and completes the task with an outcome from the allowed list and the output keys the contract names. Decision steps require an outcome.
The process continues to the next step. A human gate is simply the next step being assigned to a role or a person.

Workers are the same two kinds the platform already has: the agent fleet (headless, for judgment-only steps and steps without a connector) and a local session with connectors. The routing is decided by the actor's capabilities, not by code. An endpoint step that fails three times leaves the run open and visible so a person can act, rather than completing silently.

Human gates and the taught patterns

The pattern the platform's own Workflow Assistant teaches when it designs a process:

Score with a model or an agent, then route the risky outcomes to a human gate and let the rest continue automatically.
Put approvals in a reusable sub-process so every workflow that needs one uses the same chain.
Give every decision at least two outcomes, and every task exactly one owner.
Keep the run's evidence in the outputs: an agent that read data records what it read (a written analysis, a count, a flag that a write happened), so the run view shows the side effects.

Where the guardrails apply

Two mechanisms bound an actor. Its execution contract fixes what it must produce and how it degrades, and the step's outcomes fix what it may decide. The human gate after it is the review. The runtime guardrails described on Guardrails and correctness (tools-only grounding, the verifier pass, the ledger) apply to an agent's answers in the chat and through the evaluation route, which is also how an actor's behaviour is tested: an agent test asks the actor the question a step would ask and asserts on the answer, the tool calls and the verdict.

Do you need an orchestration framework?

Not for a project built on cortex. The table maps the usual framework concepts to what cortex has.

Framework concept	In cortex
Graph of nodes with state	A workflow definition; the run's `instance_data` and each step's `form_data` are the state
Tool-calling agent node	A step assigned to an agent actor; its tools are the manifest's endpoints
Conditional edge	A decision node with named outcomes; the actor or the person picks one
Human in the loop	A step assigned to a role or a person; the My Work inbox
Trigger / event source	A listener: email, form, schedule, data condition
Sub-graph	A sub-process step
Retry and failure policy	Endpoint steps retry three times and then hold the run open for a person
Versioning	Append-only definition history with restore
Observability	Live canvas, progress lines per step, the run's outputs, the guardrail ledger for agent answers

A team that already runs LangGraph or AgentCore keeps them and connects them to cortex over MCP (see Agents and MCP); nothing in a cortex project depends on them. A team starting on cortex designs the process on the canvas, or asks the Workflow Assistant to design it from a plain-language description, and adds actors by writing manifests.