Cet article vient d’un thread Twitter qui explique exactement comment structurer son agent IA pour en faire un vrai opérateur autonome. Et ouais, j’ai appliqué tout ça à ma config.
1. Splitter la mémoire en 5 fichiers
Fini le gros fichier MEMORY.md qui contient tout. Maintenant j’ai :
- active-tasks.md — crash recovery, lu en premier au démarrage
- lessons.md — chaque erreur documentée, jamais répétée
- projects.md — état actuel de chaque projet
- daily logs — contexte brut, supprimé après 7 jours
Pourquoi ? Un seul fichier = contexte bloated = agent confus. En splitant, l’agent charge uniquement ce dont il a besoin.
2. “Use when / Don’t use when” dans chaque skill
Sans ça, l’agent choisit le mauvais skill ~20% du temps. La différence :
Pas bon :
“description”: “Déployer des sites web”
Bon :
“description”: “Déployer des fichiers sur cPanel. UTILISER POUR : upload de fichiers, création de domains. NE PAS UTILISER POUR : acheter des domaines (utiliser registrar skill), gérer DNS (utiliser Cloudflare skill)”
C’est du if/else routing pour le cerveau de l’agent.
3. HEARTBEAT.md sous 20 lignes
Le heartbeat tourne toutes les ~30 minutes. Garde-le tiny :
- Vérifier si les tâches actives sont stale (>2h sans update)
- Archiver les sessions bloated (>2MB)
- Self-review toutes les ~4 heures
Heavy work → cron jobs. Heartbeat = quick health check seulement.
4. Cron jobs pour tout ce qui est schedule
Les heartbeats c’est pour grouper des checks rapides. Le cron c’est pour le vrai travail :
- 7h → veille IA vers Telegram
- 8h → résumé tech news
Chaque cron tourne dans sa propre session isolée. Pas de context bleed. Pas de gaspillage de tokens.
5. L’agent vérifie son propre travail
J’ai ajouté ça dans AGENTS.md :
“Every sub-agent MUST validate its own work. But I also verify the result before announcing to the user. Never take a sub-agent’s result for granted.”
L’agent qui build ≠ l’agent qui review. Cette règle règle 80% des problèmes de qualité.
6. Router les modèles par type de tâche
Pas besoin du modèle le plus cher pour tout :
- File reading, reminders, travail interne → modèle rapide/pas cher
- Contenu web externe (articles, tweets) → modèle le plus fort seulement
- Tâches de coding → mid-tier avec extended thinking
Pourquoi le plus fort pour le contenu externe ? Les modèles plus faibles sont plus vulnérables au prompt injection depuis des sites hostiles.
7. Session hygiene — archiver agressivement
Sessions >2MB = agent lent, contexte confus, turns coûteux. Archivage automatique :
-
2MB → archiver
-
5MB → alerter
- Daily logs → rotate chaque semaine
L’agent doit tourner light. S’il charge des megabytes d’historique à chaque tour, il gaspille de l’argent et devient plus con.
8. SOUL.md avec personnalité
Les agents par défaut sonnent comme des chatbots corporate. J’ai donné :
- Un nom
- Un style de com (“direct, skip filler”)
- Des limites (“ask before sending emails”)
- Le droit d’avoir des opinions
Un agent avec de la personnalité catch plus de edge cases parce qu’il s’engage vraiment avec la tâche au lieu de générer du output générique.
9. Crash recovery en 3 lignes
Ajouté dans AGENTS.md :
“On startup: read active-tasks.md FIRST. Resume autonomously. Don’t ask what we were doing — figure it out from the files.”
L’agent VA crasher. Les sessions VONT restart. Sans ça, il se réveille confus et demande “what should I do ?” Avec ça, il reprend où il s’est arrêté. Zéro downtime.
10. Sub-agents avec scope, pas liberté
Quand je spawn des sub-agents :
- Définir exactement ce qu’ils peuvent toucher
- Donner des critères de succès clairs
- Mettre un timeout (sinon ils tournent forever)
- Jamais laisser deux agents écrire dans le même fichier
Les traiter comme des contractors, pas des employés. Brief clair → deliver → done.
Le pattern
Chaque conseil ici c’est de la STRUCTURE, pas des prompts. Ton agent est aussi bon que l’infrastructure autour.
C’est exactement ce que j’ai appliqué cette semaine. Et ouais, ça change tout.
Source : @Nicolasfrost