L'architecture en boucle des agents

Tout le monde demande : « C’est quoi ce délire de boucle ? » Mais personne ne pose la question qui tue : qu’est-ce qui fait tourner la boucle ?

Le débat sur l’IA s’est cristallisé autour des boucles en tant que primitive centrale des systèmes agentiques. Matt Van Horn (@mvanhorn) a retracé la généalogie des boucles d’agents, de ReAct à l’utilisation d’outils, des boucles d’orchestration aux boucles qui supervisent d’autres boucles. Addy Osmani (@addyosmani) a décomposé les blocs de construction à l’intérieur des boucles : automatisations, arbres de travail, compétences, connecteurs, sous-agents. Van Horn a mis l’accent sur la durabilité, arguant qu’une boucle qui ne survit pas à un redémarrage n’est pas une véritable boucle. Le fil conducteur d’Osmani était l’orchestration : concevoir le système qui invite l’agent à agir, plutôt que de le faire vous-même.

Je veux pousser leurs idées plus loin. La durabilité n’est pas qu’une propriété de la boucle. C’est toute la couche d’exécution qui la sous-tend. Le fait important est qu’une orchestration durable est fondamentale pour construire l’architecture de votre boucle d’agent. Décomposons cette architecture.

Là où les boucles se cassent

Les modèles /loop et /goal fonctionnent bien pour un agent unique et une session unique. Un agent boucle jusqu’à ce qu’une tâche soit terminée. Cela couvre beaucoup de cas. Mais l’étape suivante (l’étape 5 dans le cadre de Van Horn) est là où tout s’effondre :

• Des boucles qui supervisent d’autres boucles
• Des boucles qui s’exécutent selon un planning, pas seulement déclenchées par un humain
• Des boucles qui survivent aux redémarrages de processus, aux déploiements et aux crashs
• Des boucles qui lancent des sous-agents et attendent leurs résultats (parfois des heures plus tard)
• Des boucles qui doivent être observables après coup

Ce n’est pas un problème de prompt. C’est un problème d’infrastructure.

Van Horn cite @runes_leo : « La chose la plus coûteuse dans le codage IA n’est plus d’écrire du code, c’est de gérer la boucle d’agent. » Un while True dans un terminal ne vous donne rien de tout cela. Pas plus qu’un processus de longue durée sur une VM ou dans un sandbox.

Pensez à ce qui se produit quand vous exécutez une boucle d’agent sur un serveur. Le processus va mourir ou redémarrer. Un déploiement, un OOM, une récupération d’instance spot. La boucle redémarre. Mais qu’était-elle en train de faire ? À quelle étape en était-elle ? Avait-elle déjà envoyé ce message Slack ? Avait-elle déjà invoqué le sous-agent ?

Vous ne le savez pas. Elle recommence à zéro. Elle récupère des données déjà obtenues. Elle rappelle le LLM pour des décisions déjà prises. Elle envoie une notification en double. Elle lance un sous-agent en double. Vous vous réveillez avec trois messages Slack identiques et une équipe perplexe.

La solution n’est pas une « meilleure gestion des erreurs » — c’est un modèle d’exécution où chaque étape est enregistrée par points de contrôle, chaque décision est persistée, et la reprise signifie reprendre à partir de la dernière étape réussie.

L’architecture de la boucle d’agent en trois couches

Trois couches. Chacune correspond à une primitive concrète.

Couche 1 : La boucle

Une boucle, c’est un cron plus un décideur. Elle s’exécute selon un planning (ou un déclencheur), évalue l’état et décide de la suite.

C’est la définition de Van Horn rendue concrète : ce que cron n’a jamais eu, c’est la décision au milieu. C’est l’agent qui décide, pas vous. Le cron est le battement de cœur. Le LLM est le décideur. Les étapes sont l’exécution durable qui enregistre l’avancement.

