La première fois que j'ai entendu parler de subagents, c'était dans le contexte de Cursor et de ses fonctionnalités d'agent. Un agent IA qui peut en appeler d'autres, déléguer des sous-tâches, récupérer les résultats et les synthétiser. Ça m'a semblé presque magique, et un peu abstrait.
Quand j'ai commencé à creuser, j'ai compris que la logique est en réalité assez proche de ce qu'on fait en développement : la décomposition d'un problème complexe en tâches plus simples, chacune confiée à un agent spécialisé. Un agent orchestrateur reçoit une instruction de haut niveau, la découpe, délègue à des sous-agents, et assemble les réponses.
Ce qui distingue cette architecture d'un simple chatbot, c'est l'autonomie et la persistance. Un LLM classique répond à une question et s'arrête. Un agent peut enchaîner des actions, appeler des outils (recherche web, exécution de code, accès à une API), et adapter son plan en fonction des résultats intermédiaires.
J'ai testé rapidement des demos de systèmes multi-agents, notamment via des interfaces qui permettent de visualiser les échanges entre agents. L'observation principale : ça fonctionne bien sur des tâches bien définies, et ça déraille vite sur des consignes ambiguës. Le modèle orchestrateur doit être très bien prompté pour que la chaîne reste cohérente.
Ce que cette exploration m'a apporté, c'est une meilleure compréhension de ce que font réellement les outils comme Windsurf Cascade ou les « modes agent » de Cursor. Derrière l'interface, il y a une architecture de prompts et d'appels successifs, pas une intelligence monolithique qui comprend tout d'un coup.
Pour l'instant, je reste à la surface de ce sujet. Les subagents ouvrent des possibilités énormes, automatisation de workflows, assistants métier complexes, mais ils nécessitent aussi une vraie rigueur dans leur conception. C'est un domaine que je veux approfondir en études post-BTS.