Subagents : déléguer des tâches spécialisées

Le principe de la délégation

Dans un projet complexe, certaines tâches sont indépendantes les unes des autres : analyser la sécurité d’un fichier pendant qu’un autre processus génère des tests. Plutôt que de tout traiter séquentiellement, Mistral Vibe permet de déléguer des tâches à des subagents. Un subagent est un agent qui s’exécute de manière indépendante, réalise sa mission, puis renvoie un résultat textuel à l’agent principal. Il ne peut pas poser de questions à l’utilisateur : il doit être autonome.

Cette contrainte est la clé de tout ce qui suit, et elle mérite d’être détaillée. Un subagent s’exécute dans son propre contexte, sans accès à la conversation en cours — il ne sait donc rien de ce que vous avez expliqué à l’agent principal cinq minutes plus tôt. Il ne peut pas utiliser ask_user_question et doit se débrouiller seul face à une ambiguïté. Il renvoie un texte que l’agent principal intègre ensuite dans sa réponse. Et parce qu’il est ainsi coupé de l’échange, il n’a de sens que conçu pour une tâche précise et bien définie.

Configurer un subagent

Pour transformer un agent en subagent, ajoutez le champ agent_type = "subagent" dans le fichier .toml. Le reste de la configuration suit les règles habituelles des agents custom.

# ~/.vibe/agents/test-generator.toml
display_name = "Test Generator"
description = "Génère des tests unitaires pour les fonctions données."
agent_type = "subagent"
safety = "neutral"
model = "codestral-latest"

system_prompt = """
Vous recevez du code source. Générez des tests unitaires complets :
- Tests des cas nominaux
- Tests des cas limites (null, undefined, chaînes vides)
- Tests des erreurs attendues
Framework : le framework de test du projet (Jest, Vitest, Pytest...).
Retournez uniquement le code des tests, prêt à copier.
"""

enabled_tools = [
  "read_file",
  "grep",
  "list_dir"
]

Remarquez l’absence de ask_user_question dans les outils : ce n’est pas un oubli. Un subagent ne peut pas demander de clarification, et le prompt système compense cette impossibilité en désignant à l’avance le framework de test à utiliser et le format exact de la réponse.

Cas d’usage concrets

Le premier bénéfice est le travail parallèle. L’agent principal peut confier plusieurs tâches simultanément à des subagents différents, chacun travaillant de son côté avant de renvoyer son résultat.

Agent principal
├── Subagent "test-generator" → génère les tests
├── Subagent "doc-writer" → génère la documentation
└── Subagent "security-checker" → analyse les vulnérabilités

Le second bénéfice concerne les tâches très spécialisées. Certaines demandent un prompt système radicalement différent de celui de l’agent principal ; plutôt que de surcharger un seul agent avec des instructions contradictoires, on délègue. L’optimiseur SQL ci-dessous en est un bon exemple : son prompt ne parle que d’index, de plans d’exécution et de N+1, ce qui n’aurait aucun sens dans un agent généraliste.

# ~/.vibe/agents/sql-optimizer.toml
display_name = "SQL Optimizer"
description = "Analyse et optimise les requêtes SQL."
agent_type = "subagent"
safety = "safe"
model = "mistral-large-latest"

system_prompt = """
Analysez les requêtes SQL fournies :
1. Identifiez les problèmes de performance (N+1, full scan, index manquant)
2. Proposez des requêtes optimisées
3. Suggérez les index à créer
Retournez un rapport structuré avec avant/après pour chaque requête.
"""

enabled_tools = ["read_file", "grep"]

Le troisième bénéfice, moins évident, est l’isolation de sécurité. Un subagent avec safety = "safe" ne peut pas modifier de fichiers, même si l’agent principal tourne en mode destructive : les permissions ne s’héritent pas vers le bas. Vous pouvez donc travailler en mode permissif tout en confiant les analyses à des subagents restreints, qui n’ont aucun moyen d’agir sur le dépôt.

# Subagent qui ne peut QUE lire
agent_type = "subagent"
safety = "safe"
auto_approve = true
enabled_tools = ["read_file", "grep"]

Vibe fournit d’ailleurs un subagent explore intégré, qu’il utilise automatiquement quand il a besoin de parcourir votre codebase pour répondre à une question. Il fonctionne en lecture seule et renvoie un résumé de ce qu’il a trouvé — c’est exactement le patron que vous reproduisez avec vos propres subagents.

Concevoir un bon subagent

Tout se joue sur l’autonomie du prompt système : il doit contenir toutes les instructions nécessaires pour que le subagent aille jusqu’au bout sans jamais poser de question. Cela suppose d’anticiper les cas où les choses se passent mal et d’écrire noir sur blanc ce que l’agent doit faire alors, comme dans l’exemple suivant.

system_prompt = """
Analysez TOUS les fichiers TypeScript du projet.
Si un fichier n'est pas trouvé, passez au suivant.
Si le framework de test n'est pas identifiable, utilisez Vitest par défaut.
Retournez toujours un résultat, même partiel.
"""

Deux réflexes complètent ce travail. Donnez au subagent les outils strictement nécessaires — un subagent d’analyse n’a pas besoin de write_file — et spécifiez le format de sortie attendu dans le prompt système. L’agent principal doit pouvoir exploiter le résultat sans ambiguïté : c’est lui, et non vous, qui lira ce texte en premier.

Points clés à retenir

• Un subagent est un agent indépendant qui ne peut pas interagir avec l’utilisateur
• Configurez-le avec agent_type = "subagent" dans le fichier .toml
• Les subagents sont idéaux pour le travail parallèle et les tâches spécialisées
• Ils offrent une isolation de sécurité naturelle
• Le prompt système doit être entièrement autonome — pas de questions possibles
• Spécifiez toujours un format de sortie clair dans le prompt