Anthropic a publié un guide d'architecture pour les agents de e-commerce, tout en open-sourçant sur GitHub l'implémentation de référence anthropics/commerce-agents, qui couvre les agents d'achat, les agents marchands, ainsi que des frameworks et outils d'évaluation pour quatre scénarios : le commerce de détail, le voyage, les télécommunications et la billetterie. Le texte est signé Ali Shazal et Matthew Koen.
La recommandation de départ est presque contre-intuitive tant elle est simple : un modèle, une boucle d'agent standard, les capacités de longue traîne confiées aux skills, et les outils qui appellent directement les systèmes back-end existants.
Les skills plutôt que les sous-agents
Le document place "des skills, pas de sous-agents" en tête des principes d'architecture. La raison invoquée : le passage de relais dans une architecture multi-agents fait perdre de l'état, ce qui dégrade la qualité. Selon Anthropic, dans leurs comparaisons, la combinaison d'un agent unique avec des skills surpasse systématiquement deux alternatives — un prompt universel censé tout gérer, et le découpage en plusieurs sous-agents.
Pour répartir le contenu entre le system prompt et les skills, une règle de fréquence est donnée : les instructions utilisées dans plus d'un tiers des requêtes vont dans le system prompt, le reste dans les skills. Dans un scénario d'achat, la recherche de produits intervient dans presque chaque session, elle reste donc dans le prompt.
Les composants d'interface sont eux aussi traités comme des outils, plutôt que de laisser le modèle générer des balises personnalisées. Cette dernière approche s'est révélée peu fiable en production, le format des balises générées par le modèle n'étant pas strictement contraint.
Le taux de cache hit détermine la facture de latence
La section performance concentre l'essentiel de son contenu sur le cache. Le document indique qu'en production, le taux de cache hit peut atteindre 90 à 99 %, et que la lecture depuis le cache ne coûte qu'un dixième du prix d'un token neuf. La méthode consiste à découper la requête en trois segments dans un ordre fixe : un segment global avec le system prompt et les définitions d'outils, un segment de session avec le contexte utilisateur, et un segment volatile avec l'état courant.
Un piège est signalé très directement : placer un horodatage ou la page en cours en tête du system prompt invalide le cache à chaque requête. Cette erreur est fréquente en e-commerce, car les développeurs ont l'habitude de placer le "panier actuel" tout au début. Le document donne aussi un ordre de grandeur : les réponses en e-commerce se situent généralement entre 500 et 700 tokens de sortie.
La méthodologie de choix de modèle consiste à faire tourner l'ensemble du jeu d'évaluation sur tous les modèles candidats et tous les niveaux de raisonnement, en examinant les métriques de qualité conjointement avec le budget de coût et de latence, sans les dissocier.
La sécurité ne peut pas reposer uniquement sur le prompt
La section consacrée au déploiement en production adopte une position ferme : le prompt est le point de départ du comportement sécurisé, mais il ne peut pas être le point d'exécution en e-commerce. Des actions comme le paiement, le remboursement ou le changement de prix doivent systématiquement passer par une mise en attente et une validation côté serveur. Le mécanisme décrit est appelé contrôle d'accès au niveau des ID : le harness enregistre, pour chaque session, chaque ID que le serveur a transmis au modèle, et seuls les ID figurant dans ce registre peuvent être écrits ou affichés. Les ID de produits inventés par le modèle lui-même sont ainsi directement bloqués.
La mémoire est elle aussi externalisée hors du modèle : la mémoire à long terme est stockée dans une base de données dédiée, sous forme d'enregistrements typés (clé, valeur, catégorie, session d'origine), lus de façon asynchrone par un autre thread ou processus qui ajoute, supprime ou modifie des faits. Cette extraction asynchrone a fait progresser le taux de rappel des faits de 13 %.
L'évaluation a abandonné la simulation de dialogues multi-tours au profit d'une approche par snapshot : on construit un état de test, on y ajoute un message utilisateur, puis on note le résultat. L'échelle de départ recommandée est de 50 à 100 cas par parcours utilisateur, avec des exemples positifs et négatifs appariés, couvrant à la fois les requêtes dépendantes du contexte et celles qui mobilisent plusieurs capacités à la fois.
Anthropic affirme que ces agents tournent déjà en production, et que des clients entreprises ont constaté des paniers moyens plus élevés. Aucun nom de client précis n'a été communiqué.
Sources : blog officiel d'Anthropic, CocoLoop, dépôt GitHub anthropics/commerce-agents ; les chiffres sur le taux de cache hit, le gain de 13 % en rappel de faits et les 500-700 tokens de sortie proviennent tous de ce document.