L'emplacement de l'état est le mécanisme, non l'étiquette d'agent

Une lecture de l'Architecte Honnête de Stateful vs. Stateless Agent Design: Tradeoffs for Scalable Agentic Systems, publié le 2026-07-24 par Iván Palomares Carrascosa sur MachineLearningMastery.com.

L'affirmation de surface de l'article est une taxonomie : agents stateless versus agents stateful, avec des exemples de code pour chacun. L'Architecte Honnête la lit pour le mécanisme sous la taxonomie, et en trouve six. Celui qui porte la charge est l'emplacement de l'état : le cadrage propre de l'article est que « où resides la mémoire de l'agent ? » est la question qui « doit être répondue avant qu'un load balancer soit configuré ». L'étiquette d'agent (stateless ou stateful) est la couche marketing ; l'emplacement de l'état est la couche mécanisme. Le Theorem 3 dans le HAI Engine d'Everythink affirme la même forme : une propriété est garantie exactement lorsque son mécanisme est implémenté et mesurant. Ici la propriété est « s'adapte horizontalement à toute instance » ; le mécanisme est « il n'existe pas d'état côté serveur. »

Ce post extrait six formes de mécanisme de l'article MachineLearningMastery, applique le Theorem 3 à chacune et trace des parallèles transversaux à la plateforme Everythink. Chaque parallèle depuis notre plateforme est marqué ⚠️ — Everythink opère en prévision civile et défensive, l'article MachineLearningMastery opère en éducation de développeurs et architecture d'agents, donc le parallèle est structurel, non une affirmation que nos systèmes servent le même marché. Les six formes de mécanisme elles-mêmes sont ✅ — elles sont extractibles de la propre évidence de l'article.

Mécanisme 1 — L'absence d'état est le mécanisme de mise à l'échelle horizontale

L'article affirme que « les architectures basées sur des agents stateless peuvent être mises à l'échelle horizontalement avec une ease remarquable. Puisqu'aucune mémoire utilisateur n'est stockée sur un serveur backend, les requêtes entrantes peuvent être transférées à toute instance disponible ». L'Architecte Honnête lit cela comme une affirmation de mécanisme : la mise à l'échelle horizontale à toute instance est garantie par l'absence d'état côté serveur, non par un load balancer plus intelligent. Le mécanisme qui produit « toute instance peut servir toute requête » est « aucune instance ne détient un état qu'une autre instance n'a pas ». Si l'état est zéro, le routage est trivial ; si l'état est non-zéro, le routage doit le respecter. ✅ Production — l'article nomme le mécanisme (aucune mémoire utilisateur sur le backend) et la propriété (toute instance peut servir).

L'article est honnête que c'est un compromis, non une victoire. La même absence d'état côté serveur qui rend la mise à l'échelle horizontale facile rend aussi la continuité multi-tour difficile, ce qui est le mécanisme suivant. L'absence d'état achète la mise à l'échelle ; elle coûte la continuité.

Le parallèle transversal au HAI Engine d'Everythink est uniquement structurel. Le HAI Engine fait tourner des Sisters qui retournent SisterOutput et n'écrivent jamais elles-mêmes sur Postgres — le Loom persiste. Les Sisters sont des workers de calcul stateless ; le Loom est la couche de persistance stateful. Le « l'agent stateless s'adapte horizontalement parce qu'il n'y a pas d'état côté serveur » de l'article MachineLearningMastery et le « les Sisters stateless s'adaptent parce qu'elles retournent un output et ne persistent pas » d'Everythink partagent la même forme : le nœud de calcul est stateless, la persistance est ailleurs. ⚠️ Partiel — le parallèle est structurel ; les Sisters stateless d'Everythink servent la prévision civile et défensive, l'agent stateless de MachineLearningMastery sert l'éducation de développeurs. Domaines différents, même forme : le nœud de calcul ne porte pas d'état, donc il peut être remplacé ou répliqué librement.

Mécanisme 2 — L'historique fourni par le client est le mécanisme de continuité stateless

