Au cœur du prototype se trouve une boucle d’agent continue, limitée à un dépôt GitHub. Le système écoute les demandes autorisées, les transforme en tâches et les exécute dans des sessions d’agent éphémères, chacune disposant de son propre répertoire de travail. Ces sessions peuvent modifier le code, lancer des tests et produire des pull requests. La conception associe délibérément le périmètre opérationnel de l’agent à celui du dépôt afin de limiter les dégâts potentiels, tandis que le panneau web centralise la visibilité : les humains ne sont avertis que lorsque les règles ou les seuils de confiance exigent leur intervention.

Le prototype formalise des règles explicites de sollicitation : un agent ne peut agir que si une personne ou une règle d’équipe l’y autorise. DeepSeek décrit un modèle d’autorisation et un flux de travail dans le panneau, qui permettent aux opérateurs de définir quand l’agent peut fonctionner de manière autonome et quand il doit demander une intervention. Il s’agit d’un compromis pragmatique : une autonomie totale risque de mobiliser l’attention de l’équipe pour des actions de faible valeur ; à l’inverse, multiplier les approbations va à l’encontre de l’objectif d’une automatisation peu sollicitante. Le dépôt constitue une référence utile pour intégrer des contrôles de règles au cycle de vie des agents.

Le modèle de session de dsh-superagent isole chaque tâche dans son propre répertoire et son propre environnement d’exécution. Cela réduit les fuites d’état entre les tâches et facilite la reproduction ou l’abandon des sessions qui échouent. Pour les équipes qui l’implémentent, cette approche simplifie l’audit, le retour arrière et le débogage : chaque session dispose d’une trace distincte et d’un ensemble de livrables qui lui sont propres. Le prototype comprend des outils de configuration, des instructions et des exemples de compétences montrant comment regrouper les capacités d’un agent. DeepSeek avertit toutefois que ces pratiques sont expérimentales et doivent être adaptées avant toute mise en production.

Un choix essentiel en matière d’expérience utilisateur concerne la façon dont les agents communiquent. Le panneau web de dsh-superagent regroupe les éléments nécessitant une action — propositions de fusion, échecs de tests, questions de conception ambiguës — afin que les humains ne voient que ce qui demande leur attention. Cette conception repose sur un principe : les agents ne doivent pas diffuser chaque étape de leur travail. Pour les équipes produit, le panneau illustre l’importance du rapport signal-bruit : privilégier un contexte exploitable, afficher les différences et les résultats des tests, et fournir un lien vers l’historique exact de la session pour permettre un examen ou une intervention rapide.

DeepSeek qualifie explicitement ce dépôt de projet de recherche. Parmi ses principales limites : des pratiques d’ingénierie inégales, des bogues potentiels et une mise en œuvre partielle des concepts présentés dans l’article de recherche. Des lacunes de gouvernance restent également à combler avant une mise en production : gestion des identifiants, limitation du débit, contrôles de sécurité des modifications de code et engagements de niveau de service clairs pour l’examen humain. Pour une adoption commerciale, les équipes devraient considérer dsh-superagent comme une architecture de référence : en extraire les idées, renforcer l’exécution et mettre en place des contrôles robustes avant de lui confier des bases de code critiques.