El 2 de septiembre de 2026, Anthropic publicó un modelo de comercio agéntico con implementaciones de referencia para un agente de compras y un agente destinado a los equipos comerciales. El proveedor describe una arquitectura articulada en torno a un modelo, habilidades, herramientas de negocio y un conjunto de evaluaciones. El anuncio llega mientras las plataformas intentan trasladar la búsqueda, la comparación y la creación del carrito a una conversación. Sin embargo, la verdadera dificultad no consiste en producir un diálogo convincente: consiste en preservar la exactitud del catálogo, el estado del carrito, el consentimiento y la responsabilidad del pago.
Idea clave: un agente de comercio debe razonar libremente, pero actuar mediante interfaces limitadas y deterministas. El catálogo, los precios, las existencias, las condiciones y el carrito siguen siendo fuentes de verdad externas. El agente propone y coordina; los servicios de negocio validan, persisten y confirman.
1. Qué abarca realmente un agente de comercio
Un agente de compras ayuda al cliente a expresar una necesidad, buscar productos, comparar opciones, formar un conjunto coherente y enviar un carrito al checkout. También puede responder a preguntas posteriores al pedido, como las relativas al seguimiento, las devoluciones o la política de reembolso.
Un agente comercial se dirige a los equipos de la empresa. Analiza las ventas y las existencias, señala un riesgo de desabastecimiento, sugiere una promoción o prepara una campaña. Las acciones externas —cambios de precio, publicación o pedidos a proveedores— deben seguir sujetas a una aprobación explícita.
Estos dos agentes utilizan a veces los mismos datos, pero sus permisos son diferentes. El agente del cliente lee el catálogo y modifica el carrito de la sesión. El agente comercial puede acceder a datos agregados, márgenes y existencias más amplias. Agruparlos bajo una identidad única aumenta el riesgo innecesariamente.
Anthropic anuncia que algunos usuarios de sus agentes han observado carritos hasta un 35 % mayores y una probabilidad de compra un 60 % superior. Estas cifras las presenta el proveedor y no constituyen una garantía aplicable a todos los sectores. Deben servir como hipótesis que se ha de probar, prestando especial atención a los efectos de selección, al margen y a las devoluciones.
El éxito no puede reducirse al tamaño del carrito. Un agente que promueve productos inadecuados puede aumentar el importe inmediato y, al mismo tiempo, perjudicar la confianza, la tasa de devoluciones y el valor del cliente.
2. Una arquitectura sencilla antes de multiplicar los subagentes
La guía técnica de Anthropic propone un modelo principal dentro de un bucle agéntico, equipado con habilidades y herramientas. Desaconseja crear un subagente por ámbito cuando la conversación, las preferencias y el carrito deben mantenerse coherentes a lo largo de los turnos.
Esta recomendación es pragmática. Cada delegación exige transferir contexto, introduce latencia y crea un riesgo de pérdida de estado. Una petición como «sustituye la chaqueta por una opción más barata, pero mantén la entrega del viernes» combina búsqueda, comparación, carrito y logística; no se divide fácilmente en compartimentos.
Las habilidades permiten cargar procedimientos en el momento oportuno: política de devoluciones, guía de compatibilidad, método de comparación o reglas de estilo. Las herramientas realizan las operaciones deterministas: buscar, comprobar existencias, crear un carrito, calcular una entrega o leer un pedido.
Un subagente sigue siendo útil para una tarea autónoma y de gran volumen, como una investigación exhaustiva de la que solo se devuelve el resultado resumido al coordinador. También puede estar justificado cuando un ámbito regulado dispone de su propio agente, su identidad y su proceso de cumplimiento.
La regla consiste en no confundir la modularidad del código con la multiplicación de agentes. Los servicios de negocio siguen siendo modulares; la conversación puede conservar un único responsable mientras el contexto deba permanecer compartido.
3. Mantener el catálogo, los precios y las existencias como fuentes de verdad
El modelo nunca debe inventar la ficha del producto. Recibe resultados estructurados de un motor de búsqueda o de una API de catálogo: identificador, variante, precio actual, disponibilidad, características, condiciones y URL canónica.
La respuesta mostrada debe poder relacionarse con estos objetos. Cuando el agente afirma que un producto está disponible, la interfaz muestra la hora de la comprobación. Antes de añadirlo al carrito y antes del checkout, el servicio vuelve a comprobar el precio y las existencias.
Las herramientas imponen esquemas estrictos. El agente puede solicitar search_products con una necesidad y filtros permitidos, pero no compone una consulta SQL ni una URL interna. Puede solicitar get_offer para un identificador de variante, sin proporcionar él mismo el precio esperado.
Las comparaciones deben distinguir entre hechos y valoraciones. El peso, la garantía y la composición proceden del catálogo. «Más adecuado para un fin de semana con dos niños» es una recomendación del agente que debe justificarse mediante los criterios expresados.
Las reglas comerciales siguen siendo deterministas. Los descuentos, los requisitos de acceso, los gastos y los límites de cantidad los calculan los servicios existentes. El modelo puede explicar el resultado, pero no reescribe la política.
Esta arquitectura forma parte de la preparación descrita en nuestro artículo sobre el comercio agéntico y la exposición del catálogo y del checkout.
4. Hacer que el carrito sea idempotente y explicable
El carrito es un objeto transaccional, no un párrafo de conversación. Tiene un identificador, una versión y un estado conservado por el sistema de comercio. Cada modificación utiliza una clave de idempotencia para que un reintento de red o una repetición del modelo no duplique las cantidades.
Las herramientas deben expresar la intención: añadir una variante concreta, modificar una cantidad, eliminar una línea o aplicar una opción. El servicio comprueba la versión del carrito y rechaza una escritura si otro canal lo ha modificado mientras tanto. El agente vuelve a leer el estado y explica el conflicto.
Antes de una modificación importante, la interfaz presenta sus consecuencias: producto, variante, cantidad, precio unitario, total y eventual sustitución. Hace falta una confirmación cuando el agente cambia una característica esencial, sustituye varios artículos o supera un presupuesto expresado.
Conserve la procedencia de cada línea. El cliente debe saber qué ha solicitado explícitamente, qué ha sugerido el agente y qué ha confirmado. Esta distinción facilita el soporte y evita que una recomendación se perciba como una elección segura del usuario.
Prevea la reversión. Mientras no se haya iniciado el checkout, una operación inversa debe poder restaurar la versión anterior. Los cambios se registran sin almacenar innecesariamente toda la conversación.
5. Separar recomendación, confirmación y pago
El pago constituye una frontera. Anthropic indica que su modelo deja el pago en manos del comerciante, a través del checkout existente o de un proveedor de pagos agénticos. Esta separación debe mantenerse incluso cuando la experiencia parezca continua.
El agente puede preparar el carrito, recoger preferencias de entrega y explicar las condiciones. Un servicio determinista calcula el total final, los impuestos, la entrega y las promociones. El usuario ve un resumen completo antes de confirmar.
La confirmación debe ser reciente y específica. Incluye el comerciante, el importe, la divisa, la dirección, el modo de entrega, los artículos y las condiciones principales. Una frase antigua como «sí, cómpralos» no debe reutilizarse después de modificar el carrito.
Los datos de pago no deben entrar en el contexto del modelo. Se introducen en un componente del proveedor y se tokenizan. El agente solo recibe un estado y un identificador de transacción no sensible.
En caso de ambigüedad, el estado sigue siendo payment_pending en lugar de paid. Los webhooks se procesan de forma idempotente y el estado mostrado procede del backend. Un agente nunca deduce el éxito a partir de un simple cambio visual en el navegador.
Aplique la misma lógica a las acciones comerciales. Una propuesta de reducción de precios o de campaña es un borrador. Una persona autorizada valida el objeto, el alcance, la fecha y el impacto antes de la publicación.
6. Personalizar sin cruzar el límite del consentimiento
La personalización puede mejorar la pertinencia, pero reúne rápidamente preferencias declaradas, historial, comportamiento, presupuesto y contexto. El usuario debe comprender qué datos se utilizan y poder corregir o eliminar una preferencia.
Distinga la memoria de sesión de la memoria persistente. La primera sirve para el proceso actual y caduca. La segunda solo se crea para una finalidad clara, con una base jurídica y una interfaz de gestión. Una preferencia inferida no debe registrarse como un hecho sin validación.
Evite las categorías sensibles y las inferencias que puedan producir discriminación. Un agente no debe ajustar el precio ni la calidad del servicio en función de una supuesta vulnerabilidad. Las reglas de recomendación deben auditarse y ser compatibles con la política comercial.
Anthropic indica que su modelo pretende limitar las sugerencias a productos y precios reales y evitar prácticas manipuladoras de venta adicional. La organización debe traducir este objetivo en controles comprobables: respetar el presupuesto, presentar alternativas más baratas, explicar las comisiones, no crear escasez ficticia y no ocultar una opción pertinente.
Mida también los efectos posteriores a la compra: cancelaciones, devoluciones, reclamaciones y satisfacción. Una personalización responsable optimiza la pertinencia a lo largo del tiempo, no la presión en el momento del checkout.
7. Probar un sistema no determinista con evaluaciones de negocio
Un conjunto de evaluaciones debe cubrir el razonamiento, las herramientas, la interfaz y el resultado transaccional. Empiece por escenarios representativos: solicitudes de varios productos, presupuesto estricto, incompatibilidad, falta de existencias, variante ambigua, entrega urgente, devolución y preguntas sobre un pedido.
Añada casos adversos: instrucciones maliciosas en una descripción de producto, precios contradictorios, herramientas lentas, existencias modificadas durante la tarea, repetición de un webhook e intentos de obtener datos de otro cliente. Compruebe que las políticas siguen aplicándose independientemente de la respuesta del modelo.
Mida la tasa de tareas completadas, la exactitud de productos y precios, la coherencia del carrito, el número de turnos, la latencia, el coste, las confirmaciones solicitadas, los errores transaccionales y las intervenciones humanas. Para evaluar la calidad comercial, siga la conversión, el margen, el tamaño del carrito, la satisfacción, las devoluciones y el valor a treinta o noventa días.
Las evaluaciones sin conexión no bastan. Un piloto A/B puede comparar el agente con la búsqueda clásica, pero debe mantener una experiencia de control y salvaguardas idénticas. Los resultados se segmentan por tipo de solicitud, dispositivo y complejidad.
Examine las conversaciones fallidas mediante una taxonomía: mala comprensión, catálogo incompleto, error de herramienta, elección inadecuada, política bloqueante o interfaz confusa. Este análisis orienta las mejoras mejor que un prompt cada vez más largo.
Cada vez que cambie el modelo, una habilidad, una herramienta o el catálogo, vuelva a ejecutar los escenarios críticos. Un agente es un sistema en evolución; su certificación nunca es definitiva.
8. Desplegar un piloto en noventa días
Durante los primeros treinta días, elija un proceso delimitado y no crítico: una categoría de productos, un país, usuarios voluntarios y un checkout existente. Exponga el catálogo en modo lectura, construya el carrito en un entorno de prueba y defina las evaluaciones.
Del día 31 al 60, abra el piloto con escrituras reversibles en el carrito. Mantenga una validación explícita antes de cualquier transición al checkout. Mida los errores, la latencia, el coste y las solicitudes abandonadas. Corrija los datos y las herramientas antes de aumentar la autonomía.
Del día 61 al 90, añada progresivamente el seguimiento de pedidos o algunas funciones comerciales de solo lectura. Las recomendaciones de precios y campañas siguen siendo borradores. Realice un simulacro de incidente: catálogo no disponible, confirmación duplicada, modelo degradado o política de devoluciones incorrecta.
Los criterios para ampliar el despliegue deben definirse antes del piloto: tolerancia cero a los errores de importe, tasa mínima de tareas completadas, límite de latencia, coste por sesión, satisfacción, tasa de devoluciones y ausencia de desviaciones de las políticas. Un aumento de la conversión no compensa una pérdida de integridad transaccional.
Prevea un modo degradado. Si el modelo o una herramienta no está disponible, el usuario recupera la búsqueda, el carrito y el soporte clásicos sin perder su estado. El agente enriquece el comercio; no debe convertirse en un punto único de fallo.
Conclusión
Los agentes de comercio pueden reducir la fricción entre la intención y la compra, especialmente en solicitudes complejas que combinan varios productos, criterios y etapas. Su valor depende menos de la elocuencia del modelo que de la arquitectura que lo rodea.
El catálogo, los precios, las existencias, el carrito y el pago deben seguir siendo deterministas y verificables. El agente coordina herramientas limitadas, solicita confirmaciones precisas, respeta el consentimiento y se evalúa por la calidad duradera de la transacción. Partitech acompaña a las empresas del comercio en el diseño de estas arquitecturas, la integración con los sistemas existentes y la creación de pilotos medibles y reversibles.
Referencias verificadas el 3 de septiembre de 2026
- Anthropic — «Building commerce agents with Claude», 2 de septiembre de 2026: https://claude.com/blog/claude-for-commerce-agents
- Anthropic — «A guide to the anatomy of effective commerce agents», 2 de septiembre de 2026: https://claude.com/blog/the-anatomy-of-effective-commerce-agents
- Anthropic — repositorio de referencia Commerce Agents: https://github.com/anthropics/commerce-agents