Un agent, toutes les surfaces : comment nous avons construit le harnais d'agent Kiro

Dès le début de la construction de Kiro, nous avons commencé à discuter de ce à quoi devrait ressembler le développement agentif tout au long de la journée d'un développeur. L'image à laquelle nous revenions sans cesse était celle où les sessions se déplacent entre votre ordinateur portable, un bac à sable dans le nuage et retour, sans friction. Vous fermez votre ordinateur portable à la fin de la journée et votre session Kiro continue de s'exécuter dans le nuage. Vous la consultez depuis votre téléphone pendant que vous prenez un café. Vous ouvrez l'IDE Kiro le lendemain matin et reprenez là où vous l'aviez laissée. Vous démarrez un projet dans Kiro sur le web, ajoutez du contexte dans l'IDE Kiro, continuez à travailler dans le CLI Kiro où vous exécutez déjà des tests et itérez dans le terminal, et vérifiez la progression depuis Slack. Le développement agentif devrait être une conversation continue sur toutes les surfaces où vous travaillez.

Plus tôt cette année, nous avons réalisé que notre architecture d'agent nous empêchait d'avancer vers cette vision. À l'époque, l'IDE Kiro, le CLI et les clients web exécutaient chacun leur propre agent conçu sur mesure, avec son propre format de session, son propre ensemble d'outils et son propre modèle de configuration. Pour pouvoir déplacer facilement les sessions entre environnements, il faut un agent unique qui fonctionne de la même manière, quel que soit le client utilisé ou l'endroit où il s'exécute. Dans notre architecture d'agent dédié par client, une session démarrée dans un client ne pouvait pas passer à un autre parce que les agents ne partageaient pas suffisamment de base commune. Cet article explique comment nous avons consolidé ces trois bases de code d'agent en un seul harnais d'agent Kiro (construit, bien sûr, à l'aide de Kiro lui-même) et les décisions d'architecture qui rendent notre vision désormais atteignable.

Lorsque nous avons commencé à construire Kiro, nous avons optimisé pour la vitesse et l'expérimentation. Nous avons encouragé chaque équipe de client à construire son propre harnais d'agent. Le harnais d'agent est la couche d'orchestration qui gère la boucle de l'agent, l'exécution des outils, la délégation aux sous-agents, la gestion de session, le chargement de la configuration et la communication avec le modèle. L'équipe de l'IDE a construit le sien en TypeScript pour s'adapter au modèle d'extension de Code OSS, l'équipe du CLI a construit le sien en Rust pour la performance, et l'équipe web a construit le sien en Python pour rester proche des dernières recherches sur les agents.

Avoir des harnais séparés a permis à chaque équipe de livrer indépendamment et d'itérer rapidement, mais cela signifiait aussi que chaque équipe faisait des choix différents. Le stockage des sessions fonctionnait différemment selon les clients. Les systèmes de permissions ont été conçus indépendamment et utilisaient une syntaxe incompatible : le CLI utilisait des allowedCommands/deniedCommands basés sur des expressions régulières, tandis que l'IDE utilisait la correspondance de préfixes pour trustedCommands et la correspondance de sous-chaînes pour sa liste de refus. Les stratégies de compaction divergeaient. Le partage de contexte entre sous-agents suivait des modèles différents. Les agents personnalisés fonctionnaient différemment dans chaque client. Les ensembles de fonctionnalités étaient aussi divisés : le développement piloté par Specs et les Powers n'existaient que dans l'IDE, tandis que le mode plan et l'intelligence du code n'existaient que dans le CLI.

Le coût d'implémentation s'est accumulé avec le temps. Chaque nouvelle capacité devait être construite et maintenue trois fois, ce qui aboutissait parfois à des comportements d'agent légèrement différents. Les bogues devaient être corrigés trois fois. Les utilisateurs vivaient des incohérences selon le client choisi. Notre vision de sessions se déplaçant entre clients et environnements de calcul était architecturalement impossible, car il n'existait aucun format de session partagé, aucun ensemble d'outils partagé et aucun modèle de configuration partagé. Nous avons envisagé de convenir de contrats de comportement d'agent entre les clients et de les implémenter dans chacun des trois harnais, afin de préserver l'indépendance et la vitesse individuelle de chaque équipe. Cependant, l'alignement des interfaces introduit aussi une charge de coordination qui croît avec chaque nouvelle fonctionnalité. Chaque nouvelle fonctionnalité nécessite un Spec, trois implémentations et une validation continue qu'elles se comportent de manière identique.

Le point d'inflexion est arrivé au moment où nous nous préparions à lancer publiquement Kiro sur le web. Plutôt que de lancer Kiro sur le web avec son propre agent séparé et de continuer à payer ce coût d'implémentation cumulatif, nous avons décidé de construire un seul harnais d'agent combinant le meilleur de ce que chaque équipe avait appris. Un harnais unique élimine la duplication entre équipes et nous permet d'investir tous nos efforts dans un seul endroit.

Une décision d'architecture clé que nous avons prise tôt a été de construire le harnais comme un processus serveur autonome, et non une bibliothèque compilée dans chaque client. Nous avons constaté, à partir de tentatives antérieures, que les bibliothèques partagées n'imposent pas une frontière suffisamment forte. Le code du client finit par appeler des méthodes internes qui n'étaient pas destinées à être exportées, ou superpose sa propre logique d'agent au-dessus de la bibliothèque. On revient alors à des implémentations divergentes. Un processus autonome rend la séparation réelle. Le harnais et les clients n'ont pas besoin de partager un langage ou un environnement d'exécution, chaque client peut donc rester dans la pile technologique qui convient à sa plateforme.

Maintenant, au lieu de trois paires client-agent étroitement couplées :

Nous avons une séparation nette entre les clients et un seul harnais d'agent :

Le harnais d'agent Kiro est un processus léger qui s'exécute aux côtés de votre base de code, démarre rapidement, et gère tout ce qui concerne l'agent. Le client gère la façon dont l'utilisateur interagit avec l'agent et comment il présente le travail de l'agent. La seule façon de traverser cette frontière est via l'interface de protocole définie. Comme c'est un processus autonome plutôt qu'une bibliothèque intégrée, il peut s'exécuter sur n'importe quel environnement de calcul. Le même harnais peut démarrer sur votre ordinateur portable ou s'exécuter dans une VM dans le nuage sans que le client s'en préoccupe.

L'interface bien définie entre le serveur et le client signifie que le code de l'agent évolue indépendamment des clients. Si un changement du harnais ne touche pas l'interface de protocole (par exemple, l'ajout d'un nouvel outil, l'amélioration de la planification, l'ajustement de la boucle de l'agent), il est livré immédiatement dans chaque client sans aucune modification côté client. Par exemple, nous avons récemment ajouté le rechargement en direct des agents personnalisés : vous pouvez modifier un fichier dans .kiro/agents/ en cours de session et le harnais le prend en compte immédiatement, en annonçant à nouveau les commandes disponibles au client. Cela n'a nécessité aucune modification côté client, car le type de notification pour les commandes disponibles existait déjà dans le protocole. Chaque client l'a obtenu gratuitement.

