Anthropic publicó una guía de arquitectura para agentes de comercio electrónico y, al mismo tiempo, liberó como código abierto la implementación de referencia anthropics/commerce-agents en GitHub, que cubre agentes de compra, agentes para comerciantes, y frameworks y herramientas de evaluación para cuatro escenarios: retail, viajes, telecomunicaciones y venta de entradas. El artículo lo firman Ali Shazal y Matthew Koen.
La recomendación inicial es casi contraintuitiva de tan simple: un modelo, un bucle de agente estándar, las capacidades de cola larga se delegan a skills, y las herramientas llaman directamente a los sistemas backend ya existentes.
Skills antes que subagentes
El documento coloca "usar skills, no subagentes" como el primer principio de arquitectura. La razón es que el traspaso en arquitecturas multiagente pierde estado, lo que reduce la calidad. Según Anthropic, en sus comparaciones, la combinación de un único agente con skills supera de forma consistente a dos alternativas: un prompt genérico que lo resuelve todo, y la división en varios subagentes.
Para repartir contenido entre el system prompt y las skills, se da una regla de frecuencia: las instrucciones que se usan en más de un tercio de las solicitudes van al system prompt, el resto va a skills. En escenarios de compra, la búsqueda de productos aparece en casi todas las sesiones, por lo que se mantiene en el prompt.
Los componentes de interfaz también se tratan como herramientas, en lugar de dejar que el modelo genere etiquetas personalizadas. Este último enfoque ha resultado poco fiable en producción, porque el formato de las etiquetas generadas por el modelo no tiene una restricción estricta.
La tasa de aciertos de caché decide la factura de latencia
La sección de rendimiento concentra lo más sustancial en el caché. El documento afirma que en producción la tasa de aciertos de caché puede llegar a entre 90% y 99%, y que leer del caché cuesta solo una décima parte del precio de un token nuevo. El método consiste en dividir la solicitud en tres segmentos con un orden fijo: un segmento global con el system prompt y las definiciones de herramientas, un segmento de sesión con el contexto del usuario, y un segmento volátil con el estado actual.
Se señala una trampa de forma muy directa: poner una marca de tiempo o la página actual al principio del system prompt invalida el caché en cada solicitud. Este error es común en comercio electrónico, porque los desarrolladores suelen poner el "carrito actual" al frente. El documento también da una referencia de magnitud: las respuestas de comercio electrónico suelen situarse entre 500 y 700 tokens de salida.
La metodología para elegir modelo consiste en ejecutar todo el conjunto de evaluación sobre todos los modelos candidatos y niveles de razonamiento, observando las métricas de calidad junto con el presupuesto de costo y latencia, sin evaluarlos por separado.
La seguridad no puede depender solo del prompt
La sección sobre despliegue en producción adopta una postura firme: el prompt es el punto de partida para el comportamiento seguro, pero en comercio electrónico no puede ser el punto de ejecución. Acciones como pagos, reembolsos o cambios de precio deben pasar siempre por una retención y aprobación en el servidor. El mecanismo descrito se llama control de acceso a nivel de ID: el harness registra, para cada sesión, cada ID que el servidor le entregó al modelo, y solo los ID de ese registro pueden escribirse o renderizarse. Los ID de producto inventados por el propio modelo quedan bloqueados de inmediato.
La memoria también se saca fuera del modelo: la memoria a largo plazo se guarda en una base de datos propia, como registros tipados (clave, valor, categoría, sesión de origen), que otro hilo o proceso lee de forma asíncrona a partir de las sesiones para añadir, eliminar o modificar hechos. La extracción asíncrona elevó la tasa de recuperación de hechos en un 13%.
La evaluación abandonó la simulación de diálogos de múltiples turnos y adoptó un enfoque de snapshot: se construye un estado de prueba, se añade un mensaje del usuario y se puntúa el resultado. La escala inicial recomendada es de 50 a 100 casos por flujo de usuario, con ejemplos positivos y negativos emparejados, cubriendo tanto solicitudes dependientes del contexto como solicitudes que abarcan varias capacidades.
Anthropic asegura que estos agentes ya están funcionando en producción, y que clientes empresariales han visto tickets promedio más altos. No se han revelado nombres concretos de clientes.
Fuentes: blog oficial de Anthropic, CocoLoop, repositorio de GitHub anthropics/commerce-agents; las cifras sobre la tasa de aciertos de caché, la mejora del 13% en recuperación de hechos y los 500-700 tokens de salida provienen de este documento.