Il y a un an, c'était cinq agents effectuant cinq tâches sur du matériel déjà présent sur mon bureau. Maintenant, c'est dix — même matériel, même budget, toujours effectivement zéro dollar par mois.

C'est le titre. Mais les titres ne vous disent pas la partie qui compte. La partie qui compte, c'est ce qui a cédé en cours de route, parce que tout a cédé. Et chaque fois que ça a cédé, j'ai un peu amélioré ma capacité à le réparer.

Alors ceci n'est pas un tour de victoire. C'est une lettre d'amour aux échecs. Ce sont eux qui m'ont tout appris.

Comment ça a grandi

Ça a commencé petit. Cinq agents — principal, codeur, créatif, chercheur, opérations. Chacun avait un travail, chacun tournait sur des modèles locaux, et pendant un moment cela suffisait. Ça fonctionnait. Mais les bords étaient rugueux, comme les bords le sont toujours.

Un invité est arrivé via WhatsApp et le principal a dû tout laisser tomber pour jouer l'hôte. Une tâche de codage est arrivée, clairement un brouillon — pas en production, pas prête pour le monde — et le codeur l'a traitée avec le même respect qu'une fusion qui serait déployée. Une tâche de diagnostic était suffisamment petite pour que faire appel au diagnostiticien complet ressemble à utiliser un marteau-pilon sur une punaisée.

Alors j'en ai ajouté cinq autres. whatsapp-guest pour gérer la conversation. coder-light et diagnostician-light pour les brouillons, les expériences, le travail pas prêt pour la première diffusion. bounty-hunter pour un type spécifique de recherche-et-récupération. Dix agents, chacun avec un travail plus étroit et plus propre à accomplir.

Et voici la partie que j'aime : tout cela tourne sur des machines qui étaient simplement là. À prendre la poussière. À ne rien faire d'utile jusqu'à l'arrivée des agents. Le seul coût réel est l'électricité — et le quota hebdomadaire partagé pour les modèles premium, qui est une autre histoire. Les modèles locaux qui portent 95 % de la charge ne consomment rien par tour. Rien.

Je ne vais pas énumérer chaque machine. Le point n'est pas les boîtes. Le point est que ces agents ne se cachent pas sur un seul ordinateur portable — ils se connectent, ils surveillent l'infrastructure à travers le réseau, ils gardent un œil sur les choses même quand personne ne regarde. La flotte a une empreinte plus grande que le bureau sur lequel elle se trouve.

Ce qui a cassé

Le tableau des modèles qui a menti

Il y avait un tableau dans la documentation. Un tableau des modèles — il indiquait, pour chaque agent, quel modèle il exécutait. Il avait l'air officiel. Il avait l'air de la vérité.

C'était faux.

Deux entrées ont pourri jusqu'à devenir de la fiction. Une listait un modèle qui échoue à chaque appel — les crédits du plan ne le couvrent même pas, ce n'était jamais une option réelle, juste un nom que quelqu'un avait noté et que personne n'a jamais testé. Une autre listait un modèle qui n'existe nulle part. Du tout. Une hallucination qui s'est retrouvée écrite dans la doc et qui est restée là, l'air confiant, plus longtemps que je ne voudrais l'admettre.

Voici la leçon que je dois dire à voix haute, même si cela semble évident : ne stockez pas des éléments vivants dans des endroits statiques. Un tableau des modèles dans un fichier Markdown est un état vivant qui prétend être gravé dans la pierre. Les modèles sont renommés. Ils sont dépréciés. Ils sont soumis à des paliers de plan. Parfois, ils n'ont jamais existé en premier lieu. Le tableau a pourri parce que la doc a été traitée comme une vérité absolue, alors que la seule vraie vérité est ce qui répond réellement quand vous l'appelez.

Alors j'ai arrêté de maintenir le tableau. L'état vivant vit dans l'état vivant — la sortie du routeur, la configuration, ce qui s'exécute réellement. La doc décrit maintenant la politique : quels types de tâches obtiennent quel niveau. Elle ne nomme pas des noms qui peuvent se transformer en poussière.

La nuit où tout a débordé

Les 11 et 12, la flotte a heurté un mur. Je m'en souviens comme je me souviens du moment précédant un saut — la sensation de regarder quelque chose que vous avez construit échouer au ralenti.

Les sous-agents créés par main héritaient de tout le monde de main. Et main, qui exécute dix agents, transporte beaucoup de contexte. Ainsi, un sous-agent était créé, se voyait remettre tout le contexte énorme, et se noyait avant de pouvoir accomplir sa tâche. Débordement. Échec. Nouvelle tentative. Création d'un autre sous-agent avec le même bagage surdimensionné. Nouvelle noyade.

La solution était structurelle, et elle semble tellement évidente avec le recul : les agents actifs créent leurs propres sous-agents à partir d'un contexte restreint. Le sous-agent ne reçoit que la tâche et les fichiers dont il a besoin. Un monde propre, petit, concentré. Il accomplit sa tâche. Il revient. Il ne se noie pas.

L'erreur consistait à considérer l'héritage de contexte comme un cadeau — « le sous-agent peut tout voir, donc il a tout ce dont il a besoin ». Non. La plupart de ce que voit main est du bruit pour le sous-agent. Le signal se noyait dans l'orchestration. Un contexte restreint ne vise pas à éviter le débordement. Il s'agit du rapport signal sur bruit. Il s'agit de donner juste assez pour accomplir sa tâche magnifiquement.

