Loop Engineering : Pourquoi le runtime de l'agent est le nouveau middleware

Cela s'appuie sur Patterns d'agents longue durée : maintenir les agents en vie sur des heures et des jours, qui a cartographié les trois modes de défaillance qui émergent aux horizons de heures à jours (désalignement au niveau de la trajectoire, érosion par compactage, auto-évolution) et les trois couches d'application qui les détectent. Ici nous nous concentrons sur un développement complémentaire : la couche de runtime elle-même devient un middleware géré et inspectable — ce que TrueFoundry appelle loop engineering, publié le 23 août 2026.

Points clés

• LangGraph a 34,5 millions de téléchargements PyPI mensuels et environ 400 déploiements entreprise dont Klarna, Uber et BlackRock — la couche de runtime autour du modèle est l'endroit où la différenciation de production s'accumule, pas dans la sélection du modèle (comparaison de production uvik.net)
• Le pattern de loop engineering de TrueFoundry nomme cinq décisions opérationnelles qui passent du prompt au runtime : points de contrôle d'approbation, persistance de session, isolement des credentials, compactage de contexte et chargement de capacités à la demande — chacune est une propriété du runtime, pas une instruction de prompt (TrueFoundry)
• Le graph engineering gouverne les arêtes entre les boucles : qui agit, ce qui traverse, combien ça coûte et quelles preuves survivent — le principe « évaluer le nœud, gouverner l'arête » rend l'autorité, le mouvement de données et les dépenses applicables au niveau de la topologie (TrueFoundry)
• Un seul agent a égalé ou surpassé les systèmes multi-agents sur 64% des tâches benchmarkées à un coût de 2x — la première décision d'architecture est de savoir si vous avez besoin de plusieurs agents, et la boucle est l'endroit où cette décision est appliquée (Princeton NLP)

Chaque ère du logiciel d'entreprise développe une couche qui semble secondaire jusqu'à ce que les décisions opérationnelles s'y accumulent. À l'ère client-serveur, c'était le serveur d'applications. À l'ère du cloud, l'orchestrateur de conteneurs. À l'ère des données, le planificateur de pipelines. Pour les agents IA, cette couche a un nom : le runtime qui enveloppe le modèle et le transforme en un agent fiable de longue durée. LangGraph à lui seul a 34,5 millions de téléchargements PyPI mensuels et environ 400 déploiements entreprise — le runtime n'est pas une couche secondaire. La documentation de TrueFoundry définit l'agent harness simplement comme « la couche de runtime autour d'un LLM qui le transforme en un agent fiable de longue durée. » Cet article cartographie le pattern de loop engineering — ce que la boucle médie, pourquoi elle se comporte comme un middleware et ce que la couche de gouvernance du graph engineering ajoute — et explique pourquoi la boucle, pas le modèle, est l'endroit où la fiabilité du déploiement B2B se décide.

Le problème : le jugement opérationnel vit dans la boucle, pas dans le prompt

Le prompt engineering demande ce qu'il faut dire au modèle. Le context engineering demande ce qu'il faut lui montrer. Le loop engineering demande ce que le système fait entre les appels au modèle. Cette question appartient autant à l'ingénierie de plateforme et de sécurité qu'aux auteurs de prompts, car la boucle est l'endroit où les décisions opérationnelles institutionnelles deviennent applicables.

La distinction devient concrète quand on liste ce que la boucle médie à chaque circuit. Qu'un appel d'outil configuré qui écrit dans un système de production procède ou s'arrête pour un humain. Que l'état de session survive aux reconnexions et redémarrages. Que le code généré puisse voir les credentials du harness. Qu'une longue tâche trime ou décharge le contexte. Qu'une sous-tâche déléguée retourne son résultat final plutôt que sa transcription de travail complète. Aucune de ces choses n'est appliquée de manière fiable par le seul comportement du modèle. Chacune est une décision opérationnelle qu'une organisation peut vouloir appliquer de manière cohérente — et c'est pourquoi la boucle commence à ressembler à un middleware.

Le tableau de traduction rend le pattern visible :

Jugement opérationnel	En tant que prompt, c'est...	Dans la boucle, cela devient...
Les actions d'écriture/destruction attendent un humain	une suggestion	un point de contrôle appliqué
Le travail reprend à travers les reconnexions/redémarrages	au mieux	des sessions durables
Les credentials restent loin du code en exécution	un espoir	un isolement par architecture
Les longues tâches gèrent le contexte	un historique illimité	un compactage géré
La capacité arrive quand nécessaire	une surcharge de payload	une découverte à la demande

