Core Concepts

Cendriix orchestrates complex engineering tasks by composing agents, tools, and workflows inside a governed, auditable runtime. This page explains the key primitives.

Run

A run is a single, bounded execution of a workflow. It has a unique ID, a lifecycle (queued → running → awaiting approval → done/failed/cancelled), and a full audit trail. Runs are immutable once completed — they can be replayed but not modified.

Every run is tied to a workspace and a workflow. The orchestrator uses the run as the unit of traceability — every action is logged against it.

Agent

An agent is an autonomous LLM-powered worker that performs a specific class of tasks within a run. Built-in agents include the Orchestrator, Dev, SRE, QA, and Security agents. Each agent is configured with a model, a system prompt, a set of permitted MCP tools, and a resource budget.

Agents communicate by passing structured messages through the run context — they do not share memory across runs. Custom agents can be forked from built-in agents or built from scratch using the Agent SDK.

See also: Custom agents, Policies & guardrails

Workflow

A workflow is a directed graph of agent steps, conditional branches, and approval gates. Workflows are defined in YAML or visually in the Workflow Composer. The built-in ship-from-ticket workflow reads a ticket, plans a change, opens a PR, runs CI, deploys a preview, and waits for approval before merging.

Workflows are versioned and stored in your workspace. When a run is triggered, the orchestrator resolves the workflow version at trigger time — in-flight runs are not affected by edits.

See also: Flows

MCP

An MCP (Modular Capability Provider) is the plugin layer that gives agents access to external services. Each MCP exposes a typed toolset — e.g. the AWS MCP exposes aws.ec2.describeInstances, aws.s3.putObject, etc. Agents can only call tools in their permitted list.

MCPs run in isolated sandboxes and handle authentication transparently. Every call is recorded as an audit event and contributes to the run’s cost meter.

Skill

A skill is a reusable, parameterised sub-task that an agent can invoke as a single atomic action. Skills are higher-level than individual MCP tool calls — e.g. a “deploy to ECS” skill might orchestrate a dozen AWS API calls internally but exposes a single clean interface.

See also: Custom agents, Build an MCP

Guardrail

A guardrail is a policy rule that constrains what agents can do during a run. Guardrails can block tool calls, require approval, enforce cost ceilings, or restrict environments. They are evaluated synchronously before each tool call.

Guardrails compose — a run applies both workspace-level and workflow-level policies. The most restrictive rule wins.

See also: Policies & guardrails, RBAC & SSO

Approval gate

An approval gate pauses the run until a human with the required role approves or rejects. Gates can be fixed workflow steps or triggered dynamically by guardrails.

Approvals can be granted via the dashboard, CLI, API, or Slack. Every decision is recorded with the approver’s identity and timestamp.

See also: Quickstart, API: approve run, RBAC & SSO

Time travel

Time travel replays past runs step by step with side effects intercepted. Every run captures a deterministic snapshot of LLM I/O, tool calls, and state. Use it for debugging, compliance proof, and safe policy testing.

Replay runs are marked as synthetic and do not generate real audit events.

Audit event

An audit event is an immutable, append-only record of every significant action — tool calls, approvals, policy evaluations, and auth events. Events are structured JSON, indexed in OpenSearch, and queryable via dashboard, CLI, or API.

See also: Audit log, CLI: cendriix audit

Cost meter

A cost meter tracks LLM tokens, MCP call costs, compute time, and storage for every run in real time. Guardrails can reference cost meters to enforce budgets.

See also: Cost meters, Policies & guardrails