Comment fonctionne Kiro

Kiro est un seul agent, disponible partout où vous travaillez. Fermez votre portable et votre session continue de s'exécuter dans le nuage. Consultez-la depuis votre téléphone. Reprenez-la dans l'IDE le lendemain matin. Les applications IDE, CLI, Web et Mobile sont différentes façons de dialoguer avec le même harnais d'agent unifié, donc lorsque vous configurez une règle de Steering, rédigez un agent personnalisé ou connectez un serveur MCP, vous configurez Kiro lui-même, pas une application particulière.

Cette seule idée organise tout le reste : les capacités existent au niveau de Kiro et sont documentées une seule fois dans Fonctionnalités, tandis que chaque section de surface couvre uniquement ce que cette surface ajoute par-dessus. Cette page présente comment les éléments s'assemblent. Pour l'histoire technique derrière l'architecture, lisez One agent, every surface sur le blogue Kiro.

Au centre se trouve le harnais d'agent unifié, qui gère tout ce qu'implique une exécution d'agent : orchestrer la conversation, exécuter les outils, gérer le contexte, évaluer les permissions et communiquer avec les fournisseurs de LLM. Chaque surface Kiro (l'IDE, la CLI, le Web et le Mobile) est une interface vers ce même harnais.

Le harnais est un processus autonome, pas une bibliothèque compilée dans chaque application. Il s'exécute en parallèle de votre code source, gère tout du côté agent, et le client gère la façon dont vous interagissez avec lui. Comme il s'agit d'un processus distinct, le même harnais peut démarrer sur votre portable ou dans un bac à sable dans le nuage, et il se comporte de façon identique dans les deux cas.

Comme le harnais est partagé, une capacité se comporte de la même façon partout où elle est disponible. Une règle de permission refuse les mêmes opérations dans la CLI que dans l'IDE. Un fichier de Steering façonne le comportement de l'agent de façon identique sur chaque surface. La compaction préserve les mêmes renseignements. Les surfaces diffèrent dans la façon de piloter l'agent, pas dans ce que l'agent peut faire. Lorsqu'une capacité n'a pas encore atteint une surface, la page de la fonctionnalité l'indique d'emblée dans un tableau de disponibilité.

Les clients communiquent avec le harnais par l'entremise de l'Agent Client Protocol (ACP) ouvert. Cela inclut les surfaces de Kiro elles-mêmes : les applications IDE, CLI, Web et Mobile parlent toutes ACP, étendu avec des méthodes propres à Kiro (sous l'espace de noms _kiro/ de la spec) pour des fonctionnalités comme le Steering en direct, les flux de travail de Specs, les invites de permission enrichies et le suivi de l'utilisation du contexte. Les clients locaux se connectent par stdio; le Web et le Mobile se connectent à un harnais en bac à sable par WebSocket. Même binaire, mêmes outils, même comportement sur les deux transports.

Lorsque vous envoyez une requête depuis n'importe quelle surface, le harnais exécute la même boucle :

1. Le contexte est assemblé. Le harnais rassemble votre requête, la conversation jusqu'à présent, vos fichiers de steering et tout ce que vous avez joint. Les hooks Prompt Submit s'exécutent ici et peuvent injecter leur propre contexte.
2. Le modèle planifie. La requête est envoyée à votre modèle sélectionné, ou Auto l'oriente vers le meilleur pour la tâche, et revient avec du texte, des appels d'outils, ou les deux.
3. Chaque appel d'outil est vérifié. Avant qu'un outil s'exécute, les règles de permission sont évaluées (le refus prime sur la demande, la demande prime sur l'autorisation), ainsi que les motifs kiroignore là où ils sont activés. Les hooks Pre Tool Use peuvent contrôler ou bloquer l'appel.
4. Les outils s'exécutent. Les outils intégrés lisent et modifient des fichiers, exécutent des commandes shell et effectuent des recherches sur le Web. Les serveurs MCP et les Powers étendent l'ensemble, et les sous-agents prennent en charge le travail délégué. Les hooks Post Tool Use réagissent aux résultats.
5. Les résultats reviennent en boucle. La sortie des outils revient au modèle, et la boucle se répète jusqu'à ce que la tâche soit terminée. Les hooks Agent Stop se déclenchent quand le tour se termine.
6. Le contexte reste géré. À mesure que la conversation approche la limite de contexte du modèle, la compaction résume l'historique plus ancien pour que la session puisse continuer.

