Managed Agent Runs : des agents autonomes qui travaillent sur votre architecture pendant que vous dormez

Il y a deux semaines, nous avons lancé Agent Hub avec les guardrails de conformité — des règles qui dictent aux agents IA ce qu'ils peuvent ou ne peuvent pas faire. C'était la couche défensive. Aujourd'hui, nous ajoutons la couche offensive.

Les Managed Agent Runs vous permettent de dispatcher des agents IA autonomes directement depuis Archyl. Donnez-leur une tâche, connectez-les à vos outils, définissez un planning, et laissez-les travailler. Ils clonent votre repository, lisent votre architecture, appellent des services externes, et rendent compte de tout ce qu'ils ont fait — chaque appel d'outil, chaque décision, chaque token consommé.

Ce n'est pas du "chat avec votre architecture." C'est un agent qui fait du vrai travail, de manière autonome, sur votre codebase.

Pourquoi les Managed Runs ?

Le schéma que nous observions constamment était le suivant : les équipes mettaient en place des règles de conformité, généraient leur fichier CLAUDE.md, puis lançaient manuellement des agents dans leur terminal. Copier le contexte, le coller dans Claude Code, exécuter la tâche, vérifier le résultat. À chaque fois.

La pièce manquante, c'était l'automatisation. Vous ne devriez pas avoir à surveiller un agent qui effectue une tâche de routine. Vérifier les dépendances obsolètes chaque lundi matin ? Ça devrait être un planning. Relire les PRs ouvertes par rapport aux règles architecturales après chaque merge ? Ça devrait être automatique. Générer un rapport hebdomadaire de dérive architecturale ? Configurez-le et oubliez-le.

Les Managed Runs ferment cette boucle. Définissez la tâche, choisissez un planning, et Archyl s'occupe du reste — clonage, injection de contexte, exécution et monitoring.

Anatomie d'une exécution

Chaque Managed Run suit le même cycle de vie :

Clonage — L'agent clone le repository de votre projet dans un workspace isolé. Copie propre, aucune contamination des exécutions précédentes.
Injection de contexte — Avant que l'agent n'écrive une seule ligne de code, il reçoit l'intégralité de votre contexte architectural : modèle C4, ADRs, règles de conformité, stack technique, contrats d'API. Les mêmes données get_agent_context qui alimentent les guardrails, injectées automatiquement.
Exécution — L'agent travaille sur votre tâche. Il peut lire des fichiers, écrire du code, appeler des outils externes et prendre des décisions. Chaque action est enregistrée comme un événement dans un flux en temps réel.
Reporting — Lorsque l'exécution se termine (ou atteint la limite d'itérations), vous obtenez une trace complète : chaque appel d'outil avec ses entrées et sorties, des badges de statut, le nombre de tokens et le temps écoulé.

La page de détail d'une exécution affiche tout. Les appels d'outils sont des cartes dépliables avec du JSON coloré syntaxiquement. Chaque carte indique de quel connecteur provient l'outil — "github" pour les appels à l'API GitHub, "archyl" pour les requêtes architecturales, "linear" pour le suivi des issues. Vous pouvez tracer exactement ce que l'agent a fait et pourquoi.

Connecteurs : branchez n'importe quel service MCP

C'est là que ça devient intéressant. Les Managed Runs ne communiquent pas uniquement avec Archyl. Ils peuvent communiquer avec tout ce qui parle MCP (Model Context Protocol).

Les connecteurs vous permettent d'attacher des services externes à vos exécutions d'agents. Par défaut, nous supportons :

GitHub — Lire les PRs, vérifier le statut CI, lister les issues, relire le code
GitLab — Les mêmes capacités pour les projets hébergés sur GitLab
Linear — Lire et mettre à jour les issues, suivre l'avancement des sprints
Slack — Poster des messages, lire les channels, notifier les équipes
Tout serveur MCP — S'il expose des outils MCP, vous pouvez le connecter

Configurer un connecteur prend trente secondes. Donnez-lui un nom, collez l'URL du serveur, ajoutez des headers d'authentification si nécessaire, et Archyl sondera le serveur pour découvrir les outils disponibles. Vous verrez chaque outil exposé par le connecteur avant de sauvegarder.

Lorsque vous créez une exécution ou un planning, vous choisissez quels connecteurs attacher. L'agent a accès à tous les outils de tous les connecteurs attachés, espacés par nom de connecteur. Un outil GitHub apparaît sous la forme github__list_pull_requests. Un outil Linear apparaît sous la forme linear__get_issue. Aucune collision, aucune ambiguïté.