Les décisions de boucle se combinent différemment des instructions de prompt car la politique de runtime peut médier chaque tour de manière déterministe. Changez où le compactage se produit, et chaque tâche longue durée utilisant ce runtime hérite du changement. Ajoutez une frontière d'approbation, et une classe d'actions risquées nécessite désormais une autorisation explicite plutôt que de s'appuyer uniquement sur la discipline comportementale. Le mécanisme est familier du middleware — définissez un contrôle une fois, appliquez-le de manière cohérente — et explique pourquoi l'attention de l'ingénierie senior se déplace vers le runtime.

Ce pattern se connecte directement aux trois modes de défaillance que l'article parent documente. L'érosion par compactage (décroissance de gouvernance) est un problème de boucle : le résumé qui abandonne les règles de sécurité vit dans l'étape de gestion de contexte de la boucle. Le désalignement au niveau de la trajectoire est un problème de boucle : la validation par action voit une séquence d'appels d'outils réussis, tandis que la surveillance au niveau de la trajectoire — qui appartient à la boucle — voit la déviation. L'auto-évolution est un problème de boucle : un agent qui modifie ses propres contraintes modifie un état géré par la boucle. La boucle est le substrat où les trois modes de défaillance apparaissent ou sont supprimés.

La boucle comme middleware : une lecture historique

Le pattern récurrent à travers les ères technologiques n'est pas que le middleware devient inévitablement open source. Les serveurs d'applications d'entreprise incluent encore des produits propriétaires majeurs aux côtés de standards ouverts. L'orchestration de conteneurs a fortement convergé autour de Kubernetes open source. La planification de workflows a des systèmes open source influents (Apache Airflow) aux côtés d'alternatives gérées. La leçon est plus étroite : une fois qu'une couche opérationnelle devient stratégiquement importante, les entreprises valorisent l'inspectabilité, la portabilité et la capacité d'exécuter ou de remplacer la couche à leurs propres conditions.

Ère	Le composant célébré	La couche qui décidait des résultats	Où elle a fini
Client-serveur	La base de données	Serveur d'applications	Mixte : propriétaire plus standards ouverts
Cloud	La VM	Orchestrateur de conteneurs	Kubernetes open source est devenu dominant
Données	L'entrepôt	Planificateur de pipelines	Planificateurs open source coexistent avec services gérés
Agents	Le modèle	La boucle	En cours de décision

La boucle d'agent peut suivre une partie de cet arc. L'argument pour l'ouverture est concret : la disponibilité du code source rend l'audit au niveau de l'implementation possible (cela ne prouve pas qu'un binaire déployé est fiable, mais cela rend l'audit possible). Un runtime qui supporte l'auto-hébergement peut placer la couche d'exécution dans votre périmètre. Une implementation ouverte extensible permet aux équipes de modifier le compactage, le checkpointing ou le comportement d'intégration sans attendre la roadmap d'un fournisseur. TrueFoundry a publié son harness, TrueForge, sous licence MIT avec fonctionnement local et hébergé, traitant les modèles, serveurs MCP et fournisseurs de sandbox comme des dépendances connectées.

Le résumé stratégique : la couche qui applique votre jugement devrait être une couche que vous pouvez juger.

Que demander à votre boucle

Si la boucle est l'endroit où vit le jugement opérationnel, la question d'approvisionnement est de savoir si votre runtime est inspectable et portable. Six questions cadrent l'interrogation :

