OutcomeCI

officiel

Créez, validez et gérez des workflows propulsés par des agents à travers les outils de votre équipe avec OutcomeCI.

Que pouvez-vous faire avec OutcomeCI MCP ?

  • Rédiger un plan de workflow — Demandez à votre IA de lire une demande et de proposer un plan étape par étape à l’aide de l’outil draft.
  • Affiner le plan par la discussion — Faites itérer votre IA sur le plan avec vous via discuss jusqu’à ce que vous l’approuviez.
  • Exécuter les modifications approuvées — Demandez à votre IA de mettre en œuvre le plan convenu dans les permissions définies à l’aide de implement.
  • Rapporter les résultats — Demandez à votre IA de publier le résultat, comme les liens de PR, dans le fil de conversation d’origine avec announce.
  • Examiner les traces d’exécution — Demandez un résumé de ce que chaque étape du workflow a appelé, retourné ou refusé.

Serveur MCP hébergé

npx add-mcp 'https://api.outcomeci.com/v1/mcp'

S’installe dans Claude Code, Codex, Cursor et plus

Documentation

Décrivez le workflow. Construisez-le ensemble.

Connectez votre agent préféré à OutcomeCI et décrivez ce que vous souhaitez accomplir. Construisez les étapes, les outils et les approbations ensemble, puis laissez OutcomeCI exécuter le workflow.

draft

Lisez la demande et les dépôts. Proposez un plan dans le fil de discussion.

discuss

Travaillez sur les retours avec le demandeur jusqu'à ce qu'il approuve.

implement

Effectuez les modifications convenues dans les limites des autorisations du workflow.

announce

Ramenez le résultat dans la conversation où tout a commencé.

Construire avec votre agent

Créez un workflow qui transforme les demandes Slack en pull requests. Discutez du plan avec le demandeur et attendez l'approbation avant d'apporter des modifications.

  1. 01 draft Étape d'agent
  2. 02 discuss Approbation humaine
  3. 03 implement Étape d'agent
  4. 04 announce Étape d'agent

Examinez le workflow ensemble. OutcomeCI l'exécute lorsque le travail arrive.

Voir le workflow complet

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}

Explorer le format de workflow

Façonnez le plan. Puis approuvez-le.

Décidez où les personnes guident, examinent et approuvent. Donnez aux agents des autorisations claires pour chaque étape et maintenez les modifications dans les limites que vous avez définies.

  • Autorisations pour chaque étape

    Choisissez les opérations que chaque étape peut effectuer et les ressources auxquelles elle peut accéder. Les appels en dehors de ces autorisations sont refusés.
  • Revue de politique avant les modifications

    Ajoutez des règles telles qu'une seule branche et une seule PR. Un réviseur de politique vérifie les modifications proposées avant qu'elles ne soient envoyées.
  • Les identifiants restent dans le coffre

    OutcomeCI attache les identifiants aux appels API. L'agent travaille via les autorisations sans recevoir les jetons.

# product-engineering

OutcomeCI APP

Je vais ajouter un export CSV pour la page d'activité et inclure des tests.

Maya

Exportez uniquement les résultats filtrés et conservez l'ordre des colonnes existant.

OutcomeCI APP

Plan mis à jour : exporter les résultats filtrés dans l'ordre actuel des colonnes, avec des tests pour les deux. Prêt à continuer ?

Plan révisé prêt pour approbation

Jordan

Ça fonctionne. Allez-y.

Autorisations d'implémentation

Dépôt

acme/console

Autorisation

github.write

Politique

Une branche. Une PR. Pas de force-push.

Identifiants

Attachés par le courtier

Un environnement d'exécution tracé.

Chaque exécution laisse un enregistrement que vous pouvez inspecter, du premier appel d'outil au résultat final.

Voyez ce que chaque étape a appelé, ce qui est revenu et ce qui a été refusé, avec la raison associée. Suivez le travail jusqu'à son résultat.

Explorer l'exécution et la revue de politique

slack-to-pull-request

Terminé · 5 appels API · 1 refusé

01 github.read acme/console Confirmé

Lecture de la page d'activité et de ses tests existants. Le contenu du dépôt a été renvoyé à l'étape de brouillon.

02 slack.post #product-engineering / fil original Confirmé

Publication du plan d'export CSV révisé, incluant les résultats filtrés et l'ordre des colonnes existant. Le reçu du message identifie la conversation utilisée pour l'approbation.

03 github.write Proposition de force-push Refusé

La revue de politique a refusé le force-push proposé. La politique autorise une nouvelle branche et une PR, sans force-push. Cette demande n'a pas été envoyée à GitHub.

04 github.write acme/console / pull request #142 Confirmé

Ouverture d'une pull request depuis une nouvelle branche pour l'export CSV approuvé. GitHub a renvoyé le numéro et l'URL de la PR.

05 slack.post #product-engineering / fil original Confirmé

Publication du lien de la pull request et d'un résumé dans le fil d'origine. Slack a renvoyé le reçu du message.

Résultat renvoyé dans le fil Slack · Développer un appel pour inspecter

Gardez votre workflow. Changez votre agent ou modèle.

Conservez vos workflows dans OutcomeCI ou dans votre dépôt. Choisissez l'agent et le modèle pour chaque étape, et exécutez localement ou dans le cloud.

Votre agent

  • Codex
  • Claude Code
  • OpenCode

Définissez une valeur par défaut, remplacez une étape ou ajoutez un repli pour les limites d'utilisation.