Le harnais n'est pas universel, en raison de la diversité des clients qu'il a été conçu pour prendre en charge. Différents clients ont des capacités différentes, et certaines opérations ont plus de sens implémentées au niveau du client en utilisant des fonctionnalités natives du client. Un client peut fournir ses propres outils et supprimer les outils intégrés afin d'utiliser ce qui convient à son format. Par exemple, l'IDE utilise les API de Code OSS pour la manipulation de fichiers et fournit ses propres outils de lecture et d'écriture de fichiers au lieu des outils intégrés du harnais qui opèrent directement sur le système de fichiers. Quand l'agent a besoin d'exécuter un de ces outils fournis par le client, il en notifie le client, qui exécute l'outil et renvoie le résultat.

Nous avons choisi le Agent Client Protocol (ACP) comme protocole définissant la frontière entre le client et le harnais. ACP est une spécification standardisée pour la communication agent-client qui a atteint la version 1.0 en juin 2026. Le protocole est pris en charge dans des IDE comme les IDE JetBrains, Xcode et Zed, ainsi que dans d'autres éditeurs, dont Obsidian, Emacs et Neovim. Nous avions déjà de l'expérience avec ACP grâce à son adoption dans le CLI Kiro plus tôt cette année, permettant aux utilisateurs d'interagir avec Kiro directement dans ces applications. Nous avons décidé d'utiliser ACP également pour le harnais unifié, pas seulement pour les éditeurs tiers, mais comme interface entre les propres clients de Kiro et notre propre agent. Deux propriétés d'ACP ont rendu cela possible : son extensibilité pour les méthodes personnalisées et sa flexibilité concernant les transports.

