Présentation des workflows Kiro

Aujourd'hui, nous présentons les workflows Kiro, qui vous permettent de mener des tâches complexes du début à la fin avec plusieurs agents et moins de supervision. Nous avons construit Kiro lui-même avec les workflows, y compris la nouvelle configuration cloud, les sessions cloud et la majeure partie de l'expérience des workflows.

Avant les workflows, nous demandions à un agent de mettre en œuvre un changement, puis nous revenions avec « faites maintenant une revue de code de ces changements » et, plus tard, « traitez les points soulevés par la revue de code ». Nous passons une grande partie de la session à superviser, à relancer l'agent lorsqu'il saute une étape et à lui rappeler des décisions antérieures. Au sein d'une session, le modèle contrôle le séquencement, mais l'attention d'un modèle est limitée. Tout ce sur quoi nous nous sommes entendus se trouve dans la même fenêtre de contexte qui se remplit de sorties d'outils et de contenus de fichiers, alors nous intervenons aussi lorsqu'il oublie ce qu'il reste à faire. Nous contournons cela en répartissant le travail sur des sessions distinctes et en conservant le plan dans un fichier qui persiste d'une session à l'autre, mais nous devons tout de même nous souvenir de ce que fait chaque session et transmettre les résultats entre elles. Ces workflows manuels peuvent produire de meilleurs résultats, mais leur mise en place prend du temps, et une fois que nous avons un processus qui fonctionne, nous voulons pointer vers l'exécution et dire « refais la même chose » sans le reconstruire à la main.

Les workflows Kiro règlent ce problème. Avec les workflows, le modèle définit quels agents font le travail et dans quel ordre, tandis que le moteur d'exécution de Kiro exécute ce plan pour que chaque étape se déroule au bon moment, sans rappels. Les workflows sont des graphes composés d'étapes d'agents, de séquences, de boucles et de branches parallèles, dans un format que les humains et les agents peuvent lire et créer. Chaque étape s'exécute dans sa propre session avec un contexte neuf, de sorte qu'un réviseur, par exemple, évalue le travail sans hériter du raisonnement du programmeur. Kiro génère un workflow adapté à la tâche en cours, et vous pouvez l'enregistrer comme recette pour le réutiliser ou rédiger le vôtre.

Comme les workflows s'exécutent en arrière-plan, vous pouvez continuer à travailler avec Kiro dans la conversation principale pendant que le travail délégué progresse. Les sessions des étapes du workflow demeurent accessibles pour que vous puissiez les mettre en pause, les reprendre ou les orienter pendant une exécution, et y revenir avec des questions de suivi par la suite. Déléguer ne serait-ce qu'une petite investigation garde ses sorties d'outils et son raisonnement détaillé hors de la conversation principale, ce qui préserve le contexte pour la suite du travail.

Nous avons utilisé des workflows pour construire la majeure partie du moteur d'exécution des workflows lui-même ainsi que l'intégration complète de Kiro Web, en commençant dès que le moteur d'exécution a été fonctionnel. Il s'agit d'un travail full-stack couvrant le frontend, l'API et les services internes, ainsi que le harnais d'agent de Kiro, des workflows distincts prenant en charge chaque partie en parallèle.

Les workflows de mise en œuvre utilisaient des worktrees Git distincts pour garder leurs changements isolés. Lorsqu'un agent trouvait un problème entre des composants, la session principale le relayait aux agents de workflow concernés afin qu'ils puissent se corriger. Nos fichiers Steering exigent des tests automatisés à l'aide de la CLI agent-browser pour exercer l'interface web et prendre des captures d'écran à des fins de validation.

Les agents poussaient leurs changements et ouvraient des pull requests selon notre style de description préféré, puis traitaient les points soulevés par les revues en boucles, en mettant à jour les pull requests. Ils rebasaient aussi des branches et résolvaient les conflits de fusion à mesure que des changements connexes arrivaient, en nous consultant sur les changements qui affecteraient la conception, élargiraient la portée ou modifieraient l'expérience utilisateur.

