Core concepts
Cendriix orchestrates complex engineering tasks by composing agents, tools, and workflows inside a governed, auditable runtime. This page explains the key primitives and how they relate to each other.
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 of every decision, tool call, and cost accumulation. Runs are immutable once completed, they can be replayed but not modified.
Every run is tied to a workspace, a workflow, and optionally a ticket or external trigger. The orchestrator uses the run as the unit of traceability, every action taken during a run is logged against it, making it possible to answer "what happened and why" for any run, at any time, even months later.
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. Every tool call an agent makes is subject to the active policy set for the workspace and the run.
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 is the most common starting point: it reads a ticket, plans a code change, runs CI, deploys to preview, and waits for approval before merging to main.
Workflows are versioned and stored in your workspace. You can fork, modify, and re-publish them. When a run is triggered, the orchestrator resolves the workflow version at trigger time, so in-flight runs are not affected by workflow edits.
MCP
An MCP (Modular Capability Provider) is the plugin layer that gives agents access to external services. Each MCP exposes a typed toolset, for example, the AWS MCP exposes aws.ec2.describeInstances,aws.s3.putObject, and so on. Agents can only call tools that appear in their permitted tool list.
MCPs run in isolated sandboxes and handle all authentication transparently. The Cendriix catalog provides verified MCPs for the most common integrations; you can also build and publish private MCPs for internal APIs. Every MCP call is recorded as a structured audit event and contributes to the run's cost meter.
Skill
A skillis a reusable, parameterised sub-task that an agent can invoke as a single atomic action. Skills are higher-level than individual MCP tool calls, for example, a "deploy to ECS" skill might orchestrate a dozen AWS API calls internally, but exposes a single clean interface to the calling agent.
Skills can be shared across agents and workflows. They are versioned and audited in the same way as MCP tool calls. The built-in agent library ships with a standard skill set; you can extend it via the Agent SDK or compose skills visually in the Workflow Composer.
Guardrail
A guardrail is a policy rule that constrains what agents can do during a run. Guardrails can block specific tool calls, require human approval before an action is taken, enforce cost ceilings, or restrict which environments an agent can write to. They are evaluated synchronously before each tool call, if a guardrail blocks an action, the run pauses and notifies the relevant approver.
Guardrails are authored as YAML policy files and versioned in your workspace. They compose, a run applies both the workspace-level policy and any workflow-level overrides. The most restrictive applicable rule wins. Guardrail decisions are recorded as audit events with the matched rule ID and the actor.
Approval gate
An approval gate is a workflow step that pauses the run until a human with the required role explicitly approves or rejects continuation. Gates can be defined at fixed points in a workflow (e.g. before a production deploy) or triggered dynamically by a guardrail that requires approval for a specific action.
Approvals can be granted via the dashboard, the CLI (cendriix run approve), the REST API, or a connected Slack channel. Every approval and rejection is recorded with the approver's identity, timestamp, and any note they attached. Runs time out at approval gates after a configurable window (default 24 hours).
Time travel
Time travelis Cendriix's run replay capability. Because every run records a complete, deterministic snapshot, including all LLM inputs and outputs, tool call arguments and responses, and intermediate state, any past run can be replayed step by step with side effects intercepted.
Time travel is used for debugging (inspect the state at any step), compliance (prove what happened and when), and safe testing of policy changes (replay a real run under a new policy without executing real cloud actions). Replay runs are always marked as synthetic and do not generate audit events that could be confused with real production actions.
Audit event
An audit event is an immutable, structured record of a significant action that occurred within a run or workspace. Every tool call, approval, policy verdict, login, and configuration change is recorded as an audit event with a timestamp, actor identity, event type, and payload.
Audit events are append-only and cannot be deleted. They are queryable via the REST API and the CLI, exportable to CSV, JSON, or NDJSON, and can be streamed in real time to a SIEM, S3 bucket, or Splunk. Retention is configurable per workspace (default 90 days; extended to 7 years on Enterprise plans with compliance mode enabled).
Cost meter
The cost metertracks real-time spending for every run, broken down by agent, tool call, and LLM token usage. Costs accumulate live and are visible in the run view, the OpsBar at the bottom of the dashboard, and via the API. Runs can be configured with a cost ceiling, if a run's accumulated cost exceeds the ceiling, it pauses and alerts the workspace owner.
Cost data is retained with the same retention policy as audit events and is exportable for internal showback / chargeback. The cost meter uses list pricing from each LLM provider and cloud service; custom pricing can be configured for enterprise accounts with volume discounts.