ACP prend officiellement en charge stdio comme transport, ce qui fonctionne bien pour les clients locaux où le harnais s'exécute comme processus enfant de l'éditeur ou du terminal. Pour les clients distants comme Kiro sur le web et l'application iOS, nous avions besoin d'un transport différent. Nous avons ajouté un transport personnalisé basé sur WebSocket afin que ces clients puissent se connecter à un harnais s'exécutant dans un bac à sable dans le nuage. Le binaire, les outils et le comportement de l'agent sont les mêmes, quel que soit le transport utilisé par un client.

Au-delà des transports, nous avons étendu l'ensemble de méthodes d'ACP en ce que nous appelons Kiro-ACP. L'ACP standard gère les fondamentaux (cycle de vie de session, diffusion de messages en continu et signalement des appels d'outils), mais les fonctionnalités de Kiro en nécessitaient davantage. Par exemple, nous avons ajouté le Steering en direct afin que les utilisateurs puissent envoyer un message qui sera injecté au prochain tour d'inférence pendant que l'agent travaille, orientant sa direction sans annuler ni attendre. ACP ne prend pas en charge la mise en file d'attente de messages, nous avons donc étendu ACP avec de nouvelles propriétés de méthodes et notifications pour permettre le Steering en direct. Nous avons également modélisé le flux de travail de développement piloté par Specs de Kiro comme un ensemble de méthodes dédiées, étendu l'approbation d'outils de base d'ACP en un système de permissions riche et multi-niveaux, et ajouté des notifications pour l'utilisation de la fenêtre de contexte et l'exécution des Hooks. En tout, Kiro-ACP ajoute plus de 20 méthodes appelables par l'agent, 15 méthodes appelables par le client et 20 types de notifications au-dessus du protocole de base. Le modèle d'extensibilité d'ACP garde cela propre : les méthodes personnalisées utilisent un préfixe de soulignement selon la spécification, et toutes les extensions de Kiro vivent sous l'espace de noms _kiro/. Nous pouvons étendre le protocole pour des fonctionnalités spécifiques à Kiro sans le forker.

Le résultat est que les clients tiers se connectent de la même façon que nos clients propriétaires. Tout client compatible ACP obtient l'agent complet avec ses outils, sous-agents, gestion de session et connectivité MCP. Les clients propriétaires (IDE, CLI, web, iOS) utilisent en plus les extensions Kiro-ACP pour des fonctionnalités comme le Steering en direct, les Specs, l'interface riche des permissions et le suivi de l'utilisation du contexte.

Le bénéfice immédiat d'un harnais unique est que des fonctionnalités auparavant réservées à un seul client sont maintenant disponibles partout, avec le même format de configuration et le même comportement.