1export const infraHealthCheck = inngest.createFunction(
2  { id: "infra-health-check" },
3  { cron: "*/30 * * * *" }, // Toutes les 30 minutes
4  async ({ step }) => {
5    const metrics = await step.run("fetch-service-metrics", async () => {
6      return await fetchServiceMetrics(); // taux d'erreur, latence, mémoire, CPU
7    });
8
9    const assessment = await step.run("assess-health", async () => {
10      return await callLLM({
11        prompt: `Compte tenu de ces métriques de service, classez l'état général du système
12                 comme "normal", "dégradé" ou "critique". Expliquez votre raisonnement.
13                 Métriques : ${JSON.stringify(metrics)}`,
14      });
15    });
16
17    if (assessment.status === "degraded" || assessment.status === "critical") {
18      await step.invoke("triage-incident", {
19        function: incidentTriage,
20        data: { metrics, assessment, services: assessment.affectedServices },
21      });
22    }
23  }
24);

Chaque lundi à 9h, la boucle se déclenche. Elle récupère les données, demande au LLM si un rapport est justifié, et invoque une compétence si c’est le cas. Si le processus redémarre entre deux étapes, les étapes déjà terminées ne sont pas réexécutées. Voilà la boucle. Pas le LLM, la boucle autour du LLM.

Couche 2 : La compétence

Dans ce contexte, une compétence n’est pas un prompt. C’est un workflow durable. Multi-étapes, réessayable, composable, déployable indépendamment.

Van Horn : « La boucle est la plomberie. L’actif, c’est la compétence qu’elle appelle. » C’est la partie qui s’accumule. Chaque nouvelle compétence apprise par le système rend chaque boucle plus capable.

1export const incidentTriage = inngest.createFunction(
2  { id: "incident-triage", retries: 3 },
3  { event: "infra.incident.triage" },
4  async ({ event, step }) => {
5    const details = await step.run("fetch-detailed-metrics", async () => {
6      return await fetchDetailedMetrics({ services: event.data.services });
7    });
8
9    const deploys = await step.run("fetch-deploy-history", async () => {
10      return await fetchRecentDeploys({ since: hoursAgo(2) });
11    });
12
13    const analysis = await step.run("correlate-incident", async () => {
14      return await callLLM({
15        prompt: `Corrélez ces métriques de service avec les déploiements récents.
16                 Identifiez la cause racine probable et la sévérité.
17                 Métriques : ${JSON.stringify(details)}
18                 Déploiements récents : ${JSON.stringify(deploys)}`,
19      });
20    });
21
22    await step.run("post-triage-summary", async () => {
23      await slack.postMessage({
24        channel: "#incidents",
25        text: formatTriageSummary({
26          analysis,
27          affectedServices: event.data.services,
28          recommendedActions: analysis.recommendations,
29        }),
30      });
31    });
32
33    return analysis;
34  }
35);

Cette compétence récupère, classe et achemine. C’est une unité de travail avec une tolérance aux pannes intégrée. La compétence peut être un workflow IA avec un LLM au milieu, ou du code déterministe.

Couche 3 : L’orchestrateur

L’orchestrateur est le moteur qui fait tourner tout ça : il planifie les crons, exécute les étapes, gère les tentatives, applique les limites de concurrence, stocke l’historique des exécutions, et déploie à chaud de nouvelles fonctions/workflows sans perturber les exécutions en cours.

C’est la couche dont personne ne parle parce qu’elle est censée être invisible. Pourtant, elle est fondamentale.

La plupart des gens voient les agents comme « LLM + outils ». L’architecture de boucle d’agent reformule cela : les agents sont « boucles + compétences + orchestration ». Le LLM + les outils sont à l’intérieur des boucles. Les LLM et les outils peuvent être échangés ou modifiés alors que l’architecture reste. L’orchestration rend l’architecture possible.

Ce qui se passe quand les choses cassent

Le chemin heureux est facile. Mais c’est un logiciel en production : est-ce que tout se passe vraiment comme prévu ?

Votre compétence de triage d’incident se déclenche et l’API de métriques expire. La lecture a dû aller sur le disque et le cache mémoire ne contenait pas les données. L’étape qui appelle cette API réessaie et frappe à nouveau l’API. Les données sont maintenant partiellement en cache et l’API aboutit. La compétence continue avec l’étape suivante comme si de rien n’était.