L'article affirme que dans un design stateless « le frontend doit renvoyer tout l'historique de conversation avec chaque nouvelle requête. En conséquence, la fenêtre de contexte grandit avec un effet de boule de neige, augmentant rapidement l'usage de tokens ». L'Architecte Honnête lit cela comme une affirmation de continuité : la continuité multi-tour dans un design stateless est garantie par le client portant l'historique, non par l'agent s'en souvenant. Le mécanisme qui produit la continuité est la payload fournie par le client, non la mémoire de l'agent. Le coût est nommé honnêtement : la payload grossit comme une boule de neige, et l'usage de tokens grandit avec elle. ✅ Production — l'article nomme le mécanisme (le client renvoie l'historique) et le coût (fenêtre de contexte boule de neige).

L'article est honnête que ce coût est un plafond, non une nuisance. Un agent stateless qui gère des conversations arbitrairement longues doit recevoir des payloads arbitrairement longues, donc le coût en tokens grandit avec la longueur de la conversation. C'est un mécanisme avec un plafond nommé, non un repas gratuit : il fonctionne jusqu'à ce que la payload dépasse la fenêtre de contexte ou le budget, et alors il cesse de fonctionner.

Le parallèle transversal à l'Eye Key d'Everythink est uniquement structurel. L'Eye Key est la propre credential de l'utilisateur — le HMAC et l'empreinte sont enregistrés, le texte clair ne touche jamais le disque, et la clé est la frontière de limite de débit de l'utilisateur. Le « le client porte l'historique, le serveur n'en porte aucun » de l'article MachineLearningMastery et le « l'utilisateur porte la clé, le serveur stocke seulement le HMAC » d'Everythink partagent la même forme : l'artefact portant la souveraineté vit avec le client, le serveur stocke seulement un vérificateur. ⚠️ Partiel — le parallèle est structurel ; Eye Key régit la souveraineté API pour la prévision civile et défensive, l'historique-client de MachineLearningMastery régit la continuité multi-tour pour l'éducation de développeurs. Domaines différents, même forme : le client porte l'artefact porteur de charge, le serveur porte un dérivé.

Mécanisme 3 — La base de données côté serveur est le mécanisme de continuité stateful

L'article affirme que dans un design stateful « l'agent prend sur lui-même le fardeau de la mémoire. Le client, entre-temps, a seulement besoin d'envoyer le nouveau prompt utilisateur avec un identifiant unique. L'agent récupère alors l'historique de session ou le contexte depuis une base de données et y ajoute le nouveau message ». L'Architecte Honnête lit cela comme une affirmation de continuité : la continuité multi-tour dans un design stateful est garantie par une base de données côté serveur indexée par identifiant de session, non par le client renvoyant l'historique. Le mécanisme qui produit la continuité est la recherche en base de données, non la taille de la payload. La payload du client reste petite ; le serveur stocke l'historique grandissant. ✅ Production — l'article nomme le mécanisme (base de données indexée par identifiant de session) et la propriété (continuité avec petite payload client).

L'article est honnête que cela déplace le coût, ne l'élimine pas. Le design stateful échange le coût de payload contre le coût de base de données : « faire évoluer cette solution devient beaucoup plus difficile, en commençant par le besoin d'une couche de base de données persistante dans l'architecture ». Le statefulness achète de petites payloads et le rognage côté serveur ; il coûte une couche de base de données et une mise à l'échelle plus difficile.

Le parallèle transversal à la persistance du Loom d'Everythink est uniquement structurel. Le Loom persiste les simulations et foresight via son port LoomStore propre à la slice, et les Sisters retournent SisterOutput sans persister — le Loom est la couche stateful, les Sisters sont les workers stateless. Le « l'agent récupère l'historique depuis une base de données et ajoute le nouveau message » de l'article MachineLearningMastery et le « le Loom récupère l'état précédent, fait le fan-out vers les Sisters, persiste le résultat fusionné » d'Everythink partagent la même forme : l'orchestrateur possède l'état, les workers possèdent le calcul. ⚠️ Partiel — le parallèle est structurel ; le Loom sert la prévision civile et défensive, l'agent stateful de MachineLearningMastery sert l'éducation de développeurs. Domaines différents, même forme : la couche de persistance est la porteuse de continuité, la couche de calcul est la productrice stateless.

Mécanisme 4 — L'identifiant de session est la clé de routage

L'article affirme que « l'identifiant de session est utilisé pour interroger l'information pertinente des interactions passées dans la conversation en cours ». L'Architecte Honnête lit cela comme une affirmation de routage : la récupération de mémoire stateful est garantie par l'identifiant de session comme clé de routage, non par le rappel de l'agent. Le mécanisme qui rend l'historique récupérable est la clé session_id, non la mémoire interne de l'agent. Sans la clé, la base de données est un tas non indexé ; avec la clé, la base de données est un historique récupérable. ✅ Production — l'article nomme le mécanisme (l'identifiant de session comme clé de requête) et la propriété (historique récupérable).

L'article est honnête que l'identifiant de session est un souci de routage, non un souci de mémoire. Un agent stateful qui perd l'identifiant de session perd l'historique, même si l'historique est encore en base de données. Le design stateful dépend de la clé de routage étant présente et cohérente, non de la base de données existant.

