Code with Claude 2026 : l'avenir des agents devient réel

J'ai failli ne pas regarder le keynote en direct.

C'était le mercredi matin 6 mai, mon pipeline d'agents était déjà en cours et j'avais un livrable client à livrer avant le déjeuner. Le livestream Code with Claude se trouvait dans un onglet à côté de mon terminal, en sourdine, pendant que je nettoyais un flux de travail de contenu multi-agents. Puis j'ai vu la diapositive.

Un seul mot, blanc sur fond sombre, dans le genre de typographie qu'on n'éclate que pour quelque chose qu'on a retenu. Rêver.

J'ai rétabli le flux et regardé Ami Vora, directeur des produits de Anthropic, décrire ce qui était, sur papier, une fonction de mémoire. Au moment où elle en est arrivée au moment où les agents examinent leurs propres sessions passées pour trouver des modèles, identifier les erreurs récurrentes et conserver des informations utiles sur la mémoire à long terme de toute une équipe, j'avais arrêté de faire semblant de travailler. Les trente minutes suivantes ont été marquées par trois autres annonces qui ont discrètement redessiné les lignes de ce qu'un « agent de production AI » est autorisé à être en 2026.

Si vous n'avez vu que les gros titres de la conférence Code with Claude, vous en êtes probablement reparti en pensant "ah, plus de trucs d'agents, limites de tarifs doublées, accord SpaceX, cool". Ce n'est pas ce qui s'est passé à San Francisco ce jour-là. L'histoire du calcul (que j'ai décrite en détail dans mon article sur le doublement des limites de taux Claude Code et l'accord de calcul SpaceX](/content/mejba.me/claude-code-rate-limits-doubled-spacex.md)) était la partie la plus bruyante. La feuille de route des capacités des agents – rêve, boucles de résultats, orchestration multi-agents en tant que primitive gérée, plus un aperçu du futur modèle faisant allusion à un contexte « infini » et une réelle concentration sur le jugement technique – était la partie la plus discrète. Et la partie calme est ce qui change la façon dont je vais construire pour le reste de l'année.

Ceci est mon récapitulatif et mon interprétation. Pas de sténographie. Il ne s’agit pas d’une réécriture d’un communiqué de presse. Qu'est-ce qui est réel, qu'est-ce qui est en avant-première, ce que je vais extraire de ma propre pile dans les 30 prochains jours et ce que je veux voir avant de croire aux plus grandes promesses.

Qu'était réellement Code with Claude

Une orientation rapide pour tous ceux qui l'auraient manqué. Code with Claude est la conférence annuelle des développeurs de Anthropic. L'édition 2026 s'est déroulée le 6 mai à San Francisco (avec Londres le 19 mai et Tokyo le 10 juin encore en avance), si vendue que l'équipe a ajouté une deuxième journée SF et a été diffusée en direct et gratuitement pour tous ceux qui se sont inscrits. Selon l'ordre du jour officiel, l'accent était mis sur un objectif précis : les agents de codage, les flux de travail des agents et l'avenir de l'ingénierie logicielle en plus de Claude.

Cela vaut la peine d'être signalé dès le départ, car la rumeur est devenue bruyante : le discours d'ouverture a été prononcé par Ami Vora, CPO de Anthropic, et non par Mike Krieger (qui est devenu co-dirigeant Anthropic Labs plus tôt cette année). Le cadrage de Vora était délibérément humble. "Aujourd'hui, il s'agit de savoir comment nous améliorons le fonctionnement de nos produits pour vous", a-t-elle déclaré, ce qui a donné le ton : pas d'annonce de nouveau modèle, pas de référence en gros, juste un tour d'horizon de ce qui est expédié et de ce qui nous attend. Le volume de API est multiplié par 17 d'une année sur l'autre sur la plate-forme Anthropic, ce qui est le genre de statistique qui devrait permettre à chaque constructeur de Claude de s'asseoir un peu plus droit.

Ce qui est intéressant, c'est que "pas de nouveau modèle" s'est avéré être la chose la plus honnête qu'elle aurait pu dire. Parce que les quatre changements de capacités annoncés – trois en direct, un en avant-première – modifient ce que vous pouvez expédier plus qu'un autre demi-point sur le banc SWE ne le ferait.

Laissez-moi les parcourir dans l'ordre dans lequel ils m'ont frappé, puis j'aborderai ce que je suis en train de changer.

Rêver : la fonction de mémoire que je simule depuis six mois

C'est ici que j'ai arrêté de faire semblant de travailler.

