Author a workflow

A workflow is a durable, version-controlled sequence of agent steps that Cendriix executes on your behalf. Workflows are the primary unit of automation on the platform — everything from a ticket-to-PR flow to a cross-team incident response sequence is expressed as a workflow.

What is a workflow?

A workflow defines what to do, not how to do it. Each step in the workflow specifies an agent type, its Cortex knowledge inputs, and its output bindings. The Cendriix orchestrator resolves the execution: model selection, cost accounting, RBAC checks, and approval gate enforcement all happen transparently.

Workflows are different from scripts in three key ways:

• Durable — a workflow survives infrastructure restarts. A Temporal-backed orchestrator checkpoints every step.
• Auditable — every step emits a hash-chained audit event. The complete execution history is immutable and exportable.
• Cost-capped — ACU budgets are enforced before each step executes, not after the monthly bill arrives.

Workflow structure

A workflow is a YAML document with a steps list. Each step has an agent, a context block (Cortex knowledge inputs), and an output block (entities to write back to the graph).

# workflow.yaml
name: ticket-to-pr
description: Write and test a fix for a Jira ticket
cost_cap_acu: 50

steps:
  - id: ingest
    agent: cortex-reader
    context:
      ticket: "{{ inputs.ticket_id }}"
    output:
      - entity: implementation_plan

  - id: write-code
    agent: code-writer
    context:
      plan: "{{ steps.ingest.output.implementation_plan }}"
      repo: "{{ inputs.repo }}"
    output:
      - entity: pr_diff

  - id: run-tests
    agent: test-runner
    context:
      diff: "{{ steps.write-code.output.pr_diff }}"
    gate:
      type: approval
      threshold_acu: 20   # require human approval if cost exceeds 20 ACU
    output:
      - entity: test_result

  - id: open-pr
    agent: github-pr-opener
    context:
      diff: "{{ steps.write-code.output.pr_diff }}"
      test_result: "{{ steps.run-tests.output.test_result }}"
      ticket: "{{ inputs.ticket_id }}"

Authoring a workflow

You can author workflows three ways:

1. YAML — write the YAML schema directly and commit to your repo.
2. Visual Editor — drag-and-drop the graph in the Visual Editor and export YAML.
3. Studio import — paste a Confluence runbook or markdown doc into Studio and review the generated draft.

Step types

Built-in step agents available in all plans:

• cortex-reader — reads entities from the knowledge graph
• code-writer — generates code from a plan
• test-runner — executes the test suite for a diff
• github-pr-opener — opens a pull request
• deploy-canary — initiates a canary deploy
• jira-updater — writes back to a Jira ticket
• slack-notifier — sends a message to a Slack channel

Custom agents are documented in Custom agents.

Approval gates

A gate block on any step pauses execution and requires human approval before the step runs. Gates trigger on two conditions:

• threshold_acu — triggers if the estimated step cost exceeds this ACU value
• blast_radius_score — triggers if the blast-radius score of the affected entities exceeds a threshold

steps:
  - id: deploy-prod
    agent: deploy-canary
    gate:
      type: approval
      blast_radius_score: 0.7    # require approval if blast radius > 70%
      notify_channel: "#platform-approvals"

Cost caps

Set cost_cap_acu at the workflow level to hard-cap total spend. Individual steps can also have caps. When a cap would be exceeded, the run stops and the owning team is notified — no charges beyond the cap are incurred.

Deploying a workflow

# Deploy via CLI (when available)
cendriix workflow deploy ./workflow.yaml

# Or via API
curl -X POST https://api.cendriix.ai/v1/workflows \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d @workflow.yaml