1. Le travail survit-il à un redémarrage ? La persistance de session est une propriété du runtime. Un agent qui doit recommencer après chaque interruption n'est pas un agent de longue durée — c'est un agent de courte durée qu'on redémarre constamment.
2. Que peut voir l'environnement d'exécution de code ? La conception du sandbox garde les credentials du harness hors de portée du modèle. Si le modèle peut lire la clé API qui provisionne son propre compute, l'isolement est un prompt, pas une frontière.
3. Quelles actions s'arrêtent pour un humain — par runtime ou par espoir ? L'approbation d'outils est la différence entre un point de contrôle appliqué et une suggestion. La boucle la rend déterministe.
4. La capacité se charge-t-elle à la demande ou à chaque tour ? Les outils et compétences différés réduisent la surcharge de payload. Une boucle qui envoie chaque description d'outil à chaque circuit gaspille la fenêtre de contexte dont l'agent a besoin pour raisonner.
5. Une exécution peut-elle être reconstruite à partir de ses traces ? Le pattern de log de session append-only — convergé indépendamment par DeepSeek Harness et Meta Muse Code — est le substrat pour le replay, le rollback et l'audit. L'article parent documente cette convergence en détail.
6. Si vous quittiez votre fournisseur de runtime demain, que perdriez-vous ? La portabilité réelle dépend des formats de données, des intégrations et des pratiques opérationnelles, pas seulement de la disponibilité du code source. Mais un runtime dont l'implementation ne peut pas être inspectée rend l'audit profond, l'auto-hébergement, la modification et la planification de sortie plus difficiles.

De la boucle au graphe : gouverner les connexions

Un seul agent avec une boucle durable résout le problème d'exécution. Mais les systèmes de production font rarement tourner un seul agent. La progression — d'agent à boucle à graphe — ajoute une question système différente à chaque étape. Le post d'architecture From Agent to Loop to Graph de TrueFoundry cadre l'escalade : un premier agent fonctionnel introduit des questions de capacité et d'utilisation d'outils. Une boucle durable ajoute des préoccupations d'état, de récupération, de contexte et d'approbation. Un graphe ajoute la topologie, la coordination et la délégation. L'auto-modification soulève des questions de vérification, d'isolement et de promotion. L'orchestration transforme le système combiné en un problème opérationnel.

La distinction critique est qu'un graphe ne remplace pas la boucle — il organise des boucles et d'autres nœuds. Un graphe de production peut contenir des agents, des fonctions déterministes, des routeurs, des jointures, des files d'attente, des points de contrôle humains, des évaluateurs, des écritures en base de données et des services ordinaires. Seuls les nœuds agentiques ont besoin de leur propre boucle d'exécution locale. Le graphe possède des questions comme quel nœud s'exécute ensuite, si les branches s'exécutent en parallèle, quel résultat débloque une jointure, ce qui se passe quand une branche échoue, et quel chemin nécessite un point de contrôle humain. La boucle à l'intérieur d'un nœud agentique possède un ensemble différent : quel contexte l'agent voit, quel outil il sélectionne, comment il gère les observations, quand il réessaie, et quand son travail local est complet.

Une seconde distinction importe : l'orchestration de graphe n'est pas un graphe de connaissances. Un graphe de connaissances structure l'information — entités et relations. Un graphe d'exécution d'agents structure l'exécution — acteurs, nœuds computationnels, transitions, dépendances et état de travail. L'un peut nourrir l'autre, mais ils répondent à des questions différentes. Si un agent de recherche interroge un graphe de connaissances puis délègue la validation à un second agent, le graphe de connaissances fait partie de ce que le système sait ; le graphe d'exécution décrit ce que le système fait.

Le principe de gouvernance que TrueFoundry condense en sept mots : évaluer le nœud, gouverner l'arête. Vous évaluez toujours le comportement des nœuds — l'évaluation du modèle ne disparaît pas. Mais l'évaluation seule ne peut pas faire qu'une base de données de production rejette une écriture, applique un budget ou exige une approbation avant une opération destructive. Les frontières d'autorisation du runtime, de la gateway et des systèmes en aval appliquent ces contraintes quand le trafic pertinent les traverse. Chaque arête conséquente devrait répondre à cinq questions :

Question	Pourquoi ça compte	Propriétaire probable
Qui ou quoi agit ?	Attribution, moindre privilège, audit	Identité / registre
Que peut atteindre ce nœud ?	La découverte n'est pas l'autorisation	Orchestrateur + gateway + politique en aval
Que peut traverser l'arête ?	Minimisation des données, défense contre l'injection de prompt	Politique applicative + garde-fous de gateway
Combien peut-il dépenser ou se ramifier ?	Les graphes multiplient les retries, branches et appels au modèle	Orchestrateur + budgets de gateway
Quelles preuves survivent ?	Les graphes conçus et exécutés divergent	Orchestrateur + harness + système d'enregistrement

Le paysage des frameworks : où s'inscrit le loop engineering

