AWS a ouvert Kiro Crew. Il a gardé le harness.

Kiro Crew est-il open source ? Oui, réellement, et davantage que je ne m’y attendais. Est-ce que ce qui le rend utile est open source ? C’est une autre question, et la réponse est précisément là où se trouve la partie intéressante de ce lancement.

Le 4 août, AWS a publié Kiro Crew, un espace de travail agentique persistant qui maintient des agents de développement actifs entre les sessions, les plannings et les interfaces de messagerie, sous licence Apache 2.0. Le projet est né chez Amazon comme un projet parallèle appelé MeshClaw, s’est diffusé auprès de plus de 39 000 développeurs internes en moins de six mois et vit désormais dans un dépôt public avec un modèle de gouvernance ouvert. J’ai lu l’annonce, le dépôt et la licence, puis j’ai passé du temps à comparer ce qui se trouve réellement dans le dépôt avec ce dont le produit a encore besoin chez AWS pour fonctionner. La frontière est volontaire, et il vaut mieux la comprendre avant de construire d’un côté ou de l’autre.

Points clés - Kiro Crew est un espace de travail agentique persistant d’AWS, publié en open source sous Apache 2.0 le 4 août 2026. Il a commencé comme un projet parallèle interne à Amazon, MeshClaw, utilisé par plus de 39 000 développeurs avant sa sortie. - Ce qui est ouvert : le Gateway, avec sessions, mémoire, planification, approbations et politique de sécurité, le tableau de bord, la CLI, l’application de bureau, Apps et l’App SDK, les skills et toute la pile de sécurité. Vous pouvez tout lire, forker et auto-héberger. - Ce qui reste fermé : Kiro CLI, le moteur d’agents que Crew pilote via l’Agent Client Protocol, ainsi que la connexion Kiro, le routage des modèles et la facturation en crédits. Le fournisseur d’agents de Crew est fixé sur ACP et kiro-cli, donc chaque appel de modèle passe toujours par le produit commercial d’AWS. - Il s’agit d’un harness fournisseur partiellement ouvert, pas d’un runtime d’agents ouvert. Comparez avec TrueForge, qui a ouvert le harness lui-même sous licence MIT et traite n’importe quel modèle comme un endpoint parmi d’autres. - La conception reste utile. Un état auto-hébergé, une mémoire visible et un modèle de sécurité sérieux sont de vrais avantages. Il faut simplement être lucide sur la couche à laquelle on s’engage.

Ce qui s’est passé

Le 4 août 2026, AWS a publié l’annonce de Kiro Crew et ouvert le dépôt kirodotdev/KiroCrew sous Apache 2.0. La même semaine, SiliconANGLE et DevOps.com en ont parlé, et le dépôt comptait environ 3 400 étoiles et 400 forks lorsque je l’ai consulté. Les faits essentiels :

• Kiro Crew est un espace de travail persistant pour les agents de développement : tâches en plusieurs étapes exécutées sans surveillance, jobs récurrents planifiés, heartbeats qui surveillent une PR ou un déploiement jusqu’à ce qu’une intervention soit nécessaire, et sous-agents qui se répartissent le travail puis rendent compte.

• Il s’exécute là où vous le placez : application de bureau, installation en une ligne, image Docker sur GHCR ou hôte Linux distant que vous contrôlez. L’état, c’est-à-dire les sessions, la mémoire et les checkpoints, reste sur votre matériel sous ~/.kiro/crew, pas dans un plan de contrôle AWS.

• Le travail lui parvient via un tableau de bord web, une CLI, une application de bureau ou des interfaces de messagerie : Slack, Discord, Telegram, Teams, Webex, WeCom, WeChat et WhatsApp.

• Il est issu de MeshClaw, un projet parallèle interne à Amazon inspiré d’OpenClaw, qui, selon l’annonce, a atteint plus de 39 000 développeurs internes avec près de 500 contributeurs ayant livré près de 600 mises à jour avant la sortie publique.

• La gouvernance est publique : un comité directeur répertorié dans MAINTAINERS.md et des propositions déposées et débattues sous forme de pull requests. Pour l’instant, les mainteneurs sont des ingénieurs Kiro et AWS, avec l’intention déclarée d’ajouter des mainteneurs externes à mesure que des contributeurs de confiance émergent.

