Quatre modèles d'ingénierie issus des meilleures soumissions d'agents IA

Dans un article publié sur le Google Developers Blog en septembre 2026, des ingénieurs ont résumé les décisions architecturales clés issues du Google for Startups AI Agents Challenge. L'analyse s'est concentrée sur des milliers de soumissions mondiales, isolant quatre modèles spécifiques qui distinguaient les entrées les mieux classées des autres. Ces pratiques répondent aux pièges courants liés à la concurrence, à la gestion des coûts et à l'intégration système pour les agents autonomes.

Ce qui s'est passé

Le Google for Startups AI Agents Challenge vient de se terminer, avec des milliers de développeurs soumettant des agents dans trois catégories. Les juges ont évalué ces projets, notant que si beaucoup prétendaient utiliser des systèmes multi-agents, seuls certains mettaient en œuvre des architectures véritablement sophistiquées. De nombreuses soumissions n'étaient que des modèles uniques exécutant des prompts chaînés avec différentes étiquettes d'agent attachées. Cependant, les entrées les mieux classées démontraient systématiquement quatre modèles d'ingénierie distincts qui amélioraient la fiabilité et les performances.

Ces modèles sont issus de soumissions de code réelles plutôt que de conceptions théoriques. Le rapport a anonymisé les équipes pour se concentrer sur les décisions techniques elles-mêmes. Les stratégies identifiées incluent l'utilisation bidirectionnelle du Model Context Protocol (MCP), la concurrence pilotée par événements, une validation stricte des solutions de repli et un routage des requêtes par niveaux. Ces approches ont aidé les équipes à construire des systèmes capables de gérer la charge et la complexité du monde réel sans dépendre uniquement de modèles plus grands ou plus récents.

Comment cela fonctionne

Le premier modèle consiste à faire d'un agent à la fois un client et un serveur utilisant MCP. Typiquement, les agents utilisent MCP pour appeler des outils externes pour les données. Dans les soumissions gagnantes, les agents exposaient également leurs propres outils de raisonnement internes comme serveurs MCP. Cela permettait à d'autres agents de les interroger directement sans intervention humaine. Par exemple, un agent de codage pouvait demander à un agent de performance des informations sur un job spécifique via MCP, évitant ainsi le besoin d'une interface de chat. Cette approche nécessite un contrôle d'accès strict puisque les appelants externes peuvent désormais invoquer la couche de raisonnement directement. Elle empêche également l'épuisement du budget de tokens en filtrant les données de manière programmatique avant qu'elles n'atteignent le contexte du modèle.

Le deuxième modèle remplace les chaînes d'appels linéaires par une concurrence pilotée par événements. Au lieu que l'Agent A appelle l'Agent B et attende une réponse, les agents publient des événements typés sur un bus partagé. Chaque agent s'abonne aux sujets pertinents et traite les événements en parallèle en utilisant des coroutines de travail séparées. Cela découple les agents ayant des tempos de traitement différents. Par exemple, une vérification de conformité peut s'exécuter simultanément avec une tâche de messagerie si elles ne dépendent pas l'une de l'autre pour leur sortie. Cela réduit la latence totale car aucun agent lent unique ne bloque l'ensemble du pipeline.

Le troisième modèle garantit que les modèles de repli respectent les mêmes normes de qualité que les modèles principaux. Lorsqu'un modèle haut de gamme comme Gemini 3.1 Pro renvoie des erreurs sous charge, les systèmes basculent souvent vers une alternative moins chère comme Gemini 3.6 Flash. Les meilleures entrées utilisaient une fonction de validation unique pour les deux chemins. Cette fonction vérifie les citations ou d'autres métriques de qualité avant d'accepter toute réponse. En centralisant la validation, les équipes empêchaient les solutions de repli de réduire silencieusement la qualité de la sortie. Le quatrième modèle utilise un routage par niveaux pour réduire les coûts d'inférence. Les requêtes simples sont traitées par des regex locaux ou des modèles bon marché avant d'atteindre des modèles frontière coûteux. Une équipe a rapporté que cette première passe gérait plus de 40 pour cent des messages, économisant un budget significatif.

Détails clés

• Le MCP bidirectionnel permet aux agents d'exposer des outils internes comme serveurs pour que d'autres agents puissent les appeler directement.
• Les architectures pilotées par événements utilisent des bus de signaux partagés pour permettre un traitement parallèle au lieu d'un blocage séquentiel.
• Les modèles de repli doivent passer par les mêmes fonctions de validation que les modèles principaux pour maintenir les barres de qualité.
• Le routage par niveaux filtre les requêtes simples en utilisant des regex ou des modèles bon marché avant d'invoquer des moteurs de raisonnement coûteux.
• Les meilleures soumissions utilisaient fréquemment l'Agent Development Kit (ADK) et Agents CLI pour mettre en œuvre ces modèles.
• Le contrôle d'accès est critique lors de l'exposition des outils d'agent en externe via des serveurs MCP.

Pourquoi c'est important

Pour les ingénieurs logiciels construisant des produits IA, ces modèles offrent des solutions pratiques aux problèmes d'évolutivité et de coût. Les chaînes d'agents linéaires échouent souvent dans des conditions réelles car la latence s'accumule à chaque étape. Passer à un modèle piloté par événements permet aux systèmes de scalabiliser horizontalement et de répondre plus rapidement aux signaux critiques. C'est particulièrement important dans les applications sensibles au temps comme la surveillance médicale, où les retards peuvent avoir des conséquences graves.

La gestion des coûts est une autre préoccupation majeure alors que les prix de l'inférence restent élevés. Le routage par niveaux garantit que les modèles coûteux ne sont utilisés que pour les tâches complexes nécessitant réellement un raisonnement profond. De même, le MCP bidirectionnel transforme les agents en composants d'infrastructure réutilisables plutôt qu'en chatbots isolés. Cela permet la composabilité, où l'agent d'une équipe peut devenir un outil pour le workflow d'une autre équipe sans construire d'intégrations personnalisées. Ces modèles mettent l'accent sur une ingénierie solide plutôt que sur la taille du modèle, prouvant que l'architecture compte souvent plus que la puissance brute du modèle.

Ce que vous pouvez faire

• Auditez l'accès aux données de votre agent pour voir si les outils MCP internes peuvent être exposés de manière sécurisée comme serveurs externes.
• Identifiez les agents qui s'attendent mutuellement et refactorisez-les pour utiliser un bus d'événements pour une exécution parallèle.
• Centralisez la logique de validation afin que les modèles de repli ne puissent pas contourner les contrôles de qualité appliqués aux modèles principaux.
• Analysez la distribution de votre trafic pour déterminer si les requêtes simples peuvent être gérées par des modèles moins chers ou des regex.
• Implémentez des contrôles d'accès stricts si vous exposez des outils d'agent via MCP pour prévenir les utilisations non autorisées.
• Utilisez des frameworks comme ADK qui supportent la concurrence et le partage d'outils pour simplifier la mise en œuvre de ces modèles.