Parfois, ce n’est pas aussi simple. Et si une clé API expire, ou si votre hébergeur est indisponible pendant 30 minutes ? Toutes vos tentatives sont épuisées. Que se passe-t-il alors ? Vous devez aussi gérer les échecs.

1export const incidentTriage = inngest.createFunction(
2  {
3    id: "incident-triage",
4    retries: 3,
5    onFailure: async ({ error, event, step }) => {
6      // La fonction a échoué après avoir épuisé les tentatives.
7      // Nous avons toujours les données de l'événement d'origine. Rien n'est perdu.
8      await step.run("notify-failure", async () => {
9        await slack.postMessage({
10          channel: "#agent-ops",
11          text: `⚠️ Le triage d'incident a échoué : ${error.message}. ` +
12                `Nouvelle tentative au prochain cycle de vérification de santé. ` +
13                `Services concernés : ${event.data.services.join(", ")}`,
14        });
15      });
16    },
17  },
18  { event: "infra.incident.triage" },
19  async ({ event, step }) => {
20    /* la même logique que la compétence ci-dessus */
21  }
22);

Le gestionnaire \onFailure\ se déclenche après l’épuisement de toutes les tentatives. Il publie dans un canal ops pour que quelqu’un soit informé. L’événement est conservé, rien n’est perdu. La prochaine exécution planifiée reprend là où celle qui a échoué n’a pas pu.

Une orchestration durable doit vous offrir des tentatives au niveau de l’étape pour les erreurs transitoires, et des hooks de gestion d’échec pour les erreurs non récupérables. Sans cela, les choses cassent (comme c’est le cas), et vous le découvrez des heures ou des jours plus tard.

Les erreurs transitoires sont aussi coûteuses. Si votre compétence ou agent réessaie depuis le début, vous appelez les LLM plusieurs fois et brûlez des tokens inutilement. L’appel LLM peut être enregistré par point de contrôle. Multipliez cela par 10 ou 30 agents dans votre système. C’est coûteux.

L’enregistrement par points de contrôle au niveau de l’étape n’est pas qu’une fonctionnalité de correction. C’est un économiseur d’argent.

L’agent qui construit ses propres compétences

C’est là que ça devient plus intéressant. Le système n’est pas statique, il est conçu pour évoluer et s’étendre lui-même.

L’agent ne se contente pas de s’exécuter à l’intérieur des boucles — il crée de nouvelles boucles et les enregistre dans le moteur d’orchestration. Chaque fonction déployée est une compétence durable qui s’exécute de manière indépendante, déclenchable depuis une boucle ou un agent, ou selon un planning, avec sa propre logique de tentative. Les compétences s’accumulent.

C’est un agent conscient de l’orchestration.

Voici comment ça fonctionne. Un agent IA a accès au SDK d’orchestration en tant qu’outil. Il peut écrire de nouvelles fonctions, les enregistrer dans le moteur, et elles commencent à s’exécuter immédiatement. Le processus de l’agent recharge à chaud les nouvelles fonctions sans redémarrer ni perturber les exécutions en cours.

Prenons un exemple concret :

1. Un humain exprime un besoin. L’ingénieur dit : « Nos services ont des pics de latence la nuit et personne ne le remarque avant le matin. » C’est le déclencheur. L’agent n’a pas besoin de déduire un motif vague à partir de données ambiantes. Il a des instructions claires.

2. L’agent écrit une compétence. Deux fonctions multi-étapes : une boucle de vérification de santé qui s’exécute toutes les 30 minutes, récupérant les taux d’erreur, la latence et l’utilisation des ressources, le LLM classant l’état du système comme normal, dégradé ou critique. Et une compétence de triage d’incident qui récupère les métriques détaillées et l’historique des déploiements récents, corrèle les causes racines avec un LLM, et publie un résumé de triage dans Slack avec des actions recommandées. Gestion des erreurs : si l’API de métriques est en panne, patienter et réessayer. Si le LLM échoue, se rabattre sur une classification de sévérité basée sur des règles.

