Pourquoi les frameworks d’agents IA sont-ils si complexes ? Il faut un framework révolutionnaire comme Rails

Principaux problèmes actuels des frameworks d’agents IA

• Épuisement de la fenêtre de contexte
  • Lors de tâches complexes, le modèle oublie son objectif initial
  • Hallucinations, boucles infinies
• Rôle de simple wrapper du framework
  • Le choix du modèle, du fournisseur d’embeddings, la structuration des outils, etc., sont laissés aux développeurs
  • Cela va à l’encontre du principe « Don’t make me think »
• Confusion causée par un trop grand nombre d’outils
  • L’évaluation d’options inutiles gaspille le contexte

Solution proposée : une architecture centrée sur les sous-agents

• Utiliser les sous-agents comme des citoyens de première classe
  • Délégation naturelle, comme avec un appel de fonction
  • Ils disposent d’un contexte indépendant → le parent conserve sa capacité de concentration
  • Exemple : un sous-agent de recherche dans le codebase → ne renvoie que les chemins de fichiers pertinents
• Effets
  • Agent unique : consomme 90 % du contexte
  • Avec des sous-agents : le contexte du parent n’utilise que 25 %

Application de la leçon de Rails : Convention over Configuration

• Priorité aux conventions par défaut
  • Sélection automatique du modèle (selon la complexité de la tâche)
  • Héritage parent-enfant du budget de contexte
  • Création automatique de checkpoints pour les opérations risquées
• Introduction d’archétypes (Archetype)
  • Searcher : outils de recherche uniquement
  • Writer : outils d’écriture uniquement
  • Researcher : accès web uniquement → évite la surcharge d’outils

Principes de conception pratiques

• Conception centrée sur la tâche
  • Au lieu de « Quel modèle utiliser ? », partir de la tâche réelle (ex. : validation d’un formulaire d’inscription)
• Caractère temporaire du contexte des sous-agents
  • Seul un résumé du travail intermédiaire est renvoyé au parent
• Distinguer outils et sous-agents
  • Outils : sans état (formatage de date, parsing JSON)
  • Sous-agents : nécessitent itération et jugement (recherche, analyse)

Choix technologique : TypeScript

• Renforcement de la sûreté de typage (Branded types, discriminated unions)
• Compatibilité avec l’écosystème d’outils de développement (VS Code, etc.)
• Possibilité de compiler des exécutables autonomes avec Bun

Défis non résolus

• Partage de contexte entre sous-agents (base de connaissances projet)
• Collaboration entre agents pairs (transmission de messages)
• Évaluation des agents (capture/relecture de scénarios, critères de réussite, de cohérence et de préférence)

Conclusion

• Un framework ne doit pas ajouter de la complexité, mais fournir la « bonne complexité »
• Comme Rails, un framework révolutionnaire peut transformer le développement d’agents
• Réduire au minimum le travail de plomberie → se concentrer sur les problèmes essentiels

[nomak]

En 2026, peut-être qu’un nouvel outil sortira, non ? Ce ne sera pas comme Rails, mais sans doute plus abstrait… J’attends ça avec impatience.

[ahwjdekf]

Les frameworks d’agents… le nom est pompeux, mais au final ce ne sont que des outils qui délèguent au LLM. C’est une coquille vide.

[click]

Rails est pratique parce qu’il impose des conventions et opère beaucoup de magie sous la couche d’abstraction, avec le compromis d’une baisse de performances, mais cela ne se traduit pas immédiatement par une dépense directe.
En revanche, si le framework choisit lui-même le modèle, qui prendra la responsabilité d’une explosion de la consommation de tokens… ?