Le développement piloté par Specs était auparavant réservé à l'IDE. Il fonctionne désormais dans le CLI (démarrez-en un avec /spec new) et dans Kiro sur le web. L'agent gère les interactions avec le grand modèle de langage et le raisonnement automatisé qui pilotent le flux de travail des Specs (génération des exigences, production d'une conception technique, découpage du travail en tâches), et chaque client le présente d'une manière adaptée à son format. L'IDE affiche les artefacts de Spec dans des panneaux côte à côte. Le CLI les rend dans le terminal. Kiro sur le web les affiche dans le navigateur avec révision en ligne et collaboration multi-utilisateur, permettant à une équipe d'itérer ensemble sur les Specs. L'agent parle ACP et le client décide comment présenter le résultat.

Les agents personnalisés utilisent le même format Markdown .kiro/agents/ sur toutes les surfaces. Vous définissez un agent avec une description, une requête système, une sélection d'outils basée sur des balises (des balises simples comme read, write et shell au lieu de noms d'outils individuels), des sous-agents accessibles, des définitions de serveurs MCP en ligne, et des règles de permission en ligne. Validez la configuration d'un agent personnalisé dans le contrôle de version et chaque membre de l'équipe l'obtient dans chaque client :

Les Hooks utilisent le même format .kiro/hooks/*.json avec les mêmes déclencheurs (SessionStart, PreToolUse, PostToolUse, FileCreate, FileSave) et le même comportement dans chaque client.

Au-delà de la disponibilité des fonctionnalités, le harnais unifié signifie que vous obtenez un comportement cohérent dans des domaines difficiles à bien maîtriser. La gestion du contexte, la compaction et le résumé fonctionnent tous de la même façon, quel que soit le client utilisé. Auparavant, chaque harnais avait sa propre stratégie de compaction, ce qui signifiait que les sessions pouvaient se comporter différemment en s'allongeant selon que vous étiez dans l'IDE, le CLI ou le client web. Maintenant, il n'y a qu'une seule implémentation, testée et améliorée en un seul endroit. Depuis le lancement du harnais unifié sur nos clients, nous avons déjà livré des requêtes de compaction améliorées dans le harnais pour une meilleure rétention du contexte. Nous avons également livré des améliorations de résilience et de performance en profondeur dans le harnais : une logique de nouvelle tentative améliorée pour les requêtes d'inférence de modèle, une évaluation des permissions plus rapide et des connexions aux serveurs MCP plus résilientes. Chaque client bénéficie de ces changements. Le résultat est une qualité et une fiabilité cohérentes, quelle que soit la surface que vous préférez.

Avant le harnais unifié, chaque client avait son propre système de permissions avec une syntaxe différente, une sémantique différente et des emplacements de configuration différents. Le CLI utilisait allowedCommands/deniedCommands avec des motifs d'expressions régulières. L'IDE utilisait trustedCommands avec correspondance de préfixes et une commandDenylist séparée avec correspondance de sous-chaînes. Dans les deux clients, les permissions étaient définies par outil : une seule intention comme « refuser les lectures de .env » devait être configurée séparément pour chaque outil pouvant lire des fichiers (read, glob, grep, intelligence du code). En manquer un et l'agent pouvait toujours accéder au fichier via un autre outil. Les utilisateurs faisaient face à un mauvais compromis entre appuyer sur « y » à chaque invocation d'outil ou tout autoriser, sans juste milieu utile. Nous voulions un modèle de permissions capable d'exprimer l'intention au niveau des capacités et de réduire la fatigue d'acceptation grâce à un consentement persistant et composable.

Il existe maintenant un modèle de permissions unique basé sur les capacités, soutenu par Cedar, un langage de politique formellement vérifié. Une seule règle peut cibler une classe entière d'opérations sur tous les outils :

Les capacités regroupent les outils selon leur fonction : fs_read, fs_write, shell, web_fetch, mcp, subagent, et d'autres. Un refus sur fs_read bloque tout outil qui lit des fichiers (read_file, grep_search, file_search, et tout futur outil de lecture) sans avoir à les énumérer individuellement.

Les politiques se composent sur plusieurs niveaux et se fusionnent selon une sémantique où le refus a toujours priorité. Kiro lui-même applique des invariants de sécurité immuables (par exemple, l'agent ne peut pas modifier ses propres fichiers de permissions). Les administrateurs d'entreprise peuvent imposer des restrictions via MDM. Les utilisateurs configurent leurs propres règles au niveau utilisateur ou espace de travail. Les profils d'agent peuvent déclarer des permissions adaptées à leur rôle. Les décisions au niveau de la session s'accumulent au fil du travail. Aucune configuration préalable n'est requise. La politique se construit de manière organique à mesure que vous prenez des décisions de consentement, et vous pouvez les rendre persistantes au niveau qui convient.

Les retombées de notre nouvelle architecture de harnais d'agent se manifestent déjà. Depuis que tous les clients sont passés au harnais unifié, nous avons livré plusieurs fonctionnalités à travers les clients qui n'ont nécessité aucune modification côté client, dont les Hooks globaux et les préréglages de politique. Les Hooks globaux vous permettent de définir des Hooks une seule fois dans ~/.kiro/hooks/ qui se déclenchent automatiquement dans chaque espace de travail, afin que les comportements transversaux comme le linting à l'enregistrement ou les vérifications de sécurité avant les commits n'aient plus besoin d'être dupliqués par projet. Les préréglages de politique sont des ensembles de règles nommés et composables, comme edit-workspace et dev-shell, qui réduisent la fatigue liée aux requêtes pour les flux de travail courants. Lorsque vous ajoutez des préréglages de politique à vos permissions (comme policies: [dev-shell, edit-workspace, read-all]), le moteur de politique du harnais les développe en règles individuelles au moment du chargement. Les deux fonctionnalités ont été livrées à tous les clients avec une seule mise à jour du harnais.

La vision décrite au début de cet article nécessite certaines capacités d'agent que nous devons encore construire, comme l'empaquetage de session pour déplacer des sessions entre environnements et la capacité de contrôler à la fois les sessions locales et dans le nuage depuis n'importe quel client. Le harnais unifié signifie que nous n'avons besoin de construire chaque nouvelle capacité qu'une seule fois. Dans de nombreux cas, comme pour les Hooks globaux et les préréglages de politique, nous pouvons les livrer à tous les clients sans aucune modification côté client. Certaines fonctionnalités nécessitent un travail côté client en plus d'une nouvelle capacité d'agent. Le harnais unifié n'a pas éliminé entièrement le travail côté client, et nous ne le voulions pas non plus. Un terminal, un IDE de bureau, un navigateur et un téléphone ont des modèles d'interaction différents, et nous voulons que chaque surface soit ressentie comme native à son format plutôt que d'offrir une expérience universelle. Avec la nouvelle architecture de harnais d'agent, la logique de l'agent est la même sur tous les clients et chaque équipe de client peut se concentrer sur la meilleure façon d'interagir avec elle.

Pour vous, en tant qu'utilisateur de Kiro, la nouvelle architecture de harnais d'agent signifie que les nouvelles capacités arrivent plus rapidement, se comportent de manière cohérente et fonctionnent avec la même configuration, quelle que soit la surface que vous préférez.

Le nouveau harnais d'agent Kiro est déployé sur les quatre clients Kiro, vous pouvez donc l'essayer dès aujourd'hui :

• Kiro IDE 1.0 apporte des permissions basées sur les capacités, des agents personnalisés avec outils basés sur des balises et MCP en ligne, un mode de focus d'agent pour diriger des sessions parallèles, des onglets de clavardage détachables, et l'exportation de session. Consultez la documentation de l'IDE 1.0 et comment migrer.
• Kiro CLI v3 (accès anticipé) exécute le même harnais unifié dans votre terminal avec le développement piloté par Specs, permissions.yaml, des Hooks améliorés et le nouveau format de configuration d'agent. Essayez-le avec kiro-cli --v3. Consultez la documentation du CLI v3 et comment migrer.
• Kiro sur le web (aperçu) exécute le harnais dans des bacs à sable dans le nuage pour un développement autonome avec des Specs dans le navigateur, des sessions multi-dépôts, et l'intégration GitHub et GitLab. Se connecter / s'inscrire.
• Kiro pour iOS (aperçu) se connecte aux mêmes sessions dans le nuage que Kiro sur le web depuis votre téléphone, afin que vous puissiez lancer un travail autonome, réviser les diffs et approuver les changements sans ouvrir votre ordinateur portable. Demander un accès anticipé.