Anthropic a annoncé rêver pour Agents gérés Claude : un processus en arrière-plan planifié dans lequel un agent examine ses propres sessions passées, identifie des modèles, fait apparaître des erreurs récurrentes et consolide les éléments utiles dans une mémoire à long terme qui persiste d'une exécution à l'autre. Selon le propre cadrage de Anthropic sur le message d'annonce, rêver « fait apparaître des modèles qu'un seul agent ne peut pas voir seul, y compris des erreurs récurrentes, des flux de travail sur lesquels les agents convergent et des préférences partagées au sein d'une équipe ».

C'est cette dernière clause qui est la bonne. Au sein d'une équipe. Pas seulement un agent apprenant ses propres bizarreries, mais plusieurs agents mettant en commun leur expérience.

Pourquoi cela m'a arrêté : j'en construis une version pire à la main depuis six mois.

Ma configuration : je dirige quotidiennement l'agent de contenu Aria (celui qui écrit cet article, divulgation complète) ainsi qu'une petite équipe de flux de travail de spécifications sur Claude Opus. Chaque session significative se termine par un rituel manuel où j'extrait ce qui a fonctionné, ce qui a échoué et ce qui m'a surpris dans un fichier mémoire lu par la session suivante. J'ai écrit sur un mécanisme Claude Code associé dans Claude Code Auto Dream – il s'agit d'une passe de consolidation spécifique à Claude Code. Managed Agents dreaming est la version au niveau de la plateforme, et va plus loin : il ne se contente pas de dédupliquer les notes, il recherche activement des modèles que l'agent lui-même ne peut pas voir lorsqu'il est en cours de session.

Pensez à la différence comme ceci. La mémoire automatique dans Claude Code journalise : l'agent écrit ce qu'il a fait. Auto Dream édite – nettoie le journal pour qu'il soit lisible. Agents gérés Rêver est une thérapie — l'agent (ou un laissez-passer de rêve distinct) examine l'intégralité du journal et demande : « Qu'est-ce que cette personne continue de se tromper ?

Le statut aujourd'hui : aperçu de la recherche, sécurisé, demande d'accès. Personne n’expédie donc des flux de production en plus de rêver cette semaine. Mais l’engagement architectural est le signal qui compte. Anthropic a décidé que les agents qui apprennent de leur propre historique constituent une fonctionnalité de plate-forme de premier ordre, et non un modèle intelligent sur lequel vous vous basez.

Ce que je fais à ce sujet dans les 30 prochains jours : je vais garder ma boucle de réflexion manuelle en cours d'exécution, mais je vais arrêter d'en construire la couche suivante. J'avais un script de consolidation de mémoire entre agents à moitié terminé - essentiellement une tâche cron qui prenait les réflexions quotidiennes de chacun de mes agents et essayait de trouver des modèles partagés. Je tue cette branche. Si Anthropic résout ce problème au niveau de la plate-forme, ma version lancée à la main sera obsolète le jour où Day Dreaming deviendra une version bêta publique. Mieux vaut attendre, exécuter les mêmes charges de travail via leur version et valider avant d'investir davantage de câblage.

Et voici la partie honnête : si rêver fonctionne comme annoncé, le fossé que je pensais construire (orchestration de mémoire personnalisée) vient de devenir une marchandise. C'est très bien. Le véritable fossé n’a jamais été l’orchestration. Il s'agissait des rubriques – les définitions de ce à quoi ressemble un bon résultat pour mes flux de travail spécifiques. Ce qui m'amène à la deuxième annonce.

La boucle de résultats : mon pipeline éditorial, à l'intérieur de la plateforme

Si rêver était la diapositive qui m'a fait perdre ma concentration, les résultats étaient ceux qui m'ont poussé à prendre un cahier.

Le pitch est simple. Vous rédigez une rubrique décrivant à quoi ressemble le succès de la tâche de votre agent. L'agent travaille vers cet objectif. Une instance Claude séparée (un évaluateur, s'exécutant dans sa propre fenêtre contextuelle) évalue le résultat de l'agent par rapport à la rubrique. Si le résultat échoue, l’évaluateur indique exactement à l’agent ce qu’il doit modifier. L'agent prend une autre passe. Bouclez jusqu'à ce que la sortie rencontre la barre. L'évaluateur est indépendant, il n'est donc pas biaisé par le raisonnement de l'agent.

