Triage an incoming alert
Start from an incoming webhook, investigate the issue, and propose a fix for review before making changes.
Explore the alert workflowComplex work, made simple.
Your workflows.Your agents.Your outcomes.
Outcome Continuous Intelligence™ brings people, agents, and tools together to keep things moving.
Requested → Refined → Approved → CompletedInspect the trace ↗
01 / Define the work
Describe the workflow. Build it together.
Connect your favorite agent to OutcomeCI and describe what you want done. Build the steps, tools, and approvals together, then let OutcomeCI run the workflow.
draft- Read the request and repositories. Propose a plan in the thread.
discuss- Work through feedback with the requester until they approve.
implement- Make the agreed changes within the workflow's permissions.
announce- Bring the result back to the conversation where it started.
Ask your agent
Build a workflow that turns Slack requests into pull requests. Discuss the plan with the requester and wait for approval before making changes.
- 01
draftAgent step - 02
discussHuman approval - 03
implementAgent step - 04
announceAgent step
Review the workflow together. OutcomeCI runs it when work arrives.
View the complete workflow
apiVersion: outcomeci.workflow/v1
name: slack-to-pull-request
trigger:
webhook: {uses: slack, auth: secrets.slack_signing, events: [mention, dm]}
secrets:
slack: vault:slack/bot-token
slack_signing: vault:slack/signing-secret
github: vault:github
apis:
slack: {uses: slack, auth: secrets.slack}
github: {uses: github, auth: secrets.github}
reasoning:
default: {runner: codex}
steps:
- draft:
reason: >
Read the repositories named in the request. Draft a plan with
a section per repository and post it in the request's thread.
from: trigger
can:
- github.read
- slack.post: {channel: trigger.channel, thread_ts: trigger.ts}
returns:
plan: {summary, repos: [{repo: {owner, name}, steps: [string]}]}
- discuss:
with: draft.plan
converse: slack.thread(draft.calls.slack.post)
by: trigger.user
until: converged
max_turns: 12
returns: [plan, status]
- implement:
when: discuss.status == "converged"
for_each: discuss.plan.repos as target
reason: Implement the approved plan and open one pull request.
with: [discuss.plan, target]
can:
- github.write: {repo: target.repo}
policy: "One branch, one PR, only files the plan needs. No force-push."
returns:
pr?: {url, number: int, branch}
reason?: string
- announce:
with: [implement, discuss.plan]
reason: Reply in the original thread with each PR link or the reason no PR was opened.
can:
- slack.post: {channel: trigger.channel, thread_ts: trigger.ts}
02 / Set the boundaries
Shape the plan. Then approve it.
Decide where people guide, review, and approve. Give agents clear permissions for each step and keep changes within the boundaries you set.
Permissions for each step
Choose which operations each step can perform and which resources it can access. Calls outside those grants are refused.
Policy review before changes
Add rules such as one branch and one PR. A policy reviewer checks proposed changes before they are sent.
Credentials stay in the Vault
OutcomeCI attaches credentials to API calls. The agent works through grants without receiving the tokens.
03 / See what happened
A traced execution environment.
Every run leaves a record you can inspect, from the first tool call to the final result.
See what each step called, what came back, and what was refused, with the reason alongside it. Follow the work all the way to its result.
Explore execution and policy review Completed5 API calls · 1 refused
01github.readacme/consoleConfirmed
Read the activity page and its existing tests. Repository contents returned to the draft step.
02slack.post#product-engineering / original threadConfirmed
Posted the revised CSV export plan, including filtered results and the existing column order. The message receipt identifies the conversation used for approval.
03github.writeForce-push proposalRefused
Policy review denied the proposed force-push. The policy allows one new branch and one PR, with no force-push. This request was not sent to GitHub.
04github.writeacme/console / pull request #142Confirmed
Opened a pull request from a new branch for the approved CSV export. GitHub returned the PR number and URL.
05slack.post#product-engineering / original threadConfirmed
Posted the pull request link and a summary to the originating thread. Slack returned the message receipt.
Result returned to the Slack threadExpand a call to inspect
Built for choice
Keep your workflow.
Change your agent or model.
Keep your workflows in OutcomeCI or in your repository. Choose the agent and model for each step, and run locally or in the cloud.
Your agent
- Codex
- Claude Code
- OpenCode
Set a default, override a step, or add a fallback for usage limits.
Configure your agentsYour models
- OpenRouter
- LiteLLM
Bring the model access you already have. Choose a model per workflow or step without tying your orchestration to one provider.
Choose your modelsYour execution environment
LocalOutcomeCI Cloud
The same workflow format and runner image. Credentials configured for each environment.
Explore local executionPrefer to start with your favorite agent?
Connect it to OutcomeCI with MCP and build your workflow together.
Prefer to start on your machine?
Test locally with Docker and your agent login. No OutcomeCI account needed.
pipx install outcomeci-cliBuild around your team
One workflow is just the beginning.
Start from an event, a schedule, or a request. Bring together the tools, agents, and approvals each job needs.
Answer a repository question
Give an agent read-only access to the relevant code and bring an answer back to the person who asked.
Build a read-only workflowPrepare the morning update
Gather repository activity, summarize what changed, and share an update on a schedule you choose.
Start with a scheduled workflowStart with an event Slack · Webhook · Email · Schedule · CLI
Connect your tools Explore open-source connectors ↗
Questions
Frequently asked questions
Is OutcomeCI only for coding workflows?
No. OutcomeCI is an orchestration framework for agent workflows. Define a trigger, steps, tools, and approvals around the work you want done. The pull request walkthrough is one example; workflows can also investigate questions, summarize activity, and act through supported connectors.
Which agents and models can I use?
OutcomeCI supports Codex, Claude Code, and OpenCode. Choose a runner and a model it supports in your workflow, override the agent for a particular step, or configure a fallback for usage limits. Keep your workflows in OutcomeCI or in your repository.
Where can my workflows run?
Run workflows on OutcomeCI Cloud's managed runners, or test them locally with Docker and your own agent login. Both use the same runner image and workflow format. Credentials and agent connections are configured for each environment.
What does the execution trace record?
The run's journal records API calls, their results, and refusals with reasons. Use it to inspect what a workflow attempted and what happened. It is a record of tool execution, not a transcript of an agent's private reasoning.
What happens if a run fails or an agent hits a limit?
Open the run log to see what failed and inspect the recorded calls before retrying. Cloud runs retry certain temporary failures, such as a busy agent connection, up to five times. Configure a fallback agent for usage or rate limits. For failed local runs, fix the cause and resume with the CLI's retry option. Calls with an uncertain outcome are not automatically replayed.
What if nobody approves the plan?
You set the approval window. An approval step that times out skips the remaining steps. In the walkthrough, implementation requires an approved plan; if the discussion times out or reaches its turn limit without agreement, implementation is skipped.
How are permissions and secrets handled?
Each step has explicit grants scoped to operations and arguments. The broker refuses calls outside those grants and attaches credentials from the Vault to allowed calls. Optional policy review checks proposed changes against plain-language rules, and workflows can wait for human approval.
Which tools and triggers are supported?
GitHub and Slack connectors are available today. Start workflows from Slack mentions and direct messages, webhooks, email, cron schedules, or the CLI. Connectors are open source; request additional APIs through the connectors repository.
Do I need an account to try it locally?
No. Install the CLI and test workflows locally with Docker, your agent login, and credentials for the tools you connect. Create an OutcomeCI account to run workflows on managed cloud runners.
What will your first workflow do?
Bring your tools. Choose your agent. Put your team's next workflow into motion with OutcomeCI Cloud.