Configurer vos agents

Vos modèles

  • OpenRouter
  • LiteLLM

Apportez l'accès aux modèles que vous avez déjà. Choisissez un modèle par workflow ou par étape sans lier votre orchestration à un seul fournisseur.

Choisir vos modèles

Votre environnement d'exécution

Local · Cloud OutcomeCI

Le même format de workflow et la même image d'exécuteur. Identifiants configurés pour chaque environnement.

Explorer l'exécution locale

Vous préférez commencer avec votre agent favori ?

Connectez-le à OutcomeCI avec MCP et construisez votre workflow ensemble.

URL du serveur MCP

https://api.outcomeci.com/v1/mcp

Connecter votre agent

Guides de configuration officiels : OpenCode ↗ Claude Code ↗ Codex ↗

Vous préférez commencer sur votre machine ?

Testez localement avec Docker et votre connexion d'agent. Aucun compte OutcomeCI requis.

$ pipx install outcomeci-cli

Suivre le guide de démarrage rapide

Un workflow n'est que le début.

Commencez par un événement, un calendrier ou une demande. Rassemblez les outils, les agents et les approbations dont chaque tâche a besoin.

Alerte → Investigation → Revue

Trier une alerte entrante

Partez d'un webhook entrant, enquêtez sur le problème et proposez un correctif pour examen avant d'apporter des modifications.

Explorer le workflow d'alerte

Demande → Recherche → Réponse

Répondre à une question sur le dépôt

Donnez à un agent un accès en lecture seule au code pertinent et ramenez une réponse à la personne qui a posé la question.

Construire un workflow en lecture seule

Calendrier → Résumé → Mise à jour

Préparer la mise à jour du matin

Rassemblez l'activité du dépôt, résumez ce qui a changé et partagez une mise à jour selon un calendrier de votre choix.

Commencer avec un workflow planifié

Commencer avec un événement Slack · Webhook · Email · Calendrier · CLI

Connecter vos outils Explorer les connecteurs open-source ↗

Questions fréquentes

OutcomeCI est-il uniquement pour les workflows de codage ?

Non. OutcomeCI est un framework d'orchestration pour les workflows d'agents. Définissez un déclencheur, des étapes, des outils et des approbations autour du travail que vous souhaitez accomplir. La démonstration de pull request n'est qu'un exemple ; les workflows peuvent également enquêter sur des questions, résumer l'activité et agir via des connecteurs pris en charge.

Quels agents et modèles puis-je utiliser ?

OutcomeCI prend en charge Codex, Claude Code et OpenCode. Choisissez un exécuteur et un modèle qu'il prend en charge dans votre workflow, remplacez l'agent pour une étape particulière ou configurez un repli pour les limites d'utilisation. Conservez vos workflows dans OutcomeCI ou dans votre dépôt.

Où mes workflows peuvent-ils s'exécuter ?

Exécutez des workflows sur les exécuteurs gérés du cloud OutcomeCI, ou testez-les localement avec Docker et votre propre connexion d'agent. Les deux utilisent la même image d'exécuteur et le même format de workflow. Les identifiants et les connexions d'agents sont configurés pour chaque environnement.

Qu'enregistre la trace d'exécution ?

Le journal de l'exécution enregistre les appels API, leurs résultats et les refus avec les raisons. Utilisez-le pour inspecter ce qu'un workflow a tenté et ce qui s'est passé. C'est un enregistrement de l'exécution des outils, pas une transcription du raisonnement privé d'un agent.

Que se passe-t-il si une exécution échoue ou si un agent atteint une limite ?

Ouvrez le journal d'exécution pour voir ce qui a échoué et inspectez les appels enregistrés avant de réessayer. Les exécutions cloud réessayent certaines pannes temporaires, comme une connexion d'agent occupée, jusqu'à cinq fois. Configurez un agent de repli pour les limites d'utilisation ou de débit. Pour les exécutions locales échouées, corrigez la cause et reprenez avec l'option de nouvelle tentative de la CLI. Les appels dont le résultat est incertain ne sont pas automatiquement rejoués.

Et si personne n'approuve le plan ?

Vous définissez la fenêtre d'approbation. Une étape d'approbation qui expire ignore les étapes restantes. Dans la démonstration, l'implémentation nécessite un plan approuvé ; si la discussion expire ou atteint sa limite de tours sans accord, l'implémentation est ignorée.

Comment les autorisations et les secrets sont-ils gérés ?

Chaque étape dispose d'autorisations explicites limitées aux opérations et aux arguments. Le courtier refuse les appels en dehors de ces autorisations et attache les identifiants du coffre aux appels autorisés. Une revue de politique facultative vérifie les modifications proposées par rapport à des règles en langage clair, et les workflows peuvent attendre une approbation humaine.

Quels outils et déclencheurs sont pris en charge ?

Les connecteurs GitHub et Slack sont disponibles aujourd'hui. Démarrez des workflows à partir de mentions et de messages directs Slack, de webhooks, d'e-mails, de planifications cron ou de la CLI. Les connecteurs sont open-source ; demandez des API supplémentaires via le dépôt des connecteurs.

Ai-je besoin d'un compte pour essayer localement ?

Non. Installez la CLI et testez les workflows localement avec Docker, votre connexion d'agent et les identifiants des outils que vous connectez. Créez un compte OutcomeCI pour exécuter des workflows sur des exécuteurs cloud gérés.