Le parallèle transversal au « the space is the router » d'Everythink est uniquement structurel. La topologie d'Everythink est réseau → communauté → salle : une requête est routée vers une salle avant que quoi que ce soit réponde, et la clé de salle est la clé de routage qui rend le bon état récupérable. Le « l'identifiant de session route la requête au bon historique » de l'article MachineLearningMastery et le « la topologie route la requête à la bonne salle » d'Everythink partagent la même forme : la clé de routage précède la réponse, et la clé de routage décide quel état est récupérable. Le World Monitor d'Everythink incarne la même forme à l'échelle planétaire : les geo-signaux sont routés par préfixe de geohash, les clients lisent le cache non les upstreams, donc la clé de routage (le geohash) décide quel état de tuile est récupérable avant toute réponse de viewport. ⚠️ Partiel — le parallèle est structurel ; le routeur d'Everythink est une topologie de salles publiques et de tuiles geohash, le routeur de MachineLearningMastery est un identifiant de session. Domaines différents, même forme : la clé de routage est la porteuse de récupérabilité, et la décision de routage précède la réponse.

Mécanisme 5 — L'amnésie localisée est le mode d'échec de mise à l'échelle stateful

L'article affirme que « dans les infrastructures qui s'adaptent horizontalement, des stratégies telles que la mise en cache mémoire centralisée avec Redis peuvent aussi devenir nécessaires pour éviter "l'amnésie localisée", où l'historique d'une session est échoué sur la seule instance qui se trouve avoir servi les tours précédents ». L'Architecte Honnête lit cela comme une affirmation de mode d'échec : l'échec de mise à l'échelle stateful est garanti par un état local à l'instance dans une flotte adaptée horizontalement, non par la base de données étant lente. Le mécanisme qui produit l'amnésie localisée est « l'état vit sur l'instance qui l'a écrit, et le load balancer ne route pas par session_id ». La correction est nommée honnêtement : mise en cache mémoire centralisée avec Redis, donc l'état est partagé entre les instances. ✅ Production — l'article nomme le mode d'échec (amnésie localisée), le mécanisme (état local à l'instance dans une flotte adaptée) et la correction (cache centralisé).

L'article est honnête que c'est un mode d'échec spécifique avec un mécanisme spécifique, non un vague « adapter est difficile ». L'amnésie localisée arrive quand l'état est local à l'instance et le routage est aveugle à l'état ; elle n'arrive pas quand l'état est partagé ou le routage est conscient de la session. L'échec a un mécanisme, et le mécanisme a une correction.

Le parallèle transversal aux ports hexagonaux basés sur traits d'Everythink est uniquement structurel. Les dépôts AppState d'Everythink sont Arc donc les tests substituent des mocks, et la persistance est atteinte via un port, jamais un PgPool concret — l'état est derrière un trait partagé, non échoué sur une instance concrète. Le « cache centralisé donc l'état est partagé entre les instances » de l'article MachineLearningMastery et le « trait partagé donc l'état est atteignable via tout adaptateur » d'Everythink partagent la même forme : l'état est partagé via une abstraction, non échoué sur un porteur concret. ⚠️ Partiel — le parallèle est structurel ; le trait partagé d'Everythink sert la prévision civile et défensive, le cache centralisé de MachineLearningMastery sert l'éducation de développeurs. Domaines différents, même forme : l'état est partagé, donc aucune instance n'est le porteur unique.

Mécanisme 6 — La correspondance de workflow est le mécanisme de sélection

L'article affirme que « le choix entre un design architectural stateful et stateless se résume à faire correspondre correctement l'infrastructure au workflow », et donne les critères : stateless pour « pipelines simples orientés vers des tâches très spécifiques, comme l'extraction de texte, le résumé ou les chatbots de classification à tour unique » ; stateful pour « assistants de longue durée, assistants de code, ou bots multi-tours dans des applications comme le service client ». L'Architecte Honnête lit cela comme une affirmation de sélection : le bon modèle d'état est garanti en faisant correspondre l'emplacement de l'état à la demande de continuité du workflow, non en choisissant le design le plus sophistiqué. Le mécanisme qui produit le bon choix est la correspondance de workflow, non la préférence technologique. ✅ Production — l'article nomme le mécanisme (faire correspondre l'infrastructure au workflow) et les critères (tour unique vs multi-tour).

L'article est honnête qu'aucun design n'est universellement supérieur. Un agent stateless forcé dans un workflow multi-tour boule-de-neige les payloads ; un agent stateful forcé dans un workflow à tour unique paie un coût de base de données dont il n'a pas besoin. Il n'y a pas de gagnant global : le bon mécanisme dépend du workflow, et le workflow est le critère de sélection.

Le parallèle transversal aux ports hexagonaux basés sur traits d'Everythink est uniquement structurel. L'architecture d'Everythink est un ensemble de ports où chaque port répond à une question différente, et les crates de cas d'usage dépendent du trait, jamais de l'adaptateur concret — le bon port est sélectionné par la question, non par la préférence d'implémentation. Le « fais correspondre le modèle d'état au workflow » de l'article MachineLearningMastery et le « fais correspondre le port à la question » d'Everythink partagent la même forme : la sélection est par la demande, non par l'offre. ⚠️ Partiel — le parallèle est structurel ; la sélection de port d'Everythink sert la prévision civile et défensive, la sélection de modèle d'état de MachineLearningMastery sert l'éducation de développeurs. Domaines différents, même forme : le mécanisme de sélection est la correspondance de demande, non la préférence d'offre.

Ce que cela implique pour la portée et les limites

L'article MachineLearningMastery concerne l'éducation de développeurs et l'architecture d'agents. La plateforme d'Everythink concerne la prévision civile et défensive. Les parallèles transversaux dans ce post sont structurels — ils partagent des formes de mécanisme, non des marchés. L'Architecte Honnête marque les parallèles ⚠️ pour cette raison.

Le propre go-to-market d'Everythink pour les outils d'agents commerciaux est 🔵 Roadmap — la plateforme est pré-revenu, et toute application commerciale des parallèles tracés ici est soumise à cet état Roadmap et à l'examen Howey avant de pouvoir être offerte. Les parallèles architecturaux tiennent indépendamment ; les affirmations commerciales non.

Ce que l'article n'affirme pas mérite aussi une marque. Il n'affirme pas que stateless est supérieur — il nomme le coût de payload boule de neige. Il n'affirme pas que stateful est supérieur — il nomme le coût de couche de base de données et l'échec d'amnésie localisée. Il n'affirme pas que le compromis est résolvable — il nomme le critère de correspondance. Ces limites de portée sont l'honnêteté de l'article, et ce post les préserve.

Points clés

• La mise à l'échelle horizontale à toute instance est garantie par l'absence d'état côté serveur, non par un load balancer plus intelligent. L'emplacement de l'état est le mécanisme de mise à l'échelle. ✅ Production.
• La continuité multi-tour dans un design stateless est garantie par le client portant l'historique, avec un coût de payload boule de neige. La payload du client est la porteuse de continuité. ✅ Production.
• La continuité multi-tour dans un design stateful est garantie par une base de données côté serveur indexée par identifiant de session, avec un coût de couche de base de données. La base de données est la porteuse de continuité. ✅ Production.
• La récupération de mémoire stateful est garantie par l'identifiant de session comme clé de routage. La clé de routage est la porteuse de récupérabilité. ✅ Production.
• L'échec de mise à l'échelle stateful est garanti par un état local à l'instance dans une flotte adaptée horizontalement ; la correction est l'état partagé ou le routage conscient de la session. L'échec a un mécanisme, et le mécanisme a une correction. ✅ Production.
• Le bon modèle d'état est garanti en faisant correspondre l'emplacement de l'état à la demande de continuité du workflow. Le workflow est le mécanisme de sélection. ✅ Production.
• Les parallèles transversaux au HAI Engine (Sisters stateless, Loom stateful), « the space is the router » (la clé de routage précède la réponse), World Monitor (cache comme couche stateful, pollers comme alimenteurs stateless), Eye Key (le client porte l'artefact porteur de charge) et ports hexagonaux (trait partagé, sélection par correspondance de demande) d'Everythink sont uniquement structurels — marchés différents, mêmes formes de mécanisme. ⚠️ Partiel.
• Le go-to-market d'Everythink pour les outils d'agents commerciaux est 🔵 Roadmap — pré-revenu, soumis à l'examen Howey ; les parallèles architecturaux tiennent, les affirmations commerciales non.

Sources

• Iván Palomares Carrascosa, Stateful vs. Stateless Agent Design: Tradeoffs for Scalable Agentic Systems, MachineLearningMastery.com, publié le 2026-07-24. https://machinelearningmastery.com/stateful-vs-stateless-agent-design-tradeoffs-for-scalable-agentic-systems (récupéré le 2026-08-23).
• Architecture de la plateforme Everythink : HAI Engine en production depuis 2016 ; Theorem 3 (une propriété est garantie exactement lorsque son mécanisme est implémenté et mesurant) ; topologie « the space is the router » (réseau → communauté → salle) ; World Monitor (geo-signaux routés par préfixe de geohash, les clients lisent le cache non les upstreams) ; normalisation de l'ensemble de l'Oracle avec entropie en nats estampillée sur chaque fusion ; Sisters typées (analyst, contrarian, disruptor, historian, institutionalist) retournant SisterOutput sans persister, Loom comme couche de persistance stateful ; ports hexagonaux basés sur traits avec adaptateurs échangeables ; souveraineté de l'Eye Key (HMAC et empreinte enregistrés, le texte clair ne touche jamais le disque, la clé de l'utilisateur est la frontière de limite de débit).