OutcomeCI

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.

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. 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. Email, webhook, and cron triggers then run it 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, for the runner container.
  • 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

Take it online

Next

Install the CLI and run your first workflow.