Aller au contenu

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.


Un agent = une fonction, définie par :

ÉlémentRôle
Nom / libelléidentifiant et nom affiché
Modeprimary (tient la conversation avec l’utilisateur) ou subagent (joignable seulement par délégation)
Prompt soclece qui définit son comportement
Modèlepar défaut CoeOS (la box route) — surchargeable
Outils autorisésliste blanche fail-closed (l’agent ne peut rien faire hors de sa liste)
Budget d’étapesplafond 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.

Huit agents sont livrés et disponibles d’emblée.

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.

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.

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.

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 ».

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 :

  1. 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 ;
  2. exécute le sous-agent dans un tour borné, avec seulement les outils de sa liste blanche (refus fail-closed sinon) ;
  3. 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.

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 ? ».

AgentWorkflow (cowork)
Natureboucle agentique autonome, outils, délégationpipeline déterministe fixe, sans outils ni autonomie
Étapeslibres (jusqu’au budget)3 fixes : compose → review → validate
Contextel’agent gère son contextecloisonné (chaque étape ne voit que la précédente)
Décisionl’humain valide les actions sensiblesvalidation humaine obligatoire avant export
Usagerecherche, rédaction, opérations, chatrevues 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).

  1. Dépôt : l’avocat dépose un contrat (le texte est extrait par Docling ; le binaire n’atteint jamais le pipeline).
  2. 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).
  3. 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.
  4. 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 ».
  5. 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).
  6. 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).


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.