Déléguer à des sous-agents

Un agent qui travaille longtemps accumule du contexte : tout ce qu’il a lu, tout ce qu’il a essayé. La délégation lui donne un autre geste : confier une consigne à un sous-agent, qui travaille dans sa propre session et ne rend que son rapport final. Le parent garde un historique court ; le travail de fond a lieu ailleurs.

Cette page donne le modèle mental de ce mécanisme : ce qu’est un sous-agent, ce qui passe la frontière entre lui et son parent et ce qui ne la passe pas, ce qui borne une cascade de délégations, et à quel moment vous êtes consulté. Les gestes (écrire un sous-agent, lancer une délégation, lire le rapport) sont dans le guide Déléguer une tâche à un sous-agent. Le détail des réglages est sur Les garde-fous d’exécution ; les clés exactes, dans la référence du fichier de configuration.

Ce qu’est un sous-agent

Un sous-agent est un agent au format ordinaire, un fichier Markdown dont le frontmatter porte la configuration et dont le corps est le prompt système, que son frontmatter déclare délégable :

• mode: subagent : délégable par un agent, mais pas invocable par l’utilisateur ;
• mode: all : les deux ;
• pas de mode : invocable par l’utilisateur seulement. Rien n’est délégable sans mode explicite : un fichier d’agent découvert dans un dépôt cloné ne devient pas, par sa seule présence, un exécutant à la disposition du modèle.

Ce défaut suit le principe fermé du reste du produit : ce qui n’a pas été déclaré n’est pas actif.

La délégation existe dans le terminal lemni. Les extensions d’éditeur n’offrent pas l’outil de délégation au modèle, et un fichier mode: subagent n’y figure pas dans la liste des agents à activer.

Deux sous-agents intégrés au produit sont délégables sans rien installer : general (généraliste) et explore (explorateur en lecture seule). Leurs noms sont réservés : un fichier découvert qui porte l’un de ces noms est écarté et signalé, de la délégation comme de l’invocation --agent. Un dépôt cloné ne substitue pas sa persona à un nom auquel vous faites confiance. Charger un tel fichier reste possible en passant son chemin .md complet : c’est alors un acte délibéré.

Ce qui traverse la frontière

Une délégation trace une frontière entre deux sessions. Trois choses la traversent, dans un sens ou dans l’autre ; le reste ne la traverse pas.

Ce qui descend : la consigne, et rien d’autre du parent. Le sous-agent ne reçoit pas l’historique de la session parente ; il part de sa persona, de ses règles et de la consigne. Le parent ne paie pas deux fois son contexte, et le rapport dépend de la consigne, pas de l’état accumulé d’une conversation.

Ce qui remonte : le rapport final, comme résultat de l’outil Task. Si le sous-agent a été arrêté par un garde-fou (borne, boucle, interruption), le rapport revient marqué : le parent distingue « travail fini » de « travail coupé ».

Ce qui se transmet en se resserrant : les droits. La politique d’un sous-agent est l’état effectif du parent, restreint par sa persona. Un outil exclu chez le parent reste exclu chez la fille quoi que déclare son frontmatter, le mode plan du parent la laisse en lecture seule, un serveur MCP qu’elle ne déclare pas ne lui est ni décrit ni accessible, et elle travaille dans le même périmètre fichier. Aucune combinaison de frontmatter ne donne à un sous-agent un droit que son parent n’a pas.

Un sous-agent reste l’agent de la session, au sens du livre blanc : il s’exécute dans le même bac à sable, sur la même copie de travail du dépôt, et ne reçoit ni identité, ni secret, ni accès réseau (livre blanc sécurité V3, sections 4.3 et 11.3). Ses écritures et ses commandes passent par la même politique et la même validation humaine que celles de la session.

Le modèle suit la règle des personas : celui du frontmatter du sous-agent s’il en déclare un, sinon celui de la session parente.

Les filets de la cascade

Un sous-agent peut déléguer à son tour. Trois filets globaux, actifs par défaut et réglables sous la clé execution, bornent l’arbre :

• une profondeur maximale (subagentMaxDepth, défaut 3 ; 1 interdit toute imbrication) : au dernier étage, l’outil de délégation disparaît du catalogue du sous-agent, le produit ne décrit pas au modèle un outil qu’il lui refuserait ;
• un plafond de sous-agents par session (subagentMaxPerSession, défaut 200) ;
• un plafond de sous-agents simultanés (subagentMaxConcurrent, défaut 20).