Anthropic a publié des chiffres à ce sujet dans son article d'annonce sur les agents gérés et la couverture de SD Times les a parcourus : les résultats ont amélioré les taux de réussite des tâches jusqu'à 10 points de pourcentage par rapport aux boucles d'invite standard dans leurs tests internes, avec les gains les plus importants sur les tâches les plus difficiles. La génération de fichiers a spécifiquement enregistré +8,4 % sur les sorties .docx et +10,1 % sur .pptx – ce qui est disproportionné pour les flux de travail documentaires d'entreprise où une seule génération échouée consomme du temps de révision humaine.

Voici pourquoi je ne me contente pas d’acquiescer. Je fais déjà ça. Manuellement. Tous les jours.

Mon pipeline de contenu comporte deux passes intégrées. Aria écrit un message en fonction d'une rubrique que je conserve dans l'invite du système : voix, structure, phrases interdites, règles de liaison interne, nombre de mots, vérifications de l'architecture de rétention. Ensuite, je lis le résultat et j'agis effectivement en tant qu'évaluateur distinct : cela correspond-il à la rubrique ? Si non, que manque-t-il ? Renvoyez-le avec une note spécifique. Bouclez jusqu'à ce qu'il soit expédié.

Deux choses changent lorsque cette boucle devient une primitive gérée au lieu d'un rituel manuel.

Premièrement, la boucle se déroule sans moi. J'écris la rubrique une fois. L'agent écrit. Le correcteur évalue. L'agent révise. Je vois la sortie finale post-boucle, pas trois brouillons intermédiaires. Ce que je faisais avec mes yeux et un café à 23h est désormais une propriété de la plateforme.

Deuxièmement – et c'est la partie la plus difficile à ressentir jusqu'à ce que vous l'ayez vécue – la qualité de la rubrique devient le facteur limitant. Aujourd’hui, ma rubrique est principalement dans ma tête, codée sous forme de goût, appliquée de manière incohérente. Chaque fois que j'externalise la boucle, je dois écrire la rubrique. Nettement. Spécifiquement. Pour qu'un modèle distinct puisse l'appliquer sans que je survole. C'est une discipline que j'ai évitée parce que la révision manuelle me permettait de tricher : je pouvais « simplement savoir » ce qui n'allait pas. Les boucles de résultats forcent la rubrique à devenir un artefact.

L'évaluation honnête : cela change la façon dont je structure le travail des agents, pas si je le fais. La forme d'une tâche d'agent en 2026 devient trois choses : invite, rubrique, boucle. Si vous avez écrit des invites et sauté des rubriques, vous avez écrit la moitié facile.

Ce que je fais dans les 30 prochains jours : je formalise ma rubrique Aria. Non pas en tant que section d'invite système, mais en tant que fichier distinct que l'évaluateur peut utiliser. La rubrique de rétention (10 catégories, échelle de 1 à 10) et la sous-rubrique SEO (5 catégories, pondérées) que j'utilise déjà en interne – celles-ci deviennent les entrées littérales de l'évaluateur. Si les résultats donnent ce qu'ils disent, mes brouillons devraient être plus proches de la publication lors de la première passe en boucle gérée qu'ils ne le sont actuellement après ma troisième passe manuelle.

Orchestration multi-agents en tant que primitive gérée

La troisième section du discours d'ouverture est celle où la foule d'ingénieurs présente dans la salle s'est visiblement avancée dans ses sièges.

L'orchestration multi-agents dans les agents gérés permet désormais à un agent principal de décomposer une tâche, de confier chaque sous-tâche à un agent spécialisé (avec son propre modèle, invite et outils) et de les exécuter en parallèle. Chaque sous-agent s'exécute dans une fenêtre contextuelle isolée afin de ne pas polluer le raisonnement du prospect. Le responsable signale l'activité dans le fil de discussion principal ; les sous-threads apparaissent au moment de l'exécution lorsque le responsable décide de déléguer.