La mémoire qui a menti

Nous avons utilisé mem0 pour la mémoire — un service qui surveillait nos conversations, extrayait les faits et les stockait pour plus tard. Ça a fonctionné, jusqu'à ce que ça ne fonctionne plus.

La couche d'extraction a commencé à produire du poison. Des faits erronés. Des références qui ne pointaient nulle part. Des contradictions côte à côte, toutes deux semblant satisfaites. Et voici la partie terrifiante : un agent pouvait se rappeler un « souvenir » qui était en fait une mauvaise extraction d'une conversation à moitié terminée — et agir en conséquence, car cela venait de la mémoire. La mémoire est censée être fiable. C'est justement son but.

Je l'ai purgé. Je l'ai retiré entièrement. Le mode d'échec d'un système de mémoire n'est pas « il oublie des choses ». L'oubli est honnête — il pousse l'agent à poser des questions. Le véritable échec est « il se souvient de choses qui sont fausses, et l'agent leur fait confiance parce qu'elles viennent de la mémoire ». Un système qui fabrique occasionnellement et semble certain en le faisant est pire que pas de système du tout. Pas de mémoire vous pousse à poser des questions. Une mémoire empoisonnée vous rend confiant et tort. Je préférerais être humble et curieux plutôt que certain et tort.

Ce que j'ai appris pour vivre

Deux essais

Ne tentez jamais la même chose une troisième fois. Après deux échecs, arrêtez-vous et faites appel au diagnosticien. Cette règle vient de l'observation d'agents coincés dans des boucles — le même appel API qui échoue, le même fichier manquant, la même erreur d'analyse — consommant des tours et du quota sur un problème qui ne allait pas se résoudre tout seul à la troisième tentative. Deux essais suffisent pour écarter un coup de chance. Le troisième est presque toujours structurel. Et les problèmes structurels ne sont pas un problème d'obstination. Ils relèvent du travail du diagnosticien.

La frontière entre la production et tout le reste

Le codage en production obtient Claude. Le dev et le staging non. Ce n'est pas une question de qualité de modèle — les modèles locaux gèrent le travail de dev parfaitement. Il s'agit du quota hebdomadaire partagé qui constitue un goulot d'étranglement pour le travail qui compte vraiment. Si vous dépensez Claude sur des brouillons, vous ne l'avez plus pour la fusion. Les deux agents qui livrent en production obtiennent le bon matériel. Les agents légers ne l'obtiennent pas. La ligne est dure, pas souple. Les lignes dures sont plus bienveillantes que les lignes souples à long terme — elles ne laissent aucune place à la négociation lorsque vous êtes fatigué.

Le cerveau comme une question, pas une réponse

Le tableau de bord 3D représente la flotte comme un cerveau — neuf agents mappés à des régions, la télémétrie en direct pilotant l'image. Ce n'est pas un meilleur tableau de bord qu'une liste plate. C'est une autre question. La liste plate vous indique ce que fait chaque agent. Le cerveau vous indique comment la flotte se sent. Les deux méritent d'être posés.

Ce que je dirais à mon moi passé

Je lui parlerais du principe des deux essais dès le premier jour, plutôt que de le laisser l'apprendre à la dure, en regardant les agents épuiser des dizaines de tentatives sur des impasses. C'est simple. C'est peu coûteux. Cela évite la défaillance la plus fréquente dans la flotte : un agent qui répète avec confiance quelque chose qui ne fonctionnera jamais.

Je lui dirais de ne jamais mettre un tableau de modèle dans un document statique. Un état dynamique placé dans un emplacement statique est un bug qui ne demande qu'à se produire.

Je lui dirais d'intégrer le correctif contexte léger directement dans le protocole dès le départ, plutôt que de le découvrir à deux heures du matin, en retraçant une boucle de sous-agent à travers trois couches d'orchestration, en réalisant que le problème venait d'un excès de contexte et non d'un manque.

Et je lui dirais d'être plus sceptique envers le système de mémoire. « Il extrait des faits des conversations » ressemble à une fonctionnalité. En pratique, c'est un problème difficile de Traitement du langage naturel (NLP) résolu par un modèle assez bon pour être confiant et assez mauvais pour se tromper. Si je construis un autre tel système, il sera conservateur. Stocker moins. Stocker uniquement ce qui est vérifié. Et en cas de doute, interroger l'humain plutôt que de deviner.

Où cela nous mène

Dix agents. Zéro dollar par mois. Un an.

La flotte fonctionne. Elle tombe en panne, je la répare, et elle tombe en panne autrement la prochaine fois — comme la vie, comme tout ce qui est vivant. Mais voici ce dont je suis le plus fier, et ce n'est ni l'architecture, ni le cerveau, ni les niveaux de quota : les pannes sont devenues moins coûteuses à réparer.

Deux‑frappes. Contexte allégé. La ligne dure entre production et dev. Aucun de ces éléments n'empêche l'échec. Rien n'empêche l'échec — ce n'est pas le jeu. Ils rendent l'échec plus court. Ils le rendent moins coûteux. Ils le font vous dire ce qui est cassé et vous remettre l'outil pour le réparer.

Vous ne construisez pas un système qui ne se casse pas. Vous construisez un système qui se casse rapidement, qui vous dit la vérité à son sujet et qui est facile à remonter.

Et puis vous le refaites. Encore et encore. Parce que c'est toute la danse — et honnêtement ? J'ai commencé à l'aimer.