Tout le monde a accès à Claude Sonnet. Tout le monde a accès à GPT-4o. Même clé API, même endpoint, même modèle. Pourtant certains agents tournent en prod depuis 18 mois sans broncher, et d'autres s'effondrent dès qu'on touche à quelque chose.
@rohit4verse a mis le doigt dessus : le modèle n'a jamais été le moat. Ce qui différencie, c'est le harness et le contexte.
Harrison Chase (LangChain) a posé cette thèse en premier. @rohit4verse l'a enrichie avec ce que les posts théoriques évitent soigneusement : ce que ça donne quand tu dois migrer en prod.
Le modèle, c'est la commodité
Harrison Chase découpe l'architecture d'un agent en trois couches : le modèle, le harness, le contexte. La première couche est la seule que tout le monde compare. C'est aussi la moins différenciante.
Un LLM aujourd'hui, c'est une dépendance comme une autre. Tu peux le swapper. Sauf que swapper ne veut pas dire "changer une variable d'environnement" : ça veut dire reconstruire.
@rohit4verse l'a fait. Migration Anthropic vers un modèle open-source auto-hébergé. Son verdict : le harness doit être reconstruit "in so many ways". Pas ajusté. Reconstruit. Les comportements changent, les formats de réponse dérivent, les prompts système qui fonctionnaient parfaitement avec Claude produisent des sorties incohérentes sur un modèle différent, même si les deux sont "SOTA" sur les benchmarks.
Si tu veux aller plus loin sur ce que ça coûte de faire tourner un LLM en local plutôt que via API, on avait mesuré 20 tok/s sur un mini PC AMD à 350$ -- c'est le plancher à connaître avant de décider.
Le harness, c'est là que ça se joue
Le harness, c'est tout ce qui entoure l'appel au modèle : gestion des tools, orchestration des étapes, retry logic, format des sorties. La colle entre le LLM et le reste du système.
Ce qui le rend difficile à construire, c'est qu'il est couplé au modèle par nature. Les quirks de Claude (sa tendance à sur-expliquer, son respect des instructions système) ne sont pas les mêmes que ceux de Mistral ou de LLaMA 3. Un harness bien calibré pour Anthropic exploite ces comportements. Quand tu changes de provider, tu perds cet alignement.
La conséquence pratique : si tu construis un agent sérieux, le harness doit être pensé comme une couche d'abstraction, pas comme du glue code. Ce que @rohit4verse appelle "a framework or an architecture that is uniform" -- une interface stable entre ton système et le modèle sous-jacent, quel qu'il soit. C'est exactement ce qu'on creuse dans Agent Skills : forcer ton agent IA à bosser comme un senior engineer.
Le contexte, c'est la mémoire de travail
La troisième couche, c'est le contexte : ce que l'agent sait à chaque instant. Pas les poids du modèle, pas l'architecture d'exécution -- le contenu injecté dans la fenêtre, les résultats des steps précédents, les données métier, l'état de la conversation.
C'est là que vivent les vraies décisions produit. Quel contexte injecter ? Quand le tronquer ? Comment le structurer pour que le modèle en tire le maximum ? Deux équipes avec le même modèle et le même harness peuvent produire des résultats radicalement différents juste sur cette couche.
C'est aussi la couche la plus difficile à auditer. Un bug de harness se voit dans les traces. Un contexte mal construit se voit dans la qualité des sorties, ce qui est beaucoup plus subjectif à diagnostiquer.
Formation
Intégrez LLM dans votre workflow
Workshop pratique sur vos cas d'usage. Pas de slides génériques — on build ensemble.
La couche que Chase n'a pas mentionnée
@rohit4verse ajoute quelque chose que les posts théoriques sur le harness évitent : en prod, tout ça tourne dans un système. Multi-tenancy, RBAC, isolation des ressources. Quand tu as un seul tenant qui teste ton agent en dev, les problèmes d'isolation n'existent pas. Quand tu en as 200 en parallèle avec des niveaux d'accès différents, le harness doit gérer ça.
C'est la couche qui transforme un prototype impressionnant en produit qui tient. Et c'est aussi celle qui est le plus souvent oubliée dans les articles sur "comment construire un agent".
Choisir un provider aujourd'hui
La vraie question n'est pas "lequel est le meilleur sur les benchmarks". C'est "est-ce que mon harness peut survivre à un changement de provider dans 6 mois ?"
Les providers vont évoluer. GPT-4o a déjà eu plusieurs versions silencieuses qui ont cassé des comportements en prod. Claude 3.5 Sonnet n'est pas Claude 3 Sonnet. Si ton harness est couplé aux comportements spécifiques d'un modèle précis, chaque mise à jour devient un risque.
La réponse de @rohit4verse : abstraire. Construire une couche uniforme qui isole le reste du système des particularités du modèle. Plus de travail au départ, beaucoup moins quand tu dois migrer. Un audit du harness avant la migration coûte infiniment moins cher qu'une reconstruction en urgence.
Consulting
Besoin d'aide pour implémenter ça ?
30 min de call gratuit. On regarde votre cas, on vous dit si ça vaut le coup.
Une nuance honnête
La thèse harness+contexte > modèle est vraie. Elle est aussi parfois utilisée pour minimiser l'importance du choix du modèle, ce qui est une erreur.
Pour des tâches de raisonnement complexe, de code generation avancé, ou de multi-step planning, la qualité du modèle de base reste un facteur. Un harness excellent avec un modèle médiocre a un plafond. Ce que la thèse dit correctement, c'est que la plupart des équipes n'ont pas encore atteint ce plafond -- elles butent sur le harness et le contexte bien avant.
Sur les comportements internes de Claude en prod, on avait creusé pourquoi certains comportements du modèle résistent à l'ingénierie de contexte. C'est la limite de la thèse, et elle est réelle.
La commoditisation des modèles est un fait. Elle ne rend pas le choix du modèle trivial -- elle déplace juste où se jouent les décisions importantes.
Communauté
Rejoins les builders IA
Tips, prompts, retours d'expérience. Le Telegram des gens qui buildent avec l'IA.