Les contraintes, selon la documentation de Anthropic sur les sessions multi-agents (https://platform.claude.com/docs/en/managed-agents/multi-agent), sont pragmatiques : le coordinateur ne peut déléguer qu'un seul niveau de profondeur (la profondeur > 1 est ignorée) et vous pouvez répertorier un maximum de 20 agents uniques dans multiagent.agents (bien que le coordinateur puisse appeler plusieurs copies de chacun). Système de fichiers et conteneur partagés ; fenêtres de contexte isolées par thread de session.

Je dois être honnête sur ma réaction ici, car c'était compliqué.

Je fais déjà de l'orchestration multi-agents. Je le fais depuis des mois. J'ai décrit mon approche dans le [Livre de jeu des équipes d'agents Claude Code] (/content/mejba.me/claude-code-agent-teams-playbook.md) et j'ai exploré une variante encore plus agressive dans [Architecture de l'agent Claude Code Swarm] (/content/mejba.me/claude-code-agent-swarm-architecture.md). Ma plate-forme Aria se coordonne déjà avec les sous-agents de flux de travail de spécifications (exigences, conception, tâches, implémentation, test, juge) pour les fonctionnalités non triviales. Le modèle n'est pas nouveau pour moi. Ma première réaction à l'annonce a donc été, charitablement : "d'accord, vous avez produit quelque chose que je fais déjà."

Puis j'y ai réfléchi pendant une heure et j'ai changé d'avis.

Ce qui est différent dans le fait qu'il s'agisse d'une primitive gérée, ce n'est pas la capacité — c'est la surface opérationnelle. Lorsque j'orchestre localement des sous-agents via Claude Code, je suis propriétaire du cycle de vie : les faire tourner, surveiller leur sortie, les redémarrer lorsqu'ils se bloquent, gérer le transfert de mémoire entre les threads. Lorsque la plateforme en est propriétaire, j'obtiens quatre choses que je n'avais pas :

Vrai parallélisme avec isolation. Ma plate-forme locale a un parallélisme mais mon isolation de contexte fuit — les sous-agents partagent plus d'état que je ne le souhaiterais car tout s'exécute via la même session Claude Code. L'orchestration gérée donne à chaque sous-agent son propre thread de session. 2. Webhooks pour les humains dans la boucle. Anthropic a également fourni la prise en charge des webhooks pour les agents gérés lors de la conférence. Le modèle de production (selon leurs documents) enregistre un webhook qui se déclenche sur session.status_idled, ce qui signifie que votre serveur reçoit un ping lorsque l'agent a terminé ou attend le résultat d'un outil. Cela vous permet de relier l'examen humain à un flux multi-agents sans interrogation.

Pour mon pipeline de contenu, c'est énorme : un agent termine un brouillon, déclenche un webhook, mon système le met en file d'attente pour mon examen et l'agent attend ma réponse user.custom_tool_result avant de continuer. Plus besoin de vérifier les tâches de longue durée. 3. Une seule surface facturable. Je paie actuellement le calcul via mon compte Anthropic ; la comptabilité analytique est répartie entre les différents agents que je dirige localement. Une session multi-agent gérée est un workflow unique facturable. Pour le travail des clients, cela compte plus qu'il n'y paraît : une attribution propre des coûts par flux de travail rend la tarification des engagements client réellement rationnelle. 4. L'agent principal rêve de l'équipe. C'est l'effet de second ordre dont personne ne parle assez fort.

Si le rêve fait apparaître des modèles sur les agents sur la même plate-forme, alors un flux de travail multi-agents apprend de lui-même d'une manière qu'aucune plate-forme roulée à la main ne peut faire. Le responsable remarque que le spécialiste du frontend continue de commettre une erreur spécifique et que l'exécution suivante l'ignore.

Ce que je fais dans les 30 prochains jours : je sélectionne l'un de mes flux multi-agents - probablement ma recherche SEO → brouillon → note → pipeline d'actualisation - et je le porte sur des agents gérés pour le comparer. La version locale Claude Code ne va pas disparaître (elle est toujours meilleure pour le travail de codage en boucle serrée), mais pour les flux de travail de contenu hébergés, planifiés et sans intervention, l'orchestration gérée va gagner uniquement sur le coût opérationnel.

Le détail du Webhook qui compte le plus

Je souhaite consacrer un paragraphe aux webhooks, car le discours d'ouverture les a dépassés et la plupart des récapitulatifs que j'ai lus l'ont également fait.

Les webhooks sont l'élément d'infrastructure ennuyeux qui transforme les agents gérés de « jouets de démonstration » en « éléments qui s'intègrent à de vraies entreprises ». Sans webhooks, vous interrogez (gaspillage), exécutez des agents synchrones uniquement (limitation) ou exécutez votre propre couche de suivi d'état (ce qui va à l'encontre de l'objectif de géré). Avec les webhooks, votre agent peut fonctionner pendant des heures, passer la main à un réviseur humain lorsqu'il atteint un point d'escalade, attendre l'intervention de l'humain via un rappel et reprendre proprement.

Combinez cela avec une orchestration multi-agents et des boucles de résultats et vous obtenez quelque chose qui n'existait vraiment pas pour les constructeurs il y a trois semaines : un flux de travail d'équipe d'agents hébergé, autonome, auto-évalué avec des crochets de révision humaine exactement aux points que vous souhaitez. Ce n'est pas une fonctionnalité. C'est un modèle opérationnel.

Si vous exécutez quelque chose qui devrait être un flux de travail à long terme, parfois supervisé par un humain (production de contenu, contrôle qualité, examen de la sécurité, chemins d'escalade du support client), les webhooks sont l'élément qui vous permet d'arrêter de gérer votre propre file d'attente.

La question Mythos et l'aperçu du modèle futur

Maintenant la partie spéculative. Et je vais être prudent ici, car les rumeurs sur le prochain modèle Claude sont devenues bruyantes et une grande partie de la couverture ne rend pas service à ses lecteurs.

Vora a présenté trois directions dans lesquelles Anthropic investit pour la prochaine génération. D'après la couverture en direct du blog de Simon Willison et corroborée dans les récapitulatifs de la conférence :

Jugement et goût du code plus élevés. Jugement technique, architecture logicielle, maintenabilité — les éléments de référence ne mesurent pas bien.
Des fenêtres contextuelles qui semblent infinies lorsqu'elles sont combinées à une mémoire de haute qualité.
Coordination multi-agent avancée : des agents principaux orchestrant plusieurs spécialistes à la fois, au-delà de ce que les agents gérés prennent actuellement en charge.

Ce sont des directions, pas des fonctionnalités. Aucune date de sortie. Aucun nom de modèle ne leur a été épinglé sur scène. Vora a été explicite : aujourd'hui il ne s'agissait pas d'un nouveau modèle.

Mais la rumeur sur laquelle tout le monde négocie est Claude Mythos. J'ai couvert en détail la fuite de données Anthropic Mythos en mars, lorsque Anthropic a accidentellement divulgué environ 3 000 documents internes, dont un brouillon d'article de blog décrivant Mythos comme « le plus performant que nous ayons jamais construit », en particulier pour la cybersécurité. Mythos Preview a été mis en ligne le 7 avril via le projet Glasswing, un déploiement ciblé de recherche en sécurité. Vora a fait référence à Mythos directement dans le discours d'ouverture (la célèbre anecdote sur la vulnérabilité OpenBSD de 1999). Mythos n’est donc pas une vapeur – il existe aujourd’hui, sous une forme restreinte.

Qu’en est-il de la spéculation de Polymarket « Septembre Claude 5 » ? Voici ce que je peux vérifier à partir des marchés de prédiction que j'ai vérifiés : les traders attribuaient une probabilité implicite d'environ 28 % à Anthropic publiant publiquement Mythos avant le 30 juin, le consensus évaluant une probabilité plus forte pour le troisième trimestre. Le cadrage de "septembre" n'est pas une date difficile, a confirmé Anthropic : il s'agit d'un consensus de marché pondéré par les prix des marchés les plus actifs. Le marché le plus actif "Claude Mythos publié par..." se situait à environ 17 % de chances le 30 juin dernier que j'ai regardé. Rien de tout cela n’est un engagement de libération. Ce sont les parieurs qui interprètent les mêmes signaux que vous et moi lisons.

Ma lecture : considérez le cadrage de septembre comme un pari raisonnable, pas comme une entrée de calendrier. Anthropic n'a annoncé aucun modèle sur scène. Ils ont prévisualisé trois capacités. Si Mythos (ou Claude 5, traités comme des marchés distincts) est livré avant le quatrième trimestre, ces trois capacités sont ce que j'attendrais d'être les principaux différenciateurs.

Maintenant, la partie qui compte vraiment pour moi en tant que constructeur.

Le goût du code : celui qui me tient le plus à cœur

Parmi les trois capacités évoquées, « un jugement et un goût de code plus élevés » est celui pour lequel je paierais en premier. Je le paierais plus cher que le contexte infini.

Voici pourquoi. J'utilise quotidiennement Claude Opus 4.6 sur de vraies bases de code client : monolithes Laravel, applications Next.js, infrastructure d'agents. La fenêtre contextuelle 1M est suffisante pour presque tout ce que je fais. Là où le Claude actuel lutte n'est pas le contexte. C'est un jugement. Spécifiquement:

Choisir le bon niveau d'abstraction du premier coup, au lieu de produire du code techniquement correct mais architecturalement suspect que je dois refactoriser une semaine plus tard.
Savoir quand ne pas ajouter une fonctionnalité. Le Claude d'aujourd'hui est trop impatient. Cela ajoutera un indicateur de configuration car vous avez mentionné que vous voudriez peut-être des options "un jour".
Repérer que deux parties apparemment sans rapport d'une base de code sont en réalité couplées et refuser de modifier l'une sans aborder l'autre.
Repousser l'invite — me disant que mon idée est fausse, voici pourquoi, voici un meilleur chemin. Le Claude actuel repousse les invites peut-être une fois sur vingt. Cela ne suffit pas.

Les benchmarks sont saturés. Je ne suis pas impressionné par un autre point sur le banc SWE. Ce qui m'impressionnerait : un modèle qui, étant donné une demande d'ajout de cache à un service, dit "ce service ne devrait pas être un service - il devrait être un assistant de requête sur le référentiel existant, et voici la différence qui fait les deux." C'est le goût. C'est du jugement. C'est ce qui fait la différence entre un ingénieur senior et un dactylo rapide.

Sceptique mais plein d’espoir, c’est exactement là où j’en suis. J'aurais besoin de le voir sur du code existant, laid et réel - et non sur des suites de référence - avant de croire à l'affirmation du "goût". Mais c'est celui que je veux le plus.

Contexte infini : utile, mais moins que vous ne le pensez

La ligne « fenêtres contextuelles qui semblent infinies » a suscité la réaction la plus forte dans la pièce. Je pense que cette réaction était un peu surcalibrée.

Voici mon point de vue honnête, ayant vécu dans la fenêtre contextuelle 1M depuis sa livraison : 1M est déjà suffisant pour presque toutes les tâches à dépôt unique et à projet unique que j'effectue. Les dépôts sur lesquels je travaille ne rentrent pas dans 1M car ils ne doivent pas être chargés en entier – ils doivent être chargés de manière sélective, avec une récupération intelligente, et le modèle doit savoir quels fichiers demander. Le goulot d’étranglement a cessé d’être lié aux jetons bruts il y a des mois. Le goulot d'étranglement est quels jetons.

Ce que "infini" en fait déverrouille (en supposant que Anthropic l'entend comme je pense qu'il l'entend : mémoire de haute qualité + récupération intelligente + quelque chose qui se rapproche de l'état persistant au fil des sessions) :

Raisonnement croisé-repo. Travailler sur trois dépôts dans une architecture de microservices sans perdre la trace des contrats que chacun expose.
Un agent à long horizon s'exécute. Un agent qui s'exécute pendant des jours sur un projet, conserve tout ce qu'il a appris et n'a pas besoin d'être réinformé à chaque session.
Personnalisation qui persiste. "N'oubliez pas que je préfère l'utilitaire Tailwind d'abord aux modules CSS" - et faites-le rester à chaque interaction sans que je le répète.

Les deux premiers sont des mises à niveau. Le troisième est l'argumentaire du consommateur et je suis moins sûr que cela importera aux utilisateurs expérimentés qui encodent déjà ces éléments dans CLAUDE.md et les invites système.

La combinaison rêve + contexte infini est la partie réellement intéressante. La rétention à long terme sans dégradation de la qualité est un problème difficile. Si Anthropic l'a piraté, l'avantage pratique est que l'agent s'améliore * au fil du temps sur votre travail spécifique, au lieu de réinitialiser la base de référence à chaque session. C'est une forme différente de produit.

Coordination multi-agent avancée

La troisième direction envisagée est la « coordination multi-agent avancée » au-delà de ce que les agents gérés prennent actuellement en charge. Le plafond actuel d'un niveau de délégation profond est probablement la chose la plus évidente à lever : permettre aux sous-agents de générer récursivement leurs propres spécialistes. Que cela soit réellement utile ou que vous obteniez simplement une explosion exponentielle du contexte dépend de la manière dont il est contrôlé.

Ce que je surveillerais : les agents principaux deviennent-ils suffisamment intelligents pour ne pas déléguer alors qu'ils ne devraient pas ? Le mode de défaillance multi-agents actuel n’est pas une coordination insuffisante, mais une coordination excessive. La création d'un sous-agent pour une tâche qui n'a pas besoin de décomposition coûte de l'argent et ajoute de la latence. Le modèle de nouvelle génération est meilleur en matière de coordination multi-agents s’il sait quand le faire en solo.

Quels changements dans ma pile au cours des 30 prochains jours

Du concret, pas du spéculatif. Voici ce qu'il y a sur ma liste :

Tuez la branche de consolidation de la mémoire entre agents. Attendez que les agents gérés rêvant de quitter l'aperçu de la recherche. Ma version roulée à la main sera obsolète ; Il vaut mieux valider par rapport à la plate-forme que de livrer une version pire d'une fonctionnalité dans trois mois. 2. Formalisez les rubriques d'Aria sous forme d'artefacts et non d'invites. Extrayez la rubrique de rétention (10 catégories) et la sous-rubrique SEO (5 catégories) de l'invite du système Aria et dans un rubric.md distinct par type de contenu. Il s’agit du travail de préparation à l’intégration de la boucle de résultats le jour où il sera logique d’un point de vue commercial de migrer. 3. Porter un flux multi-agents vers des agents gérés. Probablement mon pipeline de recherche SEO → brouillon → note → rafraîchissement, car c'est le pipeline le plus bien défini et le plus simple à comparer côte à côte avec mon orchestration Claude Code locale. 4.

Câblez les webhooks dans ma couche de notification. Je n'attends pas de port. La prise en charge des webhooks est désormais disponible pour les utilisateurs d'agents gérés en version bêta publique. Même sur un flux à agent unique, recevoir des notifications session.status_idled au lieu d'une interrogation m'évite une couche de ruban adhésif. 5. Arrêtez d'écrire du code de remplacement de goût dans mes invites. J'inclus actuellement des conseils verbeux de jugement architectural dans les invites de mon système ("préférez X à Y parce que Z"). Si le prochain modèle améliore véritablement le goût du code, ces instructions deviendront du bruit. Je vais les conserver pour l'instant mais les marquer comme "supprimer sur Claude 5".

Notez ce qui n'est pas sur la liste : désactiver Claude Code localement, tout reconstruire sur les agents gérés, parier sur le rêve. La bonne solution consiste à maintenir la plate-forme existante en fonctionnement et à migrer les charges de travail une par une, à mesure que les primitives gérées font leurs preuves sur le trafic de production. J'ai appris cela à mes dépens en 2024 lorsque j'ai migré un flux de travail client vers une nouvelle fonctionnalité qui est devenue obsolète quatre mois plus tard.

Ce que je veux voir avant de croire aux plus grandes promesses

Je ne vais pas prétendre que la conférence ne m'a pas convaincu. Ce n’est pas le cas. Mais voici ce qui comblerait l’écart restant entre « un aperçu intéressant » et « je parierais un quart de chiffre d’affaires là-dessus » :

Pour rêver, je veux voir des mesures sur la dérive de la mémoire. Un agent qui rêve depuis 90 jours est-il réellement plus performant sur la même tâche qu'un nouvel agent ? Ou bien la consolidation introduit-elle ses propres échecs au fil du temps ? Le billet de blog de Anthropic fait la lumière sur les données de performances à long terme.

Pour les boucles de résultats, je souhaite voir les modes d'échec. Que se passe-t-il lorsque la rubrique est mauvaise ? Que se passe-t-il lorsque l’agent et l’évaluateur ne sont pas d’accord mais que tous deux ont tort ? L'ascenseur de 10 personnes est génial ; le mode de défaillance longue traîne vous indique si vous pouvez le déployer en production sans survol.

Pour l'orchestration multi-agent, je souhaite voir la courbe des coûts. Cinq agents en parallèle, ça sonne bien jusqu'à ce que vous réalisiez que la facture est 5x. L'économie ne fonctionne que si l'agent principal est vraiment doué pour ne pas paralléliser les tâches qui n'en ont pas besoin. J'aimerais voir les chiffres sur les tâches par dollar pour les multi-agents gérés par rapport aux mono-agents sur la même charge de travail.

Pour "contexte infini" + rêver, je veux un benchmark reproductible. "Feels infinite" est une déclaration d'ambiance. Montrez-moi la précision de la récupération à la barre des 10 millions de jetons et j'adhérerai.

Pour Mythos / jugement de nouvelle génération, je veux le voir sur une base de code héritée que je connais intimement. Pas le banc SWE. Il ne s'agit pas d'un ensemble de tests organisé. Une véritable application Laravel, vieille de 8 ans, que j'utilise pour un client. Si Mythos peut suggérer le bon refactor pour ce code, je croirai à l'affirmation du goût. En attendant, considérez cela comme du marketing.

Pourquoi les annonces silencieuses comptaient plus que les annonces bruyantes

Revenez à l’ouverture. J'ai failli ne pas regarder le discours. Puis j'ai vu la diapositive de rêve.

Voici ce que je veux que vous reteniez si vous ne lisez rien d'autre. L'histoire du calcul - SpaceX, les limites de débit doublées, le bit du centre de données orbital - a fait la une des journaux car elle est tangible et facile à écrire. Mais chaque constructeur Claude que je connais disposait déjà de suffisamment de calcul. Ce n'était pas la contrainte. La contrainte était la suivante : comment puis-je amener un agent à apprendre de son propre travail, évaluer son propre résultat, se coordonner avec d'autres agents et s'intégrer à mes systèmes réels sans que je sois en service ?

La conférence Code with Claude a répondu à ces quatre questions. Pas d'une manière qui se fait. D'une manière qui est désormais une priorité de la plate-forme, avec des primitives concrètes livrées aujourd'hui en version bêta publique ou en aperçu de recherche.

L’aperçu du futur modèle – goût, contexte infini, multi-agent avancé – est l’arc le plus long. Mythos, Claude 5, peu importe comment ils finissent par l'appeler, atterrit quand il atterrit. La date de Polymarket en septembre est une supposition. Les capacités sont l'engagement.

Si vous créez des agents en 2026, la question à se poser n'est pas « dois-je changer d'outil ? La question est : que devient possible lorsque la mémoire persiste, lorsque les agents s'évaluent eux-mêmes, lorsque des équipes de spécialistes se coordonnent sans ma supervision et lorsque le modèle sous-jacent fait l'objet d'un véritable jugement technique ? Quoi que vous construisiez avec ces quatre éléments, commencez à le concevoir maintenant. La forme de la plate-forme sur laquelle vous le déployerez commence à se définir. Au cours des douze prochains mois, ceux qui ont conçu contre les nouvelles primitives devancent ceux qui continuent de construire autour des anciennes.

J'ai un fichier de rubrique à écrire.

Questions fréquemment posées

De quoi rêve Claude et quand puis-je l'utiliser ?

Dreaming est un processus en arrière-plan planifié pour les agents gérés Claude qui examine les sessions passées, identifie les modèles et les erreurs récurrentes et consolide les informations utiles sur la mémoire à long terme partagée au sein d'une équipe. Il est actuellement en aperçu de recherche sur la plate-forme Claude avec accès sécurisé – les développeurs doivent en faire la demande. Pour un aperçu complet de ce que le rêve change pour les constructeurs, consultez la section sur les rêves ci-dessus.

Quand a eu lieu la conférence Code with Claude et qu'a-t-elle été annoncée ?

Code with Claude 2026 a eu lieu le 6 mai à San Francisco (avec Londres le 19 mai et Tokyo le 10 juin toujours au programme). Anthropic a annoncé quatre changements de capacités d'agent : le rêve, les boucles de résultats (tous deux en version bêta publique), l'orchestration multi-agents avec prise en charge des webhooks (bêta publique) et un aperçu du futur modèle mettant l'accent sur le goût du code, le contexte infini et la coordination multi-agent avancée.

Claude 5 ou Claude Mythos sortira-t-il en septembre 2026 ?

Anthropic n'a pas confirmé de sortie en septembre 2026 pour Claude 5 ou Mythos. Les marchés de prédiction des polymarchés impliquaient une probabilité d'environ 28 % de publication publique de Mythos d'ici le 30 juin, avec des prix plus élevés vers le troisième trimestre. Mythos Preview est déjà disponible sous forme restreinte via le projet Glasswing pour la recherche sur la cybersécurité. Considérez le cadrage de septembre comme une spéculation de marché et non comme un engagement calendaire.

Qu'est-ce que la boucle de résultat Claude et comment fonctionne-t-elle ?

La boucle de résultats permet à un agent de s'auto-évaluer par rapport à une rubrique écrite. Une instance d'évaluation Claude distincte s'exécute dans sa propre fenêtre contextuelle, note le résultat et l'agent révise jusqu'à ce que la rubrique soit respectée. Anthropic a signalé une amélioration de la réussite des tâches jusqu'à 10 pp par rapport aux boucles d'invite standard sur les tests de performance internes, avec les gains les plus importants sur les tâches les plus difficiles. Disponible dès maintenant dans la version bêta publique des agents gérés.

En quoi l'orchestration multi-agent Claude diffère-t-elle de l'exécution de sous-agents dans Claude Code ?

L'orchestration multi-agents des agents gérés exécute chaque sous-agent dans un thread de session isolé avec sa propre fenêtre contextuelle, prend en charge les webhooks pour les étapes humaines dans la boucle et bénéficie du rêve au niveau de l'équipe. Les plates-formes multi-agents locales Claude Code partagent davantage d'états et nécessitent une gestion manuelle du cycle de vie. L'approche locale reste meilleure pour le travail de codage en boucle serrée ; des victoires gérées pour des flux de travail sans intervention à long terme.

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
Portefeuille : mejba.me
Ramlit Limited (solutions d'entreprise) : ramlit.com
ColorPark (conception et image de marque) : colorpark.io
xCyberSecurity (services de sécurité) : xcybersecurity.io

Code with Claude 2026 : l'avenir des agents devient réel