Get started

OutcomeCI runs agent workflows that act on real systems through narrow, audited grants. A workflow is one file in your repository: a trigger, the secrets and APIs it may use, and the steps an agent works through. You build it on your machine and run the same file in the cloud.

In 0.71.0

Connect Codex, Claude Code, and OpenCode through Vault. Select an agent with agent and its credential with auth: secrets.<name>, then grant the workflow access to that Vault entry. Named credentials let workflows choose the account they run with. Existing accounts need reconnecting after the Vault migration. See coding agent setup and Upgrade to 0.71.0.

Add an objective and training labeler to describe the intended outcome and evaluate completed runs. These v1 fields arrived in 0.70.0. Choose an LLM or a decision model such as TypeSafe/Jev, and mark low-confidence annotations for review with review_below. See Training and run labels.

Workflow capabilities

Dispatcher workflows use typed decisions to route an incoming event to named child workflows. Ordinary model steps support 16 providers with your own Vault keys, with capability checks for tools, images, and model context limits.

How it fits together

1. Write the workflow. oci init creates outcome.yml, an outcomeci.workflow/v1 file with a manual trigger, a GitHub API binding, and two steps. Edit the steps, their instructions under .outcomeci/instructions/, and the grants each step holds.
2. Keep secrets in the local Vault. oci vault local put stores the credentials the workflow's APIs use, encrypted on your machine: a token, an OAuth app, a GitHub App installation, or any other kind the API accepts. The workflow refers to them by name, such as vault:github, and never contains a value or says how to authenticate.
3. Run it in the runner container. oci workflow run starts the same runner image OutcomeCI uses for cloud runs, with your checkout, your local Vault values, and your own agent login. It runs the workflow once, now: the trigger is simulated, so a cron workflow runs immediately instead of waiting for its schedule. Every API call goes through the broker and lands in the run's journal, so you see exactly what the workflow did.
4. Take it online. When the run does what you want, store the same secret names in the workspace Vault and sync the file with oci workflow sync. Only then do email, webhook, and cron triggers start runs on their own, on managed runners.

The file you tested is the file that runs. Only where the secrets and the agent login come from changes.

What you need

• Docker, Podman, or Rancher Desktop, for the runner container. See container setup.
• A Codex, Claude Code, or OpenCode login for the agent that runs the steps.
• Credentials for the APIs your workflow uses, such as a GitHub token. An API without a connector can be requested as a GitHub issue; see Connectors.
• An OutcomeCI account when you take the workflow online. Nothing before that step needs one.

Follow the path

Build and test

• Quickstart
• Write a workflow
• Training and run labels
• Bring your own model key
• Connectors
• Vault
• Run in the container
• Review run artifacts
• Review calls with a policy

Take it online

• Use OutcomeCI Cloud
• Webhooks
• Share a workflow
• CLI reference

Next

Install the CLI and run your first workflow.