Kiro Crew est un espace de travail agentique persistant open source sous Apache 2.0, publié par AWS le 4 août 2026. Il exécute des tâches multi-étapes sans surveillance, des jobs planifiés, des heartbeats et des sous-agents, auto-hébergés sur le matériel de l’utilisateur, selon l’annonce d’AWS et le dépôt du projet.

Quelles couches sont ouvertes et lesquelles ne le sont pas

C’est la partie que la plupart des articles ont ignorée, alors je suis allé voir moi-même dans le dépôt. L’architecture comporte trois niveaux : les interfaces avec lesquelles vous interagissez, c’est-à-dire tableau de bord, desktop, CLI et messagerie ; le Gateway qui conserve l’état, avec sessions, mémoire, planification, approbations et politique de sécurité ; et les sessions d’agents qui exécutent réellement la boucle du modèle. Voici où passe la frontière de licence :

La ligne porteuse se trouve dans la documentation de configuration : agent.provider est fixé à acp, et Kiro Crew pilote kiro-cli via l’Agent Client Protocol. Chaque requête de modèle est gérée par kiro-cli sous votre compte Kiro et sa configuration de modèles. L’espace de travail, la mémoire, les plannings, la posture de sécurité : tout cela est à vous, forkable et vérifiable. Le moteur qui raisonne et la facturation qui le mesure : à AWS.

Le Gateway, les interfaces, les Apps et les couches de sécurité de Kiro Crew sont open source sous Apache 2.0 dans le dépôt KiroCrew, mais le moteur d’agents sous-jacent, kiro-cli, reste un produit AWS fermé. Le fournisseur d’agents de Crew est fixé sur ACP via kiro-cli, donc l’accès aux modèles, la connexion et la facturation en crédits restent sous contrôle d’AWS.

Pourquoi la frontière est exactement là

La lecture paresseuse serait de dire qu’AWS a ouvert Crew par bonne volonté, ou comme un piège. La lecture plus utile est que la frontière suit l’argent, et qu’elle le fait honnêtement.

Donner l’espace de travail, garder le moteur et le compteur. C’est le même compromis que beaucoup d’infrastructures open source raisonnables, et AWS l’explique clairement : l’annonce dit que Crew s’exécute sur Kiro CLI et lit directement votre configuration .kiro existante. Si vous vivez déjà dans Kiro, Crew est un cadeau. Vos fichiers de steering, skills et agents personnalisés sont repris, et vos agents gagnent persistance, planification et une douzaine d’interfaces de messagerie gratuitement. Les 39 000 utilisateurs internes sont la preuve que cette forme fonctionne à grande échelle, pas seulement une ligne marketing.

Mais regardez ce que cette ouverture apporte à AWS. Chaque installation de Crew est une installation de Kiro, car le premier lancement configure kiro-cli et la connexion par code d’appareil. Chaque tour d’agent est mesuré en crédits Kiro sur les modèles vers lesquels Kiro route les requêtes, et ce routage couvre Claude ainsi que les modèles ouverts chinois Qwen, DeepSeek, GLM et MiniMax sur Bedrock. Un utilisateur précoce a consommé 5 000 crédits en une semaine sur des projets personnels, ce qui montre ce qu’un espace d’agents toujours actifs fait à un forfait de modèles mesuré. La couche ouverte élargit l’entonnoir vers la couche fermée, et c’est dans la couche fermée que se trouve le chiffre d’affaires. Rien de cela n’est caché, et rien de cela n’est sinistre. Il faut simplement le voir clairement, car la même semaine a apporté une alternative entièrement ouverte qui a placé la frontière ailleurs.

Une autre chose dans la couche ouverte mérite d’être saluée. Le modèle de sécurité est appliqué à la frontière du runtime plutôt que dans les prompts : sandboxing au niveau de l’OS sous Linux et macOS, commandes refusées par défaut, masquage des identifiants et posture fail-closed sous Windows, où les sous-processus d’agents sont refusés plutôt qu’exécutés sans confinement, sauf si vous l’autorisez explicitement. Comme tout est dans le dépôt, vous pouvez vérifier chaque couche au lieu de faire confiance à une page vendeur. C’est l’argument le plus fort pour dire que la partie ouverte est réelle et pas théâtrale.