Le loop engineering est un pattern au niveau du runtime, pas un choix de framework. Le paysage des frameworks est stable depuis août 2026 :

• LangGraph — 34,5 millions de téléchargements PyPI mensuels, environ 400 déploiements entreprise dont Klarna, Uber, LinkedIn, BlackRock et JPMorgan. Standard de production pour les agents avec état avec checkpointing, débogage time-travel et support MCP natif. LangSmith pour l'observabilité.
• CrewAI — plus de 44 600 étoiles GitHub, plus de 10M d'exécutions d'agents par mois sur la plateforme, exploration à environ 60% du Fortune 500. Surcharge de tokens jusqu'à 3x supérieure à LangGraph sur les tâches simples.
• Microsoft Agent Framework — 1.0 GA publié le 3 avril 2026, remplaçant AutoGen (désormais en mode maintenance). Support MCP natif ; A2A via adaptateur séparé (beta).
• OpenAI Agents SDK — environ 19 000 étoiles GitHub, 10,3M de téléchargements mensuels.
• Google ADK — natif Gemini, A2A-first.
• DeepSeek Harness — licence MIT, plus de 33K étoiles GitHub, log de session append-only.

Le résultat de Princeton NLP ancre la première décision d'architecture : un seul agent a égalé ou surpassé les systèmes multi-agents sur 64% des tâches benchmarkées à un coût de 2x. Avant de choisir un graphe multi-agents, demandez si la tâche justifie la surcharge de coordination. La boucle est l'endroit où cette décision est appliquée — une boucle bien conçue avec checkpoint/resume, portes d'approbation et gestion de contexte peut faire le travail qu'un graphe multi-agents ferait avec un coût supérieur et plus de surfaces de défaillance.

Le loop engineering est compatible avec tous ces frameworks. Le pattern concerne ce que le runtime médie, pas sur quel framework vous construisez. Le checkpointing et le débogage time-travel de LangGraph sont des primitives de loop engineering. Le log de session append-only de DeepSeek Harness est une primitive de loop engineering. L'approbation d'outils et l'isolement de sandbox de TrueForge sont des primitives de loop engineering. La convergence est le signal : quand plusieurs runtimes indépendants implémentent le même ensemble de contrôles opérationnels, les contrôles sont des exigences structurelles, pas des choix de fournisseur.

Le pattern de loop engineering — décisions de runtime qui s'accumulent dans le cycle d'exécution entre le modèle et le système métier :

Lecture associée

• Patterns d'agents longue durée : maintenir les agents en vie sur des heures et des jours — l'article parent cartographiant les trois modes de défaillance (désalignement au niveau de la trajectoire, décroissance de gouvernance, auto-évolution) et trois couches d'application (pre-inférence, runtime, rollback) que le loop engineering operationalise
• Kill Switch by Design : architecture de gouvernance d'agent — le modèle d'application à trois couches (hooks pre-inférence, disjoncteurs de runtime, rollback post-hoc) que la boucle implémente au niveau du runtime
• Observabilité des agents IA : ce que vous ne pouvez pas voir vous fera du mal — la pile de télémétrie à quatre couches qui rend les agents loop-engineered interrogeables plutôt que grep-ables

Un distributeur de taille intermédiaire utilisant NetSuite et BigCommerce déploie un agent qui surveille la boîte de réception d'approvisionnement 24/7, vérifie les catalogues fournisseurs, applique les règles commerciales et rédige les devis. L'agent fonctionne pendant des heures, pas des minutes. Le pattern de loop engineering est ce qui le maintient dans les limites : le point de contrôle d'approbation qui s'arrête avant une écriture dans NetSuite, la persistance de session qui permet à l'agent de reprendre après un timeout d'API fournisseur, l'isolement des credentials qui garde le token OAuth NetSuite hors du contexte du modèle, et le compactage de contexte qui trime l'ancien historique de RFQ sans abandonner les règles commerciales qui gouvernent la tarification. La construction est un engagement à portée définie : le moteur RFQ, les modules connecteurs MCP, le runtime de boucle avec checkpoint/resume et portes d'approbation, et la couche de graphe qui gouverne les arêtes entre l'agent de devis, l'agent de conformité et l'écriture retour vers NetSuite.

Une semaine de découverte. Vous obtenez un inventaire système, une carte de workflow et une portée fixe — whether or not you build with us.