Organisation des agents

Description

Bonnes pratiques pour créer, gérer et former des agents spécialistes enfants persistants (marketing, recherche, design, etc.) via le système d'organisation.

Déclencheurs

• organization
• specialist
• marketing agent
• research agent
• design agent
• team
• delegate work
• spawn specialist
• child agent

Instructions

Organisation vs Swarm

• Organization (cette skill) — clones EloPhanto persistants pour le travail de domaine (marketing, recherche, design, n'importe quoi). Identité propre, coffre de connaissances, esprit autonome. Ils apprennent des retours et travaillent de manière proactive.
• Swarm — agents de codage externe éphémères (Claude Code, Codex, Gemini CLI) pour les tâches de code. Pas d'apprentissage, pas de persistance.

Si la tâche nécessite une expertise de domaine → organization. Si la tâche est du code → swarm.

Quand créer des spécialistes

1. Travail spécifique au domaine — stratégie marketing, recherche concurrentielle, audits de design, création de contenu
2. Travail récurrent — tâches qui se répètent (le spécialiste accumule des connaissances au fil du temps)
3. Travail de domaine en parallèle — « rechercher les concurrents ET rédiger le plan marketing » → créer les deux
4. Surveillance proactive — « surveiller les prix des concurrents » → spécialiste avec esprit autonome

Quand NE PAS créer

• Tâches rapides et ponctuelles que vous pouvez gérer directement
• Tâches de codage (utiliser swarm à la place)
• Tâches qui nécessitent vos outils directement (navigateur, email, paiements)

Créer un spécialiste

Utilisez organization_spawn avec un rôle et un objectif clairs :

• role — identifiant court : "marketing", "research", "design", "content"
• purpose — ce que fait ce spécialiste (devient son identité)
• seed_knowledge — fichiers de connaissances pertinents à copier de votre coffre

Le spécialiste passe par sa première activation, découvre son identité et est prêt à travailler.

Si un spécialiste pour ce rôle existe déjà, il est réutilisé (redémarré s'il est arrêté). Ne créez pas de doublons.

Déléguer des tâches

Utilisez organization_delegate avec soit role (résolution automatique) soit child_id :

• Soyez précis sur la tâche — « Créer un calendrier de contenu de 5 posts pour la semaine prochaine ciblant les développeurs »
• Incluez les contraintes — « Concentrez-vous sur X et LinkedIn, gardez les posts sous 280 caractères pour X »
• Référencez le contexte — « Utilisez les directives de marque dans votre coffre de connaissances »

Examiner les résultats

Examinez toujours les résultats du spécialiste avec organization_review :

• Approuver avec retours — renforce le bon comportement, notes de félicitations ou d'affinage optionnelles
• Rejeter avec raison spécifique — le rejet devient un fichier de correction dans le coffre de connaissances du spécialiste. Soyez précis sur ce qui s'est mal passé et quelle est la bonne approche.

Bon rejet : « Le post dépasse la limite de 280 caractères de X. Vérifiez toujours les limites de caractères des plateformes : X=280, LinkedIn=3000, Mastodon=500. » Mauvais rejet : « C'est faux. »

Enseignement

Utilisez organization_teach pour pousser proactivement des connaissances :

• Directives de marque, guides de style, règles de plateforme
• Connaissances spécifiques au domaine dont le spécialiste a besoin
• Corrections qui s'appliquent largement (non liées à une tâche spécifique)

Score de confiance

• Confiance = nombre_approuvés - nombre_rejetés
• Nouveaux spécialistes (confiance < 10) — examinez tout résultat
• Spécialistes de confiance (confiance >= 10) — éligibles pour l'auto-approbation
• Faible confiance (négatif) — peut nécessiter un re-seed avec les connaissances corrigées

Anti-patterns

• Créer trop de spécialistes — chacun est un processus complet avec son propre budget LLM. Respectez max_children.
• Délégation vague — « faire du marketing » est trop large. Décomposez en tâches spécifiques.
• Ne pas examiner les résultats — la boucle de retour est comment les spécialistes apprennent. Sauter l'examen = pas d'apprentissage.
• Rejeter sans explication — « rejeté » n'enseigne rien. Toujours inclure des retours spécifiques.
• Dupliquer des rôles — vérifiez organization_status avant de créer. Un spécialiste par rôle.

Vérifier

• L'autre agent / outil / canal visé a bien reçu le message ; un accusé de réception, un ID de message ou un payload de réponse est capturé
• L'identité, les scopes et les permissions utilisés par l'appel étaient le minimum requis ; les tokens surpermissionnés sont signalés
• La gestion des défaillances a été testée : au moins un chemin retry/timeout/permission-denied est montré comme fonctionnant comme prévu
• Le contexte de passation transmis à l'acteur suivant est assez complet pour que le destinataire puisse agir sans question de suivi
• Tout état modifié (config, mémoire, queue, fichier) est listé avec les valeurs avant/après, pas seulement « mis à jour »
• Les éléments sensibles (clés, tokens, données personnelles) ont été masqués dans les journaux / transcriptions partagés dans la preuve de vérification