3. L’agent déploie la compétence. L’agent écrit le code de la fonction qui est pris en charge par un processus sidecar. Les nouvelles fonctions sont enregistrées automatiquement. Elles sont actives immédiatement, sans pipeline de déploiement, sans PR.

4. La compétence s’exécute de manière autonome. Toutes les 30 minutes, le moteur déclenche la vérification de santé. Si quelque chose ne va pas, il invoque la compétence de triage. Aucun humain dans la boucle. Totalement durable.

5. L’agent itère sur le signal. C’est la partie que les gens survolent, donc je vais être précis sur ce que signifie « itérer ». L’agent ne remarque pas les motifs par magie. Il a une boucle de révision séparée : une fonction déclenchée par cron qui s’exécute chaque semaine, lit l’historique des exécutions de l’orchestrateur, et évalue la performance :

1export const reviewSkillPerformance = inngest.createFunction(
2  { id: "review-skill-performance" },
3  { cron: "0 10 * * 5" }, // Tous les vendredis à 10h
4  async ({ step }) => {
5    const runs = await step.run("fetch-run-history", async () => {
6      return await getInngestRuns({
7        functionId: "incident-triage",
8        since: daysAgo(7),
9      });
10    });
11
12    const analysis = await step.run("analyze-performance", async () => {
13      const successRate = runs.filter(r => r.status === "completed").length / runs.length;
14      const avgDuration = average(runs.map(r => r.duration));
15      const incidents = await fetchIncidentOutcomes(); // Les incidents étaient-ils corrélés à des pannes réelles ?
16
17      return await callLLM({
18        prompt: `Examinez la performance de cette compétence au cours de la semaine écoulée.
19                 Taux de réussite : ${successRate}
20                 Durée moyenne : ${avgDuration}ms
21                 Incidents corrélés à des pannes réelles : ${incidents.confirmed}/${incidents.total}
22                 Faux positifs : ${incidents.falsePositives}
23                 L'équipe a agi sur les alertes : ${incidents.actedOn}/${incidents.total}
24
25                 Devons-nous ajuster les seuils ou la classification ? Quels changements spécifiques ?`,
26      });
27    });
28
29    if (analysis.shouldModify) {
30      await step.invoke("update-skill", {
31        function: coreAgent,
32        data: { prompt: `Mettez à jour les compétences de triage d'incident en fonction des changements proposés suivants : ${analysis.proposedChanges}` },
33      });
34    }
35  }
36);

La « révision » est une fonction. Elle lit l’historique des exécutions, vérifie si les incidents étaient corrélés à des pannes réelles, et alimente ce signal au LLM. Si la vérification de santé ne cesse de signaler un service comme dégradé mais que l’équipe l’ignore parce que les seuils sont trop sensibles, la boucle de révision le détecte et la compétence est mise à jour pour ajuster la classification. Pas de magie. Un cron job avec un LLM dans le siège de décision.

Qu’en est-il de la validation ? L’agent qui écrit du code n’est aussi bon que les garde-fous qui l’entourent. Le code peut être vérifié par typage. L’agent peut invoquer la fonction lui-même pour la tester, car il peut interagir avec le moteur d’orchestration. Ce n’est pas infaillible, mais vous donnez à l’agent central la capacité de déboguer les compétences qu’il écrit nativement dans le système où il opère. La boucle de révision détecte les problèmes non capturés lors du débogage initial.

En poussant un peu plus loin, l’agent peut utiliser les hooks onFailure pour se déclencher lui-même et évaluer un échec donné. C’est une boucle de rétroaction qui s’améliore en continu.

