Les agents
CoeOS n’a pas un « moteur agentic externe » : l’agentique est native à l’application. Elle repose sur deux mécanismes distincts et complémentaires :
- Les agents — un assistant principal (Nemo) qui délègue à des sous-agents spécialisés, chacun avec un rôle, des outils et des garde-fous.
- Les workflows — des pipelines déterministes à étapes cloisonnées (compose → review → validate) pour les revues documentaires, avec validation humaine obligatoire.
Dans les deux cas, aucun agent ne « contient » un modèle : il pointe sur le
méta-modèle CoeOS, et c’est la box (le routeur) qui envoie chaque appel au
modèle prouvé le meilleur sur cet axe. Tu choisis la fonction, CoeOS choisit le
modèle.
1. Ce qu’est un agent
Section intitulée « 1. Ce qu’est un agent »Un agent = une fonction, définie par :
| Élément | Rôle |
|---|---|
| Nom / libellé | identifiant et nom affiché |
| Mode | primary (tient la conversation avec l’utilisateur) ou subagent (joignable seulement par délégation) |
| Prompt socle | ce qui définit son comportement |
| Modèle | par défaut CoeOS (la box route) — surchargeable |
| Outils autorisés | liste blanche fail-closed (l’agent ne peut rien faire hors de sa liste) |
| Budget d’étapes | plafond de tours pour une tâche déléguée |
Les agents se règlent dans Paramètres → Agents : on peut éditer les agents livrés (les désactiver, jamais les supprimer — ils sont re-semés à chaque déploiement) et créer ses propres agents (import/export en Markdown). Un agent personnel prime sur l’agent d’instance du même nom.
2. Les agents livrés
Section intitulée « 2. Les agents livrés »Huit agents sont livrés et disponibles d’emblée.
Nemo — l’assistant principal (primary)
Section intitulée « Nemo — l’assistant principal (primary) »C’est l’agent auquel l’utilisateur parle. Il tient la conversation et délègue
le travail spécialisé aux sous-agents via l’outil task. Quand employer : par
défaut, tout le temps — c’est le point d’entrée.
Explore — la recherche (subagent, lecture seule)
Section intitulée « Explore — la recherche (subagent, lecture seule) »Rassemble des faits : mémoire, RAG (bases documentaires), fichiers de l’espace de travail, web, serveurs MCP. Strictement lecture seule — « ne crée, ne modifie, n’envoie, ne supprime jamais rien ». Quand l’employer : retrouver une décision antérieure, comparer des sources, réunir de la matière avant de rédiger.
Writer — la rédaction (subagent)
Section intitulée « Writer — la rédaction (subagent) »Produit des documents longs complets (rapports, notes, synthèses) sous forme de fichiers. « Tu écris des fichiers, tu ne bavardes pas. » Quand l’employer : quand le livrable est un document, pas une réponse de chat.
Ops — l’exécution bornée (subagent)
Section intitulée « Ops — l’exécution bornée (subagent) »Exécute des actions précises et cadrées sur des sources connectées (Notion, Linear, infra via MCP). « N’élargis jamais le périmètre. » Quand l’employer : une opération explicite et délimitée sur un outil externe.
Legal review — la revue de contrat mono-tour (subagent)
Section intitulée « Legal review — la revue de contrat mono-tour (subagent) »Reçoit un document + une doctrine, produit un tableau de conformité JSON
strict. FR et NL (selon la langue de l’utilisateur). Invariant : « Tu n’es PAS
un avocat… tu proposes une lecture que l’avocat valide » (AI Act art. 50).
Note : la version courante et enrichie de ce cas d’usage est le workflow
contract-review — cf. §6.
Arena — la revue contradictoire (trois sous-agents)
Section intitulée « Arena — la revue contradictoire (trois sous-agents) »Un trio orchestré séquentiellement pour stress-tester un document :
- Arena — Défense : plaide la conformité, ne cite que des clauses présentes.
- Arena — Attaque : soulève les faiblesses en citant les clauses ; ne doit
jamais inventer une clause absente (marque
[clause absente du document]). - Arena — Synthèse : pèse défense vs attaque, arbitre, marque le résultat comme « proposition — décision finale = l’avocat ».
Quand l’employer : quand on veut une lecture contradictoire, pas un seul avis.
Invariant transverse à tous les agents legal : « 0 source inventée » et « l’IA propose, l’avocat dispose ».
3. Comment les agents tournent
Section intitulée « 3. Comment les agents tournent »L’utilisateur parle à Nemo. Quand une tâche mérite un spécialiste, Nemo
appelle l’outil task en précisant le sous-agent, la consigne et une description.
Le système :
- crée une conversation-enfant dédiée au sous-agent (avec son prompt), et pose une carte de tâche dans la conversation principale ;
- exécute le sous-agent dans un tour borné, avec seulement les outils de sa liste blanche (refus fail-closed sinon) ;
- rend un résumé dans la carte, consultable via le panneau Trace.
Garde-fous : au plus 3 délégations par tour, profondeur de délégation ≤ 2, budget global de 30 étapes. Un sous-agent ne voit rien de la conversation parente — la consigne de délégation doit être auto-suffisante. Les sous-agents ne polluent pas la barre latérale et n’écrivent pas la mémoire.
Le mode agent (agentMode) est désactivé par défaut : sans lui, la
conversation est un chat simple et propre (aucun outil injecté). On l’active pour
donner à l’agent l’accès aux outils.
Les outils disponibles (quand le mode agent est actif)
Section intitulée « Les outils disponibles (quand le mode agent est actif) »- Recherche :
rag_search(recherche sémantique sur les bases RAG),web_search(DuckDuckGo, sans clé),web_read. - Fichiers :
fs_list / fs_read / fs_write / fs_edit(espace de travail par utilisateur). - Compétences :
skill_*(paquets d’instructions Markdown). - MCP : les outils des serveurs MCP tiers branchés par l’utilisateur
(Paramètres → MCP servers), nommés
mcp_<serveur>_<outil>. - Optionnels : Web Search (Tavily, si clé), image (ComfyUI/Imager, si addon),
bash(sandbox).
Sur un Mac avec agent local connecté, bash et fs_* s’exécutent sur la machine
de l’utilisateur.
4. Agent Trace — « montrer son travail »
Section intitulée « 4. Agent Trace — « montrer son travail » »Un Agent Trace est l’enregistrement inspectable de ce qu’un agent a fait. Il existe deux surfaces :
-
Le panneau Trace (utilisateur) — ouvert depuis une carte de tâche. Il affiche le transcript complet du sous-agent : chaque étape, chaque outil appelé, le résultat. C’est la transparence « montre ton travail ». Source = les messages persistés de la conversation-enfant (jamais purgés).
-
La page Traces (admin — Paramètres → Traces) — la télémétrie : par agent et par type d’appel (LLM / outil / tâche), le nombre d’appels, les tokens consommés, la durée moyenne, le nombre d’erreurs ; plus les 50 dernières tâches avec leur conversation, statut, durée. Fenêtre glissante de 30 jours.
Autrement dit : le panneau Trace répond à « qu’a fait cet agent, précisément ? », la page Traces à « comment se comportent les agents dans le temps ? ».
5. Agent vs Workflow
Section intitulée « 5. Agent vs Workflow »| Agent | Workflow (cowork) | |
|---|---|---|
| Nature | boucle agentique autonome, outils, délégation | pipeline déterministe fixe, sans outils ni autonomie |
| Étapes | libres (jusqu’au budget) | 3 fixes : compose → review → validate |
| Contexte | l’agent gère son contexte | cloisonné (chaque étape ne voit que la précédente) |
| Décision | l’humain valide les actions sensibles | validation humaine obligatoire avant export |
| Usage | recherche, rédaction, opérations, chat | revues documentaires réglementées (contrat, RH) |
6. Un workflow type — la revue de contrat (bout en bout)
Section intitulée « 6. Un workflow type — la revue de contrat (bout en bout) »Le workflow contract-review est un pipeline en trois étapes cloisonnées,
chaque étape = un appel LLM quasi-déterministe (température 0.1).
- Dépôt : l’avocat dépose un contrat (le texte est extrait par Docling ; le binaire n’atteint jamais le pipeline).
- Compose : lit le document + la doctrine du cabinet (les « Golden
Rules », GR-001…GR-012) → produit un tableau de conformité JSON (une ligne par
règle ; clause absente →
non_applicable, aucun extrait inventé, aucune jurisprudence citée). - Review : relit uniquement le document + la sortie de Compose → corrige (clauses manquantes, extraits inventés, sévérité ou page erronées) et journalise les erreurs trouvées.
- Validate : voit le document + Compose + Review corrigé → produit le tableau final stable + un résumé exécutif de ≤ 5 lignes pour l’avocat. Il ne décide pas : « il présente un état stable que l’avocat va accepter, refuser ou faire refaire ».
- Gate humain (obligatoire) : la sortie est une proposition. L’export
n’est possible qu’après que l’avocat a cliqué « Valider » — ce clic écrit
un événement auditable
workflow.validated. Sans lui, l’export renvoie une erreur (409). - Export : une fois validé, le tableau de conformité + le résumé sont exportables.
Le cloisonnement (compose ne voit jamais les notes du reviewer, le reviewer
ne voit jamais le résumé du validateur) est précisément ce qui empêche l’agent de
« se valider lui-même ». Un second workflow, hr-policy-review, réutilise le
même moteur pour la conformité RH (politique d’entreprise vs CCT de branche
belge, CCT 200/100).
En une phrase
Section intitulée « En une phrase »L’utilisateur parle à Nemo, qui délègue à des sous-agents spécialisés (Explore, Writer, Ops, Arena…) sous garde-fous et outils en liste blanche ; les revues réglementées passent par des workflows cloisonnés à validation humaine ; tout est traçable (panneau Trace + page admin) ; et les modèles viennent tous de la box, jamais épinglés dans l’agent. L’IA propose, l’avocat dispose.