Cette boucle explique pourquoi la section Fonctionnalités est organisée ainsi : chaque capacité est une étape de la boucle, pas un ajout dans une seule application. Une règle de permission que vous rédigez une fois contrôle l'étape 3 partout. Un fichier de Steering façonne l'étape 1 partout. C'est le sens concret d'« un seul harnais ».

Chaque capacité du harnais est documentée une seule fois, au niveau de Kiro :

Vous trouverez ces éléments sous Fonctionnalités dans la barre latérale (Models a sa propre section). Toutes les capacités n'ont pas encore atteint toutes les surfaces, donc chaque page commence par un tableau de disponibilité montrant précisément où elle fonctionne aujourd'hui. La direction est un seul harnais, partout.

La boucle est la même partout, mais l'ordinateur sur lequel elle s'exécute diffère selon la surface :

• L'IDE et la CLI exécutent le harnais sur votre machine par défaut. Les outils fonctionnent sur votre système de fichiers local, les commandes shell s'exécutent dans votre shell, et les builds utilisent votre chaîne d'outils et vos identifiants installés localement. Les deux peuvent aussi créer et se connecter à des sessions dans le nuage qui s'exécutent dans le même bac à sable géré que le Web utilise.
• Le Web et le Mobile exécutent le même harnais dans un bac à sable dans le nuage géré. Kiro clone votre dépôt connecté dans un environnement isolé, y travaille et livre les modifications en retour sous forme de pull requests. Rien ne s'exécute sur votre machine, et les sessions continuent de s'exécuter après la fermeture de votre portable. Le Mobile reprend les mêmes sessions dans le nuage, ce qui vous permet de commencer à travailler dans le navigateur et de vérifier depuis votre téléphone.

Une session dans le nuage appartient à votre compte plutôt qu'à une seule application, donc vous pouvez la démarrer sur une surface et la reprendre sur une autre. Consultez Sessions dans le nuage pour savoir comment chaque surface les crée et s'y connecte.

Même boucle, mêmes règles, même format de configuration. La différence réside dans l'endroit où le travail s'effectue et dans la façon dont les résultats vous parviennent.

Les sections de surface documentent l'expérience autour de l'agent : comment vous l'invoquez, voyez son travail et gardez le contrôle. Les surfaces ne sont pas non plus de simples enveloppes légères. Un client peut fournir ses propres outils à la place des outils intégrés du harnais lorsque sa plateforme fait mieux le travail; l'IDE, par exemple, utilise les propres API de l'éditeur pour les opérations sur les fichiers et ajoute par-dessus une analyse de code native à l'éditeur.

Si vous lisez une section de surface et vous demandez « mais comment fonctionne la fonctionnalité elle-même? », la réponse se trouve dans Fonctionnalités, un niveau plus haut.

La configuration suit le même modèle partagé. Ce que vous définissez une seule fois s'applique partout où le harnais s'exécute :

C'est pourquoi Kiro Web et Mobile peuvent reprendre les agents et le Steering de votre projet sans aucune configuration : ils lisent le même répertoire .kiro/ de votre dépôt que l'IDE et la CLI utilisent localement. Consultez Portées de configuration pour la référence complète.

• Apprenez une fois, utilisez partout. Le fichier permissions.yaml que vous rédigez pour la CLI est le même fichier que l'IDE consulte. Un Skill que vous ajoutez à votre projet fonctionne depuis chaque surface qui l'ouvre.
• Mises à niveau cohérentes. Les améliorations du harnais arrivent en un seul endroit, et les changements qui ne touchent pas le protocole client atteignent chaque surface sans mise à jour d'application nécessaire. Les Hooks globaux dans ~/.kiro/hooks/ et l'amélioration de la compaction ont tous les deux été livrés ainsi, arrivant sur toutes les surfaces en même temps.
• Cohérence à l'échelle de l'équipe. Le fait de commettre .kiro/ dans votre dépôt donne à tout le monde le même comportement d'agent, qu'ils préfèrent l'IDE, le terminal ou le navigateur.

• Portées de configuration pour savoir où réside chaque paramètre et comment les conflits se résolvent
• Agents personnalisés pour façonner les outils, les permissions et la requête de l'agent
• Permissions pour contrôler ce que l'agent peut faire
• Getting started pour installer Kiro sur la surface de votre choix