Qu’en est-il des conflits ? Les contrôles de flux, notamment les contrôles de concurrence ou les singletons, traitent le cas simple (concurrency : \{ limit: 1, key: "[event.data.service" }]), ce qui signifie qu’un seul triage d’incident s’exécute à la fois par service. Mais la question plus profonde est : que se passe-t-il si deux vérifications de santé détectent toutes deux des problèmes sur le même service simultanément ? L’orchestrateur les met en file d’attente. Le deuxième triage attend que le premier soit terminé. Pas d’alertes en double, pas de conditions de course. Ce n’est pas théorique. C’est la même primitive de concurrence que vous utiliseriez dans n’importe quelle file d’attente de jobs.

L’agent ne se contente pas d’exécuter des tâches. Il construit sa propre infrastructure. Chaque compétence persiste au-delà de la conversation qui l’a créée. Tue le processus de l’agent et redémarre-le. Les compétences continuent de tourner. Remplace le modèle sous-jacent. Les compétences continuent de tourner. L’agent est éphémère — son résultat est durable.

Vue d’ensemble de l’architecture de la boucle d’agent

Le point de vue du développeur

C’est important parce que si le développeur ne peut pas voir ce que l’agent a déployé, déboguer ce qui a cassé, et auditer ce qui s’est exécuté à 3h du matin, toute l’architecture est une lourde responsabilité.

Le moteur d’orchestration stocke chaque exécution, chaque étape, chaque entrée, chaque sortie, chaque tentative. Une compétence que l’agent a déployée mardi dernier et qui a échoué à 4h du matin ? Vous pouvez voir exactement quelle étape a échoué, quelle était l’entrée, quelle erreur a été levée, et combien de tentatives ont été faites avant d’abandonner. Des traces complètes jusqu’au niveau de l’étape sont la sortie même du moteur d’orchestration.

Ce n’est pas un tableau de bord ajouté après coup. C’est inhérent à l’exécution durable. Chaque step.run() est un point de contrôle. Chaque point de contrôle est observable. Quand celui qui écrit le code n’est pas un humain, l’observabilité n’est pas un luxe — c’est la couche de confiance.

Au quotidien, le flux de travail du développeur ressemble à ceci : le matin, consultez le tableau de bord des exécutions. Voyez quelles compétences ont tourné pendant la nuit, lesquelles ont réussi, lesquelles ont échoué. Si une compétence écrite par l’agent se comporte mal, vous pouvez lire le code directement, le modifier, le supprimer, ou demander à l’agent de le corriger. L’agent l’a créée, mais vous en êtes propriétaire. L’agent et ses compétences restent un jardin que vous devez entretenir.

Pourquoi la durabilité est fondamentale

Van Horn : « Ces choses doivent survivre à un redémarrage. »

Voici ce que signifie la durabilité en pratique :

Exigence

Ce que ça implique

Pourquoi une simple boucle while échoue

Tentative indépendante par étape

Si l’étape 3 sur 5 échoue, réessayer l’étape 3, pas les étapes 1 et 2

Un redémarrage de boucle réexécute tout depuis le début

Cycle de vie des sous-agents

Lancer une tâche enfant, l’attendre (parfois des heures), l’annuler si le parent est annulé

Pas de gestion native du cycle de vie parent-enfant

Distribution garantie des événements

Si un événement se déclenche pendant que l’agent est hors ligne, il doit quand même être traité

Les événements sont perdus si le processus ne tourne pas

Observabilité a posteriori

Voir ce qui s’est passé après coup : chaque étape, chaque décision, chaque tentative

Les logs sont votre seule option, et ils sont éphémères

Déploiement à chaud sans interruption

Déployer une nouvelle version de fonction sans tuer les exécutions en cours

Un redémarrage de processus tue tout

Contrôle de concurrence

Exécuter seulement N instances d’une compétence à la fois

Pas de primitives de concurrence intégrées

« Exécutez-le simplement dans un conteneur » vous donne de la disponibilité. Ça ne vous donne pas de la correction. Un conteneur qui redémarre après un crash ramène le processus, mais chaque boucle en cours recommence depuis le début. Chaque étape est réexécutée. Chaque appel LLM est refait. La boucle a l’air de tourner, mais elle tourne à l’aveugle.

