Il décide ce qui reste dans la fenêtre de contexte, ce qui est résumé, ce qui s'exécute dans un bac à sable sans jamais entrer dans le contexte, quand confier une sous-tâche complexe à un sous-agent, et quand s'arrêter pour demander l'avis d'un humain. Ce n'est pas un framework : vous écrivez toujours vos propres outils. Ce n'est pas une passerelle : il ne détient ni vos identifiants ni votre politique. C'est l'élément qui maintient un agent opérationnel de la première à la cinquantième itération.

La boucle elle-même représente environ deux cents lignes de code. N'importe qui peut l'écrire, et la plupart des équipes le font en un après-midi. Le harnais, c'est tout ce que vous construisez au cours des six mois suivants, une fois que cette boucle rencontre une charge de travail réelle et commence à faire face à des obstacles en cours de route.

Notre thèse est que les modèles deviendront interchangeables, que les outils deviendront le facteur de différenciation de l'entreprise plutôt que celui du fournisseur, et que la gouvernance doit se situer sous l'agent plutôt qu'à l'intérieur. Ce que nous avions sous-estimé, c'était le harnais. L'équipe d'ingénierie des plateformes de développement de NetApp a soumis une charge de travail réellement complexe à cette thèse, en profondeur, en avance sur le marché, et nous a montré exactement là où elle montrait ses limites.

En juin 2025, Rob Rubin, désormais directeur principal de l'ingénierie des plateformes de développement chez NetApp, avait déjà dépassé la question que la plupart des entreprises débattaient encore. Son équipe gère les environnements Kubernetes sur lesquels le reste de l'entreprise s'appuie, et le provisionnement en libre-service était déjà entièrement automatisé. La contrainte résidait dans l'interface : un formulaire de demande ne peut offrir que ce qui a été modélisé à l'avance.

Son idée était d'y placer l'intention à la place. Décrivez la pile que vous souhaitez ; laissez un agent l'assembler à partir de l'automatisation existante.
Cela impliquait deux choses de notre part.

Pas de framework d'agent. Pas de harnais. Ce n'était pas encore le sujet de la conversation. La raison pour laquelle il a choisi de standardiser sur MCP explique pourquoi cette histoire s'arrête là :

Mi-2025, c'était une position minoritaire. C'est en grande partie pour cette raison que TrueForge propose ses solutions en open source plutôt que sous forme de runtime géré fermé.

La première phase concernait l'identité, et c'est la partie que la plupart des équipes sous-estiment.

Pas une identité basée sur « l'agent détient une clé API ». Une véritable identité, où la personne qui pose la question détermine ce que les outils peuvent faire. Un utilisateur s'authentifie via le fournisseur d'identité de NetApp. Cette identité est transmise via la passerelle MCP au serveur MCP, qui la vérifie par rapport au compte de cluster de l'utilisateur et émet des identifiants à courte durée de vie, limités à l'utilisateur. Chaque appel kubectl et chaque commande shell s'exécutent en tant que cette personne. Si vous interrogez quelque chose auquel vous n'avez pas accès, vous obtenez exactement ce qu'un terminal vous donnerait : rien.

Quatre mots, et ils sont la raison pour laquelle ce projet est passé en production. Un agent fonctionnant avec un compte de service disposant des droits cluster-admin n'est qu'une démonstration. Un agent fonctionnant avec votre identité est une infrastructure.

Tout le reste réside dans la passerelle plutôt que dans un agent individuel : identifiants de fournisseur, RBAC au niveau du modèle, autorisations au niveau des outils, budgets, limites de débit, garde-fous, journalisation. Les agents font référence aux noms des modèles et des serveurs ; les identifiants ne transitent jamais. C'est ce qui permet à une équipe de plateforme d'approuver le quarantième agent aussi facilement que le premier, car un nouvel agent n'est pas une nouvelle copie du modèle de sécurité.

Début 2026, l'agent Kubernetes était opérationnel auprès des utilisateurs, et la nature de la charge de travail explique tout ce qui suit.

Un ingénieur demande : « Pourquoi mon pod est-il en CrashLoopBackOff ? » La plateforme couvre huit clusters Kubernetes au service de toute l'entreprise ; la première tâche de l'agent consiste donc généralement à localiser la charge de travail avant de pouvoir diagnostiquer quoi que ce soit. Vient ensuite l'enquête proprement dite : décrire l'espace de noms, lister les pods, extraire les événements, filtrer les journaux, inspecter la couche d'entrée, interroger les métriques historiques. Le serveur MCP expose kubectl, un shell, Prometheus et un outil d'inventaire de cluster. Aucune de ces séquences n'est scriptée ; le modèle la compose en fonction du problème.

Quinze à trente séries de sorties de commandes réelles par question. Gardez ce chiffre en tête, car il résume toute l'histoire de l'ingénierie.

Trente itérations de sorties brutes kubectl et de logs ont un effet prévisible sur une fenêtre de contexte. Les investigations commençaient à échouer en cours de route.

Ce que nous avons reçu n'était pas une demande de fonctionnalité. C'était un rapport de bug, et un rapport bien argumenté :

Il avait écarté les suspects coûteux, ce qui constitue la partie la plus ardue de tout diagnostic : ce n'était ni le modèle, ni le prompt, ni les outils. La couche qu'il pointait du doigt se situait juste sous l'interface, celle qui décide de ce qui reste dans le contexte, de ce qui est résumé, et de ce qui est exécuté ailleurs sans jamais entrer dans le contexte.

Nous n'avions pas cette couche. Nous étions partis du principe, à tort, que la boucle intermédiaire relevait de la responsabilité du client. C'est cette hypothèse que NetApp a fait voler en éclats, et c'est celle sur laquelle repose encore, selon nous, une grande partie du marché.

Un moteur d'exécution ouvert et auto-hébergé élimine la facture par utilisateur d'une plateforme gérée. Ce n'est pas là l'aspect le plus intéressant, et ce n'est pas la raison pour laquelle NetApp est ici.

Parallèlement à l'attribution, il y a le problème de la discipline : les utilisateurs se tournent vers le plus gros modèle alors qu'un plus petit suffirait. Les deux problèmes se règlent au même endroit. Chaque appel de modèle et chaque appel d'outil est associé à une personne et à une équipe, avec des budgets et des limites de débit réellement contraignants, et un routage qui dirige le travail vers le modèle approprié plutôt que vers le plus gros disponible.

Nous n'avons pas fini. Rob souhaite une application du budget par exécution plutôt que par semaine, et il a raison : un plafond hebdomadaire est trop imprécis lorsqu'un agent à exécution longue peut l'épuiser en une seule investigation.

C'est aussi pour cette raison que le harness et la passerelle doivent appartenir au même système. Un harness seul vous donne un agent. Un harness intégré à un plan de contrôle gouverné vous donne un agent que vos équipes de sécurité et de finance pourront valider.