Quand une limite est atteinte, l’agent reçoit une erreur explicite et finit le travail lui-même. Ces filets se règlent et ne se retirent pas : la valeur zéro est refusée.

À l’intérieur de ces filets, chaque session fille a un budget propre : rien ne se décompte du parent, sauf la délégation elle-même, qui coûte au parent une action, comme tout appel d’outil. Une fille n’a pas de plafond d’actions par défaut ; un sessionMaxActions posé dans son frontmatter s’applique, et la détection de boucle y est active comme dans toute session.

La borne de durée d’une fille vient de la configuration du processus (défauts, puis environnement, puis clé execution), pas du temps déjà consommé par le parent. Chaque fille repart avec un budget de durée entier, sans extension possible : il n’y a pas d’humain dans une session fille, la borne arrête.

Où l’humain décide

Il n’y a qu’une surface d’approbation par processus, l’écran du terminal, et toutes les demandes de l’arbre y convergent, quelle que soit la profondeur. Quand un sous-agent touche un outil soumis à votre accord, la demande s’affiche au même endroit que celles de la session principale, étiquetée du nom de l’agent qui demande. Vous tranchez, pas le modèle parent : une approbation rendue par un modèle serait une auto-autorisation en deux étapes.

Là où personne ne peut répondre (exécution ponctuelle lemni -p, lemni serve, tâche détachée), la demande de permission devient un refus sec et annoncé. Le journal des appels d’outils attribue alors le refus à l’automate, pas à un humain.

Un agent délégué ne pose pas de question ouverte : l’outil Question ne fait pas partie de son catalogue. Il est offert à la session principale, dans un terminal interactif. Un seul canal remonte d’un sous-agent vers vous, la demande de permission d’un sous-agent synchrone. Face à une ambiguïté, l’agent délégué choisit l’interprétation la plus raisonnable et l’énonce dans son rapport. Une tâche détachée ne vous demande rien, ni permission ni question, et cela vaut pour tout ce qu’elle délègue à son tour.

Synchrone ou détaché : deux cycles de vie

Une délégation ordinaire est synchrone : elle est un morceau du tour du parent. Plusieurs appels Task d’un même tour s’exécutent en parallèle, et le tour ne reprend que lorsque tous les rapports sont revenus. Interrompre le tour du parent interrompt ses délégations synchrones : leur rapport revient marqué « interrompu », avec le travail partiel.

Une délégation détachée (background: true) inverse ce lien : l’outil rend immédiatement un identifiant de tâche (task_id) et le parent continue. La fin est annoncée dans la conversation, le rapport se relit avec l’outil TaskResult, qui ne bloque pas, et la tâche survit à l’interruption du tour. Elle reste bornée par sa durée, sa détection de boucle et les filets globaux. Vous pouvez aussi lancer une tâche détachée vous-même, par la mention @general <consigne> dans le terminal, sous les mêmes filets que les délégations du modèle ; la marche à suivre est dans Déléguer vous-même par une mention.

Deux limites du détachement décident de ce que vous lui confiez :

• Une tâche détachée vit dans le processus qui l’a lancée ; elle n’est pas un service. Fermer le terminal, ou arrêter lemni serve, interrompt les tâches en vol sans annonce : leur trace s’arrête dans la session fille persistée. Une tâche dont le résultat compte se relit avant de fermer.
• Le détachement suppose un processus qui dure. En exécution ponctuelle (lemni -p), le processus ne survit pas au tour : background: true s’y replie en exécution synchrone, et le repli est annoncé dans le rapport. Sur lemni serve, processus durable, le détachement est réel, et les événements task/started et task/settled l’annoncent sur le flux d’événements.

Ce qui reste écrit

Le rapport est un résumé ; il n’est pas la preuve. Chaque session fille est persistée comme une session ordinaire : ce que le sous-agent a fait (chaque appel d’outil, chaque verdict de permission, chaque arrêt) se relit après coup, même si le parent n’en a reçu que le rapport. Le rapport se termine par l’identifiant de cette session ; voir Lire le rapport. Un refus sec ou un arrêt sur borne y laisse la même trace que dans une session principale.