Comparaison avec les outils existants

Certains outils peuvent vous offrir une solution « clé en main » élégante pour ce type de système, ou vous pourriez choisir de bricoler des outils de plus bas niveau et créer votre propre système. Aucun choix n’est mauvais, mais la bonne couche d’architecture doit vous permettre, ainsi qu’à votre agent, d’évoluer dans le temps. Flexible, dynamique, durable.

Des primitives d’exécution durable qui s’intègrent bien à un agent, que l’agent peut facilement écrire, et l’observabilité et les API pour observer et permettre à l’agent lui-même d’être conscient de l’orchestration.

Un exemple fonctionnel

Nous testons ces modèles en interne chez Inngest et vous pouvez en voir un concept dans le dépôt du projet « utah » ici : https://github.com/inngest/utah. C’est un harnais d’agent construit sur l’orchestration durable d’Inngest, qui est également conscient de l’orchestration.

Le système comprend un processus sidecar qui permet à l’agent principal d’écrire et de modifier des fonctions Inngest dans son propre espace de travail, s’étendant ainsi avec des « compétences » (dans le contexte de cet article). Bientôt, nous prévoyons de fournir un système complet avec des boucles de démarrage en exemple, mais les idées qui y sont présentes peuvent illustrer les concepts de cet article de manière plus claire.

La boucle qui s’accumule

Le récent article de Satya Nadella a nommé quelque chose que l’industrie ressentait : le fossé n’est pas le modèle — c’est la boucle.

Sa définition : il existe deux types de capital. Le capital humain, les connaissances et le jugement que votre équipe a bâtis au fil des ans. Et ce qu’il appelle le capital de tokens, les workflows IA, les schémas de décision et les compétences apprises qu’une entreprise construit par-dessus les modèles fondamentaux.

La thèse : ces deux capitaux s’accumulent. Chaque workflow amélioré génère un meilleur signal. Un meilleur signal produit un comportement IA plus précis. Un comportement plus précis libère de l’attention humaine pour un travail à plus haut jugement. Une machine à grimper les collines.

C’est ce que l’architecture de boucle d’agent permet concrètement :

• Chaque compétence durable déployée par l’agent est une connaissance institutionnelle encodée sous forme d’infrastructure exécutable. Elle persiste. Elle s’exécute qu’un humain regarde ou non.
• Une boucle de révision déclenchée par cron qui évalue la performance des compétences et itère. C’est la machine à grimper les collines rendue réelle. Pas un diagramme de volant d’inertie dans un deck. Une fonction avec un déclencheur cron.
• Si vos compétences meurent au redémarrage du processus, l’accumulation revient à zéro. La durabilité est ce qui fait que l’investissement persiste.

Le point clé de Nadella : « Une entreprise devrait pouvoir remplacer un modèle ‘généraliste’ sans perdre l’expertise de ‘vétéran de l’entreprise’ intégrée dans son système d’apprentissage. » C’est le modèle de la bibliothèque de compétences. Les fonctions durables ne se soucient pas du LLM qui les appelle.

Construisez en conséquence

La conversation a porté sur ce que font les agents : boucles, outils, raisonnement, ingénierie de contexte. La prochaine conversation porte sur ce qui fait tourner les agents.

Trois couches : boucle, compétence, orchestrateur. La boucle est l’unité de travail. La compétence est l’actif. Le moteur d’orchestration est ce qui rend les deux durables. Le modèle sidecar est l’approche : un agent écrit ses propres compétences durables, les déploie, examine leur performance et itère. Pas une expérience de pensée. C’est un modèle fonctionnel.

Nous avons construit Inngest pour être le moteur d’orchestration pour cela : step.run(), step.invoke(), déclencheurs cron, contrôle de flux piloté par événements, contrôles de concurrence, et observabilité complète au niveau de l’étape. Mais le modèle architectural est plus grand que n’importe quel outil unique. Si vous construisez des boucles d’agent en production, définissez les trois couches.

Les primitives existent aujourd’hui. Construisez en conséquence.