L’espace de travail ouvert de Kiro Crew canalise les utilisateurs vers le moteur Kiro fermé et facturé : chaque installation configure kiro-cli et la connexion Kiro, et chaque tour d’agent est débité en crédits Kiro. La pile de sécurité, avec sandbox OS, commandes refusées par défaut, masquage des identifiants et journaux d’audit, est réellement ouverte et auditable dans le dépôt.

Le contraste avec TrueForge

Deux semaines après Kiro Crew, TrueFoundry a publié TrueForge sous licence MIT, et le duo constitue une expérience naturelle très nette sur la quantité d’une pile d’agents qu’un fournisseur est prêt à céder.

TrueForge a ouvert le harness lui-même : la boucle autour du modèle, les sessions, le sandboxing, les approbations et la gestion du contexte. N’importe quel endpoint compatible OpenAI peut s’y brancher, de sorte que le modèle le moins cher capable de terminer la tâche peut gagner la charge, tandis que la couche commerciale se trouve en dessous sous la forme d’une passerelle facultative que vous pouvez refuser. Kiro Crew a ouvert tout ce qui entoure le harness : persistance, planification, interfaces et politique de sécurité. Le harness lui-même, kiro-cli, reste fermé, et le plan de modèles derrière lui est le produit.

Aucun des deux n’est malhonnête, mais ce sont des engagements différents avec des modes d’échec différents. Forkez TrueForge et vous conservez un runtime d’agents fonctionnel ; vous perdez la passerelle et le support de TrueFoundry. Forkez Kiro Crew et vous gardez un excellent espace de travail sans moteur à l’intérieur. Dès que kiro-cli modifie son protocole, ses prix ou son calendrier de retrait, votre fork hérite du problème. Si vous pesez le build versus buy pour votre propre pile d’agents, c’est la question à poser à tout produit partiellement ouvert : quelle couche cesse de fonctionner lorsque la feuille de route du fournisseur change ? J’ai fait le même constat au sujet de l’architecture agentique en général : la question intéressante est rarement le modèle, mais ce qui l’entoure, et qui possède cet habillage.

La note de bas de page de Hangzhou que je ne peux pas m’empêcher d’ajouter : le routage de Kiro traite déjà Qwen, DeepSeek, GLM et MiniMax comme des options de premier rang sur Bedrock, et Crew fournit des connecteurs WeCom et WeChat dès l’installation. Des modèles chinois et des surfaces de messagerie chinoises comme composants ordinaires de la pile d’un fournisseur américain. Noté, avec une certaine satisfaction, depuis la ville où la moitié de ces modèles sont fabriqués.

Que faire maintenant

Si vous évaluez Kiro Crew, trois étapes, dans cet ordre.

1. Aujourd’hui : lisez le dépôt avant d’installer quoi que ce soit. Commencez par la section architecture du README, GOVERNANCE.md et MAINTAINERS.md, puis les documents de sécurité. Tout l’intérêt de la couche ouverte est que vous pouvez la vérifier, alors vérifiez-la. L’installation tient sur une ligne, et le tableau de bord se lie à localhost par défaut.

2. Cette semaine : faites-le tourner sur une charge bornée et peu risquée : surveillance planifiée d’une PR, digest du matin, revue récurrente. Regardez ce qu’il fait via la vue Activity et le journal d’audit, et surveillez votre consommation de crédits. Les agents persistants dépensent de l’argent pendant votre sommeil. C’est le produit qui fonctionne comme prévu, et c’est aussi une question de budget.

3. Ce mois-ci : décidez à quelle couche vous vous engagez. Si vous êtes déjà une organisation Kiro, Crew est un oui facile. Si vous choisissez une pile depuis zéro, comparez cette frontière à un harness entièrement ouvert comme TrueForge, et réfléchissez aux compromis de l’auto-hébergement avant que les workflows de votre équipe ne se figent autour de l’une ou l’autre option. Si vous continuez, le support MCP de Crew permet d’emporter vos outils existants ; ma sélection de serveurs MCP à connecter constitue un point de départ raisonnable.

FAQ

Kiro Crew est-il open source ?

