Este artículo abre una serie de tres sobre el blueprint de agentes de comercio que publicó Anthropic. Este primero es el "qué" y el "por qué". Los dos siguientes son el "cómo": las decisiones de diseño y lo que hace falta para salir a producción.
Durante dos años el "asistente de compras con IA" fue, en la mayoría de las empresas que conozco, un demo. Se presentaba en el comité, generaba entusiasmo, y después chocaba con la misma pared: nadie sabía exactamente cómo pasar del chatbot que recomienda productos al sistema que agrega al carrito, respeta el inventario, no inventa precios y no hace nada raro con la tarjeta del cliente.
El 2 de septiembre Anthropic publicó algo distinto a un demo: un blueprint completo para construir agentes de comercio, con implementaciones de referencia, código abierto bajo licencia Apache 2.0, y un artículo técnico que explica las decisiones detrás de cada pieza. Lo leí completo, corrí los ejemplos, y creo que cambia la conversación para cualquier empresa de la región que venda por internet. No porque vaya a construirlo desde cero, sino porque ahora existe un estándar contra el cual medir lo que le ofrecen.
Qué publicó Anthropic exactamente
Son tres piezas que se leen mejor juntas.
Un repositorio en GitHub (anthropics/commerce-agents) con dos agentes listos para adaptar. El agente de compras vive dentro de tu tienda o app: busca en el catálogo, compara productos, arma pedidos de varios artículos a la vez ("necesito carpa, bolsa de dormir y estufa para dos personas por menos de 250 dólares"), agrega al carrito y responde preguntas de servicio al cliente en la misma conversación. El agente del comerciante mira hacia adentro: analiza ventas, alerta sobre inventario, propone precios y promociones, redacta campañas. Con una regla que atraviesa todo: ningún cambio se aplica hasta que una persona lo aprueba.
Cuatro verticales de ejemplo, cada una con su tienda y su portal funcionando: retail, viajes, telecomunicaciones y venta de entradas. No son casos triviales. El de telecom maneja tarifas reguladas que el agente no puede tocar. El de entradas maneja reservas temporales, listas de espera y la obligación de mostrar el precio final con todas las comisiones. Anthropic eligió a propósito verticales donde equivocarse cuesta.
Un artículo técnico, "The anatomy of effective commerce agents", que es el verdadero manual. Explica por qué eligieron una arquitectura y no otra, cómo bajaron latencia y costo, y qué hicieron para que el agente no mueva dinero sin permiso. Es el documento más honesto que he leído de un proveedor de IA sobre lo que cuesta llevar un agente a producción.
Y hay un cuarto elemento que me parece el más subestimado: un plugin para Claude Code que arma el esqueleto del agente con un comando, agrega flujos, escribe evaluaciones y revisa un agente existente. Lo que hace un mes tomaba semanas de arquitectura ahora empieza con una instrucción en lenguaje natural.
Los números y quién está detrás
Anthropic reporta, con base en sus clientes enterprise, dos resultados: carritos 35% más grandes y 60% más probabilidad de completar la compra cuando el cliente interactúa con el agente. Son cifras del proveedor, y como toda cifra del proveedor hay que leerlas con cuidado: no sabemos el punto de partida ni qué se compara con qué. Pero el orden de magnitud es consistente con lo que uno esperaría de un asistente que resuelve el pedido completo en vez de dejar al cliente navegando categorías.
Lo que me parece más relevante que las cifras es la lista de quienes ya están construyendo sobre esto: Shopify, Priceline, Intuit, Visa, Mastercard, Accenture, Square, Wix, Klaviyo, Zomato. Cuando las dos redes de tarjetas más grandes del mundo y la plataforma de e-commerce con más comercios están en el mismo anuncio, no estamos hablando de un experimento. Estamos hablando de la infraestructura sobre la que se va a construir la próxima capa del comercio electrónico.
Dato clave: el blueprint corre en tres modalidades (API directa, Agent SDK y agentes administrados por Anthropic) y está disponible también en AWS Bedrock, Google Cloud Vertex AI y Microsoft Foundry. Para una empresa de la región que ya tiene contrato con alguna de esas nubes, la barrera de compras es mucho menor de lo que parece.
Probablemente no lo vas a construir. Igual te cambia la conversación
Seamos realistas. La mayoría de los retailers y marketplaces de América Latina no tiene un equipo de ingeniería para construir y mantener un agente de este tipo. Vende a través de VTEX, Tiendanube, Shopify, Mercado Libre o una plataforma propia que ya cuesta bastante mantener. Y eso está bien: no todo el mundo tiene que construir.
Pero el manual cambia la conversación de dos maneras concretas.
Primero, fija el estándar de lo que debes exigir. Cuando tu plataforma de e-commerce te ofrezca "el asistente con IA" (y te lo va a ofrecer, si no lo hizo ya), ahora tienes una lista de preguntas con respuesta conocida. ¿El agente usa mi buscador y mi inventario o tiene una copia desactualizada? ¿Puede cobrar por su cuenta o el cobro siempre pasa por un botón que aprieta el cliente? ¿Qué pasa si una reseña de producto contiene instrucciones maliciosas? ¿Cómo evalúan que no invente precios? Si el proveedor no puede responder, no es que su producto sea malo. Es que todavía es un demo.
Segundo, sube el piso de lo que es "normal". Hace un año, un chatbot que respondía preguntas frecuentes en la tienda era un diferencial. Con este blueprint circulando, en doce meses el cliente va a esperar que el asistente arme el pedido completo, recuerde su talla y le avise cuando baje el precio. Las empresas que lleguen tarde a ese piso no van a perder contra la IA. Van a perder contra el competidor que la adoptó primero.
Si sí tienes equipo: empieza más chico de lo que crees
Para las empresas que sí tienen ingeniería propia (los marketplaces grandes, los retailers con equipo digital, las fintech que venden productos), el consejo del propio manual es sorprendentemente conservador: empieza con búsqueda y detalle de producto, y deja todo lo demás en stub.
Esto es importante porque contradice el instinto de "vamos a hacer el agente completo". El blueprint está diseñado para apagar capacidades con un parámetro de configuración. Puedes lanzar un piloto que solo busca y compara, sin carrito, sin memoria, sin checkout. Medir. Y encender la siguiente capacidad cuando la anterior funcione. Cada capacidad apagada es una herramienta menos que el modelo puede usar mal, un flujo menos que evaluar y una superficie de ataque menos que defender.
El otro consejo que rescato para la región: construye sobre lo que ya tienes. El agente no reemplaza tu buscador, tu carrito ni tu sistema de inventario. Los llama. Si tu buscador es malo, el agente va a recomendar mal. Si tu inventario no está en tiempo real, el agente va a prometer cosas que no tienes. La IA amplifica la calidad de los sistemas de base, en ambas direcciones.
Lo que el manual no dice sobre América Latina
El blueprint está pensado para un mercado donde el checkout es tarjeta, el idioma es inglés y la regulación de datos es la estadounidense. Tres cosas que en la región son distintas y que cualquier implementación tiene que resolver por su cuenta.
Los medios de pago. En Brasil el cliente va a querer pagar con Pix. En Colombia con PSE o Nequi. En México, una parte relevante todavía paga en efectivo en OXXO. Y en toda la región, las cuotas sin interés son parte de la decisión de compra, no un detalle del checkout. El agente tiene que entender que "¿cuánto queda en cuotas?" es una pregunta de producto, no de pago. Nada de eso viene en el blueprint. Todo eso es trabajo de adaptación.
El canal. En la región una parte enorme del comercio conversacional ya ocurre en WhatsApp. El blueprint asume una interfaz web con componentes visuales (carruseles, comparadores, mapas de asientos). Llevar eso a un chat de texto con imágenes es un problema de diseño distinto, y probablemente el más importante para una pyme latinoamericana.
Los datos personales. El agente recuerda cosas del cliente: talla, tienda preferida, historial. Eso es dato personal bajo la Ley 1581 en Colombia, la LGPD en Brasil, la LFPDPPP en México. El manual dice, correctamente, que hay que decidir qué se guarda, por cuánto tiempo y cómo el cliente lo ve y lo borra. En la región eso no es una buena práctica. Es una obligación legal desde el día uno.
Recomendación: si vas a evaluar una implementación, propia o de proveedor, pide que la demo corra con tu catálogo real, con tus medios de pago reales y en tu canal real. Un agente que funciona perfecto con la tienda ACME de ejemplo y tarjeta de crédito no te dice nada sobre cómo va a funcionar con tu inventario, con Pix y por WhatsApp.
Conclusión
Anthropic no publicó un producto. Publicó un manual, con código, para que cualquiera con equipo lo construya y para que cualquiera sin equipo sepa qué exigir. Eso es lo que lo hace importante: mueve la discusión de "¿esto es posible?" a "¿cómo lo hacemos bien?".
Si lideras una empresa que vende por internet en la región, tres preguntas para llevar al próximo comité:
- ¿Qué tan buenos son mis sistemas de base? Buscador, inventario en tiempo real, catálogo limpio, API de carrito. Si la respuesta es "regular", el primer proyecto no es el agente. Es arreglar eso.
- ¿Construyo, compro o espero? Con equipo propio y un catálogo complejo, el blueprint hace viable construir un piloto acotado. Sin equipo, la pregunta es qué va a ofrecer mi plataforma y cuándo. Esperar es una decisión válida si es consciente.
- ¿Quién es dueño de la seguridad y los datos? Antes de la primera línea de código o del primer contrato, alguien tiene que responder quién aprueba cambios de precio, qué se guarda del cliente y qué pasa cuando el agente se equivoca.
En el próximo artículo entro en las decisiones de diseño del manual: por qué Anthropic recomienda un solo agente en vez de diez, qué es la regla del 33%, y cómo se lee una propuesta técnica sin ser ingeniero.
¿Listo para llevar la IA a tu equipo?
Agenda una llamada gratuita de 30 minutos y te mostramos cómo podemos ayudarte a adoptar IA de forma estratégica y efectiva.
Agendar llamada gratuita