Nos agents gèrent souvent des dizaines de workflows par session dans Kiro, et un workflow typique exécute de cinq à dix étapes avec des agents personnalisés. Ces étapes comprennent des revues de code multimodèles et des corrections automatiques en boucles. Certaines sessions se poursuivent pendant des semaines, accumulant du contexte sur nos décisions à mesure que le travail évolue à travers les fonctionnalités et les améliorations. Dans toute l'équipe, les workflows s'exécutent presque 24 h sur 24, 7 jours sur 7.

Les workflows changent notre façon de travailler. Davantage de travail s'exécute en parallèle au sein de chaque session, les agents explorant en arrière-plan et développant des fonctionnalités à travers plusieurs pull requests. Les tâches deviennent plus asynchrones, et les agents travaillent plus longtemps sans que nous les relancions toutes les 10 minutes pour avancer. Kiro nous apporte les demandes qui nécessitent notre intervention, et nous passons plus de temps sur les décisions de conception et sur ce qu'il faut construire ensuite.

Voici un court exemple de workflow qui planifie un changement, répète la mise en œuvre suivie de revues parallèles jusqu'à l'approbation, puis ouvre une pull request en brouillon. Nous pouvons le représenter sous forme de graphe.

La recette ci-dessous décrit le même workflow.

Chaque step exécute une session d'agent indépendante. Nous définissons les dépendances en plaçant les étapes après le travail dont elles ont besoin et en référençant ses sorties au moyen des variables {{...}}, sans arêtes de graphe distinctes à maintenir. Un nœud parallel exécute des étapes indépendantes ensemble, tandis que repeat boucle sur des étapes avec une condition d'arrêt, comme l'approbation d'une revue. La façon la plus simple de créer un workflow est de le demander à Kiro.

Kiro génère les recettes en JSON, mais YAML est aussi pris en charge.

Kiro décompose la tâche que vous décrivez dans votre session, de sorte que vous n'avez pas besoin de rédiger une recette. Vous pouvez préciser comment le travail doit être organisé, y compris les agents personnalisés, les modèles préférés et les niveaux d'effort de réflexion.

Kiro peut adapter un workflow pendant son exécution, en fonction de ce que ses agents découvrent. Par exemple, un planificateur peut diviser la mise en œuvre en tâches indépendantes et les déléguer à des agents de programmation travaillant en parallèle. Les changements prennent effet entre les étapes, laissant intact le travail terminé et inchangée l'étape active.

Pour un exemple plus poussé, la recette intégrée feature-pipeline coordonne des agents pour recueillir les exigences, concevoir et réviser une solution, planifier la mise en œuvre et écrire le code. Des réviseurs de code indépendants s'exécutent ensuite en parallèle.

Dans l'arbre ci-dessous, les boucles de conception et de code autorisent chacune jusqu'à trois tentatives pour atteindre l'approbation, puis arrêtent l'exécution si elle n'est toujours pas approuvée. La validation finale compare le résultat aux exigences d'origine.

Cet exemple est lancé depuis une session utilisant Claude Opus 5 avec un effort Élevé. Nous avons personnalisé les agents de conception et de revue pour utiliser Très élevé. Seuls les remplacements de modèle et d'effort sont affichés ci-dessous; les paramètres omis utilisent les valeurs par défaut de la session.

• NœudAgentModèleEffort de réflexion

• Nœud

  setup

  Agent

  wf-coder

  Effort de réflexion

  Faible

• Nœud

  requirements

  Agent

  wf-design

  Effort de réflexion

  Très élevé

• repeat design-loop

  Max. 3 itérations; arrêt sur APPROVED dans design-review.json; abandon sinon.

  • Nœud

    design-draft

    Agent

    wf-design

    Effort de réflexion

    Très élevé

  • Nœud

    design-review

    Agent

    wf-design-reviewer

    Effort de réflexion

    Très élevé