L’espace de travail l’est : le Gateway, le tableau de bord, l’application de bureau, la CLI, les Apps, les skills et toute la pile de sécurité sont sous Apache 2.0 dans le dépôt kirodotdev/KiroCrew, et vous pouvez tout auto-héberger sur votre propre matériel sans plan de contrôle AWS. Le moteur d’agents en dessous, kiro-cli, n’est pas open source, et Crew ne peut pas fonctionner sans lui. Donc "open source" décrit correctement le dépôt, mais reste incomplet pour décrire le produit.

Kiro Crew nécessite-t-il un compte AWS ?

Il nécessite une connexion Kiro, qui gère l’accès aux modèles et la facturation en crédits via kiro-cli. Pour une utilisation locale, vous n’avez rien à déployer dans un compte AWS ; l’espace de travail et son état restent sur votre machine. Si vous voulez une instance distante toujours active, kirocrew cloud launch peut en provisionner une sur EC2 dans votre propre compte AWS, mais un simple serveur Linux ou un home lab convient aussi.

En quoi Kiro Crew diffère-t-il du mode autonome de Kiro ?

Par la portée. Le mode autonome gère une tâche dans une session pendant que vous observez. Crew persiste entre les sessions et les redémarrages, exécute des travaux planifiés et réactifs que vous soyez en ligne ou non, orchestre des sous-agents en parallèle et conserve mémoire, leçons et skills d’une exécution à l’autre. C’est une nouvelle interface sur le même moteur Kiro, qui lit la même configuration .kiro.

Puis-je utiliser Kiro Crew avec un autre moteur d’agents ou fournisseur de modèles ?

Pas aujourd’hui. Le fournisseur d’agents est fixé sur ACP via kiro-cli, donc les modèles viennent de ce vers quoi votre compte Kiro route les requêtes, ce qui inclut actuellement Claude ainsi que des modèles ouverts comme Qwen, DeepSeek, GLM et MiniMax sur Bedrock. Le modèle de gouvernance est public et les mainteneurs disent que les contributions externes sont les bienvenues, donc un moteur interchangeable est concevable, mais ce n’est pas la conception livrée et je ne construirais pas un plan autour de cette hypothèse.

En bref

Kiro Crew est un bon projet open source construit autour d’un moteur commercial fermé, et AWS a été plus direct sur cet arrangement que la plupart des fournisseurs. La couche ouverte est réelle : état auto-hébergé, mémoire visible, modèle de sécurité auditable, gouvernance publique. La couche fermée est réelle aussi : le harness proprement dit, la connexion, le compteur. Si vous y allez en sachant exactement de quel côté de cette ligne se situe votre engagement, Crew mérite votre temps. Si vous avez besoin que la ligne soit ailleurs, le même mois vous a donné un harness sous licence MIT qui la place à cet endroit.

Si vous essayez de déterminer où la frontière ouverte devrait se situer dans votre propre pile d’agents, c’est une conversation que j’ai régulièrement avec mes clients. Contactez-moi.

Sources

• Kiro (AWS), "Introducing Kiro Crew": https://kiro.dev/blog/introducing-kiro-crew/ (publié 2026-08-04, consulté 2026-08-29)

• kirodotdev, dépôt KiroCrew (README, LICENSE, GOVERNANCE.md, documentation de sécurité) : https://github.com/kirodotdev/KiroCrew (consulté 2026-08-29)

• Kiro, page produit Kiro Crew (FAQ licence et fonctionnalités) : https://kiro.dev/crew/ (consulté 2026-08-29)

• SiliconANGLE, "AWS launches Kiro Crew, an autonomous agentic orchestrator for 24/7 code development": https://siliconangle.com/2026/08/04/aws-launches-kiro-crew-autonomous-agentic-orchestrator-24-7-code-development/ (publié 2026-08-04, consulté 2026-08-29)

• DevOps.com, "AWS Adds Agentic Workspace to Kiro AI Coding Tool": https://devops.com/aws-adds-agentic-workspace-to-kiro-ai-coding-tool/ (publié 2026-08-05, consulté 2026-08-29)

• Playing AWS, "Kiro Crew after one week (and more than 5000 credits)": https://www.playingaws.com/posts/what-is-kirocrew/ (publié 2026-08-08, consulté 2026-08-29)