Lancer un agent d’IA dans un notebook, c’est simple. Le maintenir en production pendant des heures, voire des jours, est une autre histoire. Google vient de rendre public le code de l’Agent Executor, un runtime pensé exactement pour ce scénario. Et, franchement, il répond à des problématiques que toute équipe d’ingénierie d’agents connaît bien.
Pourquoi un agent Google qui cale en chemin coûte cher
Tout d’abord, parlons du problème réel. Les flux de travail avec des agents peuvent durer longtemps. De plus, ils dépendent d’appels externes, d’approbations humaines et de connexions qui ne sont pas toujours stables.
Lorsqu’un agent tourne pendant des heures, toute défaillance devient un cauchemar. Vous perdez le contexte. Vous perdez l’état. Par conséquent, il faut tout recommencer à zéro. Google a souligné que l’exécution prolongée exige la capacité de reprendre le travail après des interruptions, des échecs ou des checkpoints avec intervention humaine.
Et les chiffres ne sont pas anecdotiques. Selon le rapport “State of Agent Engineering 2026” de LangChain, 57,3% des interviewés avaient déjà des agents en production. Autres 30,4% étaient en train de développer des agents avec des plans clairs de déploiement. Autrement dit, la majorité du marché fait face à ces défis au quotidien.
Comment le Google Agent Executor reprend le travail là où il s’était arrêté
Voici la partie la plus intéressante. Le runtime s’appuie sur un registre d’événements combiné à des instantanés pour reconstruire l’état d’un flux. Ainsi, lorsque quelque chose casse, l’agent ne repart pas de zéro. Il revient exactement au point où il s’était arrêté.
Ce mécanisme couvre aussi les checkpoints avec intervention humaine. Donc, si votre flux nécessite une approbation manuelle en cours de route, l’état est préservé pendant votre attente.
De plus, l’Agent Executor gère les déconnexions client. Imaginez un utilisateur qui perd la connexion pendant une tâche longue. Lorsqu’il se réconnecte, le runtime livre les réponses à partir de la dernière séquence qu’il avait vue. Rien n’est perdu.
Trajectory branching: teste caminhos sans casser le flux
Il existe encore une fonctionnalité qui va plaire à ceux qui testent beaucoup. Il s’agit du trajectory branching, ou ramification de trajectoire. Plutôt que d’exécuter à nouveau l’intégralité du flux, on utilise des checkpoints pour explorer des chemins différents.
Concrètement, l’agent se ramifie à partir d’un checkpoint antérieur. Pendant ce temps, le contexte et l’état de ce point restent intacts. Pour ceux qui itèrent beaucoup sur des invites et des stratégies de décision, cela fait gagner du temps et des ressources.
Sécurité dans les environnements multi-tenant n’est pas optionnelle
À présent, abordons un point sensible. Les agents génèrent du code. Les agents manipulent des données utilisateur. Et cela, bien souvent, dans des environnements partagés par plusieurs clients.
L’Agent Executor apporte de l’isolement via des composants en sandbox. L’objectif est clair : limiter les effets secondaires et réduire le risque que des activités malveillantes affectent l’ensemble du service. Google a cité la génération de code et la gestion des données dans des environnements multi-tenant comme des cas typiques.
La documentation du GKE décrit le Agent Sandbox comme une pièce conçue pour exécuter du code non fiable généré par un LLM. Il offre un isolement au niveau du noyau via GKE Sandbox et fonctionne également avec les conteneurs Kata. De plus, il adopte une approche réseau du type « refuser par défaut ».
Un seul écrivain pour éviter les conflits d’état
Le runtime utilise également une architecture d’écrivain unique pour gérer l’état de la session partagée. La raison est simple. Lorsque plusieurs composants d’un flux distribué tentent de modifier la même session en même temps, des conflits apparaissent. Cette architecture limite justement ce type de mise à jour concurrente.
Google sans verrouillage: le runtime dialogue avec votre pile technologique
Vous vous demandez peut-être si cela vous condamne à rester dans l’écosystème Google. Or le projet va dans le sens inverse. Il est agnostique vis-à-vis des frameworks d’agents.
Vous pouvez le connecter à plusieurs modèles de déploiement. Parmi eux figurent Google Antigravity, des agents natifs comme le Deep Research et des agents personnalisés via API Managed Agents in Gemini. Toutefois, il tourne aussi avec LangChain, LangGraph et le Google Agent Development Kit.
Le support du protocole Agent2Agent est ce qui assemble tout cela. Grâce à lui, le runtime opère entre différents frameworks et environnements de déploiement. Ainsi, vous n’êtes pas prisonnier d’un seul choix technologique.
Et en plus. L’Agent Executor peut fonctionner sur une infrastructure auto-gérée. Ainsi, des flux propriétaires s’exécutent dans vos propres environnements de calcul et sandboxes. Vous pouvez aussi lancer des MCPs, des skills et d’autres agents sur votre plan de données.
Google Agent Substrate: le Kubernetes qui comprend les agents
Google ne s’est pas arrêté au runtime. Cependant, l’entreprise a aussi annoncé le Agent Substrate, un projet frère créé avec l’équipe GKE. Il ajoute une couche axée sur les agents au-dessus de Kubernetes.
Mais pourquoi une couche nouvelle ? Parce que les charges liées aux agents se comportent de manière particulière. Elles présentent souvent des pics d’activité courts suivis de longues périodes d’inactivité. Kubernetes tel quel a été pensé pour des milliers de services de longue durée.
L’écart d’échelle est saisissant. Pendant ce temps, les agents peuvent déclencher des millions d’appels à des outils de courte durée. Pour gérer ce schéma, l’Agent Substrate déplace les agents à l’intérieur et à l’extérieur de la capacité de calcul en temps réel. Il s’en occupe avec un plan de contrôle plus épuré.
Le GKE Agent Sandbox s’intègre encore aux Pod Snapshots. Grâce à cela, les charges inactives peuvent être suspendues et reprises en quelques secondes. Plus aucune ressource laissée inutilement tourner et faire grimper le budget.
Les chiffres d’allocation qui retiennent l’attention
Les données de performance aident à comprendre l’ambition du projet. Selon Google, le pool d’instances actives du GKE Agent Sandbox alloue jusqu’à 300 sandboxes par seconde, par cluster. De plus, 90% de ces allocations se terminent en 200 millisecondes.
Ce pool existe pour une raison précise. Il réduit la latence de démarrage à froid lorsque le système a besoin de nouvelles instances de sandbox. Par conséquent, l’utilisateur final n’attend pas que l’environnement démarre.
Enfin, l’Agent Substrate combine runtime sécurisé, snapshots, planification via Kubernetes et scalabilité horizontale. Google affirme que le plan de contrôle a été conçu pour gérer des centaines de millions d’agents enregistrés. Et tout cela reste dans l’écosystème Kubernetes que vous connaissez déjà.
Ce que cela signifie pour votre prochain projet
Au bout du compte, le message est clair. Mettre des agents en production n’est plus de l’improvisation. Des outils comme l’Agent Executor et l’Agent Substrate traitent la fiabilité, la sécurité et l’évolutivité comme des exigences de première classe.
Si vous avez déjà des agents en fonctionnement, cela vaut la peine de tester comment la reprise par snapshots s’intègre à votre flux. Et si vous êtes encore en phase de prototypage, peut-être est-il temps de penser dès le départ à la production. Après tout, l’outillage existe désormais et est ouvert à la communauté.
Acompanha nosso perfil no Instagram!