• Nœud

  plan

  Agent

  wf-planner

• repeat code-loop

  Max. 3 itérations; arrêt sur APPROVED dans code-review.json; abandon sinon.

  • Nœud

    implement

    Agent

    wf-coder

  • parallel code-reviews

    Exécute les deux revues en parallèle; attend les deux.

    • Nœud

      review-claude

      Agent

      semantic_reviewer

      Modèle

      claude-opus-5.5

      Effort de réflexion

      Très élevé

    • Nœud

      review-gpt

      Agent

      semantic_reviewer

      Modèle

      gpt-5.6-sol

      Effort de réflexion

      Très élevé

  • Nœud

    code-aggregate

    Agent

    wf-review-aggregator

• Nœud

  validate

  Agent

  wf-coder

Nous avons exécuté des milliers de workflows en construisant Kiro, et il est livré avec des recettes intégrées. Parmi elles, investigate et publish-pr sont deux que nous utilisons nous-mêmes chaque jour. investigate exécute en arrière-plan une investigation en lecture seule menée par un seul agent, puis fait un compte rendu, ce qui aide à limiter l'utilisation du contexte dans nos sessions. La recette publish-pr ouvre une pull request et la suit jusqu'à la fusion, en réessayant les vérifications CI en échec et en traitant les retours de revue qu'elle peut résoudre en toute sécurité. Elle vous consulte avant de modifier la conception, d'élargir la portée de la pull request ou de modifier l'expérience utilisateur. Ces recettes sont des points de départ. Vous pouvez en exécuter une telle quelle, décrire la tâche et laisser Kiro structurer le workflow, ou rédiger la vôtre.

Les étapes d'un workflow envoient des messages à la session principale pour signaler leur progression, indiquer une réussite ou un échec, ou demander une décision qu'elles ne peuvent pas prendre seules. Ces messages arrivent dans la conversation que vous avez déjà avec Kiro, de sorte que vous suivez le travail depuis un seul endroit au lieu d'ouvrir la session de chaque étape pour en vérifier l'état.

La messagerie fonctionne aussi dans l'autre sens. La session principale peut envoyer un message à l'agent qui exécute une étape pour relayer une décision que vous avez prise dans le clavardage. Lorsque la réponse à la question d'une étape se trouve déjà dans votre conversation, la session principale répond en votre nom, de sorte que l'étape se poursuit et que vous n'entendez parler que des questions qui vous concernent. Cela permet aux workflows de s'exécuter de façon plus autonome pendant que vous dirigez le travail depuis la conversation principale.

Les workflows sont maintenant offerts dans Kiro IDE, CLI et Web, avec un seul moteur d'exécution sous les trois, de sorte qu'une recette se comporte de la même façon peu importe où vous la lancez.

Les workflows sont lancés en option et doivent d'abord être activés dans les paramètres.

Vous pouvez stocker vos recettes préférées dans la configuration cloud de Kiro Web pour les réutiliser d'un projet et d'un appareil à l'autre. Les workflows s'exécutent aussi dans les sessions cloud depuis Kiro CLI et IDE. Pour activer les workflows dans les sessions cloud et gérer les workflows enregistrés, utilisez la page de configuration des workflows.

Les workflows utilisent le même modèle de crédits Kiro que le reste du travail des agents. L'utilisation des crédits dépend du travail des agents qu'ils exécutent, de sorte que des workflows plus complexes peuvent utiliser plus de crédits. Sans instructions précises, Kiro crée un workflow en fonction de ce qu'il estime nécessaire pour la tâche. Votre requête ou vos fichiers Steering guident la façon dont Kiro divise le travail et l'ampleur de la revue qu'il effectue.

Consultez la documentation des Workflows pour de l'information plus détaillée.

Dites-nous ce que vous construisez avec les workflows!