Ce nommage par espace de noms est important. Quand vous regardez le flux d'événements d'une exécution, chaque appel d'outil affiche sa source. Vous pouvez immédiatement savoir si l'agent interrogeait votre modèle d'architecture, lisait une PR GitHub ou postait sur Slack. Visibilité totale sur ce que l'agent a touché et où.

Planifications : automatisation basée sur cron

Certaines tâches ne devraient pas attendre qu'un humain appuie sur "Run." Les planifications vous permettent de définir des exécutions d'agents récurrentes avec des expressions cron standard.

Quelques exemples de ce que les équipes font déjà :

Revue architecturale hebdomadaire — Chaque lundi à 9h, un agent vérifie la codebase pour détecter les dérives architecturales. Il compare la structure réelle du code avec le modèle C4, signale les nouvelles dépendances non documentées et identifie les composants qui ont dépassé leur périmètre initial.

Vérification de conformité des PRs — Après chaque merge sur main, un agent relit le diff par rapport aux règles de conformité. Il détecte les patterns qui ont échappé à la CI — pas des erreurs de syntaxe, mais des violations architecturales qui n'ont de sens que dans le contexte du système complet.

Audit de dépendances — Chaque mercredi, un agent scanne l'arbre de dépendances à la recherche de vulnérabilités connues, de packages dépréciés et d'incohérences de versions entre les services. Il produit un résumé avec des niveaux de sévérité et des mises à jour suggérées.

Synchronisation de la documentation — Chaque vendredi après-midi, un agent compare la codebase actuelle avec la documentation du projet. Endpoints manquants, descriptions obsolètes, nouveaux services sans documentation — il les signale tous.

Chaque planification affiche son expression cron, la prochaine exécution, la dernière exécution et le statut actif/en pause. Vous pouvez mettre en pause une planification sans la supprimer, la déclencher manuellement en dehors de sa cadence normale, ou modifier le texte de la tâche et le timing à tout moment.

La page de détail d'une exécution

Nous avons passé beaucoup de temps sur l'expérience de monitoring, car la visibilité est primordiale lorsque vous laissez un agent travailler de manière autonome.

La page de détail d'une exécution vous donne :

Statut en un coup d'œil — En cours, terminé, échoué ou annulé. Badge coloré, visible immédiatement.
Utilisation des tokens — Tokens en entrée et en sortie, pour suivre les coûts par exécution.
Temps écoulé — Combien de temps l'agent a travaillé, mis à jour en temps réel pendant l'exécution.
ID d'exécution — Pour la traçabilité et le debug.
Flux d'événements en direct — Chaque action de l'agent apparaît comme une carte dépliable. Les appels d'outils montrent la source du connecteur, le nom de l'outil, les paramètres d'entrée et la sortie. Les messages montrent le raisonnement de l'agent. Les erreurs sont mises en évidence.

Le flux est conçu pour être parcouru rapidement. Les lignes repliées affichent le type d'événement et un résumé d'une ligne. Survolez pour voir le badge du connecteur et dépliez pour les détails complets. Quand quelque chose se passe mal, vous ne fouillez pas dans des logs — vous parcourez une timeline structurée de ce qui s'est exactement passé.

Contextualisé par l'architecture, par défaut

Chaque Managed Run obtient automatiquement accès au serveur MCP de votre projet Archyl. Cela signifie que l'agent peut :

Interroger le modèle C4 pour comprendre les limites du système
Lire les ADRs pour comprendre les décisions passées
Vérifier les règles de conformité pour savoir quels patterns suivre
Parcourir les contrats d'API pour comprendre les interfaces de service
Consulter les assignations technologiques pour choisir les bons outils

Ce n'est pas une intégration optionnelle. C'est le socle. L'agent ne part pas de zéro — il part de votre architecture. Quand il doit créer un nouveau service, il sait dans quel container il s'inscrit. Quand il écrit du code, il connaît les patterns imposés. Quand il ajoute une dépendance, il sait quelles technologies sont approuvées.

Combiné avec les connecteurs externes, cela crée des agents qui sont à la fois conscients de l'architecture et opérationnellement capables. Ils connaissent votre système et ils peuvent interagir avec vos outils.

Pour commencer

Les Managed Agent Runs sont disponibles dès maintenant dans Agent Hub pour les plans Business et Scale.

Créez un connecteur — Allez dans Agent Hub puis Connectors. Ajoutez votre service GitHub, Linear ou tout service compatible MCP.
Lancez une exécution — Allez dans Runs puis New Run. Rédigez votre tâche, attachez des connecteurs et lancez.
Configurez un planning — Allez dans Schedules puis New Schedule. Choisissez une expression cron, attachez des connecteurs et laissez tourner.

Les agents sont prêts. Votre architecture est le contexte. Vos outils sont les connecteurs. Maintenant, mettez-les au travail.