Cómo crear un agente de compras con IA para ecommerce

Ya es posible poner en marcha un agente de compras con IA sin diseñar desde cero el bucle del agente, las skills, los contratos de herramientas, las barreras de seguridad ni los patrones de interfaz. Claude Commerce Agents aporta esa base. El verdadero trabajo consiste en conectarla con datos fiables del catálogo, vincular cada acción con el comprador correcto, mantener actualizado el inventario y detener el modelo antes del pago o de cualquier cambio irreversible.

Ese trabajo de producción importa porque el beneficio potencial se puede medir. Anthropic afirma que los comercios que usan agentes de compras con Claude han logrado carritos hasta un 35% más grandes y compradores con un 60% más de probabilidades de completar la compra. No son resultados garantizados para todas las tiendas, pero sí una razón para tratar al agente como un producto de conversión y no como un simple widget de chat.

Claude Commerce Agents aporta el armazón, no la tienda

Claude Commerce Agents es una implementación de referencia con licencia Apache-2.0 para dos funciones. El agente de compras atiende al cliente: puede buscar, comparar, planificar una compra de varios artículos, llenar un carrito, responder preguntas sobre políticas y pedidos, y recordar preferencias. El agente para comercios opera detrás de la tienda: puede analizar el rendimiento, vigilar el inventario, proponer cambios de precios y preparar campañas.

El diseño de un agente de cara al cliente es deliberadamente sencillo: un modelo ejecuta el bucle, las reglas comunes viven en el prompt del sistema, los procedimientos menos frecuentes se organizan en cinco skills y las herramientas se comunican con los sistemas comerciales que ya utiliza la empresa. Es como tener a un vendedor capacitado en un mostrador. Conserva toda la conversación, pero consulta el terminal del almacén para conocer existencias, el sistema de clientes para verificar identidades y la caja para gestionar el carrito.

La misma definición puede ejecutarse con Messages API, Claude Agent SDK o Claude Managed Agents. Esa portabilidad resulta útil, pero no convierte los ejemplos en sistemas listos para producción. Anthropic advierte que las demostraciones no incluyen autenticación. El repositorio tampoco hace pedidos, cobra tarjetas ni incorpora las reglas de fraude, elegibilidad, inventario y cumplimiento de cada negocio.

Los números del negocio empiezan después de la demo

El proyecto de referencia reduce el costo de llegar a una primera versión convincente. En la página de lanzamiento de Anthropic, Wix cuenta que creó en 15 minutos un prototipo capaz de recibir prompts; Fetch señala que ejecutó localmente ambos agentes de referencia en bastante menos de una hora; y Zomato sostiene que las prácticas incluidas pueden ahorrar semanas de prueba y error. Son testimonios de socios, no garantías de entrega. Aun así, muestran con claridad cómo cambia el presupuesto: se dedica menos ingeniería a inventar la estructura del agente y más a la calidad del catálogo, los permisos, la evaluación y el último tramo hasta el checkout.

El gasto en el modelo también puede ser pequeño frente al trabajo de integración. Claude Sonnet 5 tiene un precio de $2 por cada millón de tokens de entrada nuevos, $0.20 por cada millón de tokens recuperados de caché y $10 por cada millón de tokens de salida. En un turno ilustrativo con 20,000 tokens de entrada y 800 de salida, el modelo cuesta $0.048 si todos los tokens de entrada son nuevos. Si 18,000 proceden de la caché y 2,000 son nuevos, el mismo cálculo da $0.0156. Esto no incluye búsqueda, alojamiento, observabilidad, soporte ni ninguna de las API comerciales que rodean al modelo.

Anthropic indica que sus implementaciones de comercio más sólidas alcanzan tasas de acierto de caché de entre el 90% y el 99%. Por eso, el presupuesto de producción no consiste en «comprar un LLM», sino en lograr que cada tarea de compra completada sea correcta, rápida, atribuible y segura.

Cómo llevar un agente de compras con IA a producción

El orden correcto de construcción sigue el dinero y el riesgo. Primero se define la tarea de compra; después se conectan los datos y la identidad; luego se habilitan las acciones; y solo entonces se optimiza la velocidad. Una conversación impecable basada en existencias obsoletas sigue siendo una tienda averiada.

1. Elige una sola tarea de compra y una métrica de éxito

No empieces con la idea de «responder cualquier pregunta sobre nuestro catálogo». Elige una tarea concreta: ayudar a una persona a escoger el tamaño correcto de colchón, armar un kit de campamento de tres productos sin superar un presupuesto o encontrar un reemplazo disponible para un artículo agotado.

Define el éxito como una tarea completada, no como una respuesta agradable. Entre las métricas útiles están una selección de productos sustentada en datos, una recomendación aceptada, un artículo añadido al carrito, la transferencia al checkout, la resolución sin abrir un ticket de soporte y la tasa de devoluciones de los pedidos asistidos. Evalúa el tamaño del carrito y la finalización de compra junto con la latencia y el costo del modelo. La respuesta más barata sale cara si recomienda la variante equivocada.

2. Coloca la búsqueda y el ranking actuales detrás de la herramienta de catálogo

El modelo no debe convertirse en el motor de búsqueda. En el patrón de Anthropic, search_products devuelve resultados ya ordenados. Claude decide después cuáles satisfacen las condiciones del comprador y cuántos conviene mostrar.

Organiza el catálogo en tres estructuras: productos simples, familias de productos y variantes que realmente se pueden comprar. Una familia de camisas puede reunir las opciones de talla y color, mientras cada variante conserva su precio y sus existencias actuales. La búsqueda puede devolver la familia, pero cualquier escritura en el carrito debe indicar la variante exacta. Esa distinción impide que un agente elocuente añada una «camisa azul» sin saber si la azul de talla mediana está disponible.

Devuelve únicamente los campos que el modelo necesita para razonar. Normalmente importan el ID del producto, el título, el precio, la disponibilidad, los valores de las opciones, los atributos relevantes y la marca de tiempo de la fuente. Repetir las URL de las imágenes y extensos textos promocionales en cada resultado consume contexto sin mejorar la decisión.

Si ya existe un servicio de búsqueda o recomendaciones, conserva ahí su lógica de negocio. Si no existe, corrige primero la recuperación de información y después ajusta el prompt. Una herramienta de catálogo no puede compensar atributos incompletos, SKU duplicados ni un ranking que pase por alto las condiciones del comprador.

3. Vincula la identidad antes de mostrar una herramienta al modelo

La autenticación corresponde a la aplicación anfitriona. Esta inicia la sesión del comprador, determina si se trata de un cliente o un invitado y crea una sesión. Los métodos del backend leen esa identidad desde el estado de sesión del servidor. El modelo no recibe ni el ID del cliente como argumento de una herramienta ni la credencial utilizada para acceder a la tienda.

Los invitados deben tratarse como identidades reales, aunque tengan menos permisos. Si alguien sin autenticar pide su historial de pedidos o sus direcciones guardadas, el backend debe exigir que inicie sesión. Tras la autenticación, crea una sesión nueva en lugar de transformar una identidad anónima a mitad de la conversación.

Es fácil pasar por alto esta separación en una demo y muy costoso incorporarla más tarde. Es lo que distingue «el agente llamó a la herramienta de pedidos» de «este comprador autenticado tenía permiso para consultar este pedido».

4. Haz que el inventario sea la autoridad en el momento de actuar

Los resultados de búsqueda ayudan al agente a razonar, pero el backend conserva la verdad. Dentro de la operación del carrito, vuelve a comprobar existencias, elegibilidad, precio, límites de compra, horas límite de preparación de pedidos y reglas de promociones. Hazlo de forma atómica para que, si el inventario desaparece entre una lectura y una escritura, el sistema responda de manera inequívoca.

Si la variante solicitada no está disponible, devuelve su ID junto con las variantes hermanas válidas. El agente debe explicar la diferencia y pedir al comprador que elija; nunca debe sustituir productos en silencio. En marketplaces, precios por cuenta, fechas de viaje o recogida en una tienda específica, envía el contexto pertinente al backend que calcula la respuesta.

5. Trata cada herramienta como una API con permisos

La implementación de referencia construye la lista visible de herramientas a partir de la configuración de despliegue. Desactiva los sistemas que no existan, crea una lista explícita con los nombres restantes y rechaza mediante código cualquier llamada que quede fuera de ella.

Añade después controles de procedencia. Una escritura en el carrito solo debe aceptar un ID de producto devuelto por el servidor durante esa sesión o que ya esté en ese carrito. Así se bloquean los ID inventados, los copiados desde otra cuenta y las instrucciones ocultas en el contenido de los productos. El mismo principio se aplica a la presentación: el agente puede elegir un ID devuelto, pero el servidor completa la tarjeta de producto con su propio registro.

Considera que fichas, reseñas, políticas, mensajes de vendedores y datos recordados son información no fiable. El entorno de ejecución de Anthropic limpia y delimita los textos de terceros antes de que Claude los lea. Las reglas del prompt ayudan, pero los permisos, los límites de cantidad, los campos protegidos y la serialización de escrituras deben estar implementados en código.

Si el despliegue exige más control sobre el entorno de ejecución o el gateway, la guía de herramientas para agentes gestionados explica las opciones de infraestructura para agentes que utilizan herramientas.

6. Termina la autoridad del agente en el checkout

Claude Commerce Agents marca un límite estricto: el modelo puede construir y mostrar el carrito, pero no hacer el pedido ni cobrar una tarjeta. La aplicación anfitriona proporciona el destino del checkout después de la llamada al modelo, de modo que la propia URL nunca entra en el contexto del modelo.

Elige una forma de transferencia:

1. Abrir el checkout dentro de la aplicación propia.
2. Abrir la URL de checkout alojada por la plataforma de comercio.
3. En un marketplace, mostrar un enlace de checkout por vendedor.

Ese límite es una buena decisión de producto, no una función ausente. Permite que el comprador revise cantidad, dirección, envío, descuentos y precio total en el sistema que ya se ocupa del pago y del cumplimiento normativo.

Añade otra vía de transferencia al soporte humano para los casos ambiguos que el agente no debe asumir. Define qué intenciones la activan, qué cola los recibe, qué resumen de la conversación se envía y qué puede aprobar la persona. «Hablar con alguien» es un flujo de trabajo con identidad y reglas de nivel de servicio, no una frase de último recurso.

7. Presenta la interfaz comercial mediante herramientas tipadas

Las cuadrículas de productos, tablas comparativas, planes, carritos y tarjetas de pedidos deberían ser herramientas de presentación tipadas. Claude invoca un componente con argumentos estructurados, el servidor los valida y completa, y el cliente muestra el resultado.

Así, la interfaz visible pasa a formar parte del historial de la conversación. Cuando el comprador dice «el segundo», la lista ordenada de productos sigue dentro de los mensajes. Además, evita pedir al modelo que invente marcado personalizado y frágil. Para construir la experiencia conversacional que rodea esos componentes, la guía para crear chatbots aborda las decisiones generales de interfaz.

8. Distribuye la latencia a lo largo de toda la tarea

Mide el tiempo hasta completar la tarea como la suma de los turnos del modelo y el tiempo de las herramientas. Importan tanto reducir los turnos como acelerar las herramientas y la entrega de tokens.

Carga el contexto probable de la página antes de la primera llamada al modelo. Ejecuta en paralelo las consultas independientes al catálogo o a las políticas. Envía cada herramienta en cuanto terminen de llegar sus argumentos por streaming. Muestra las tarjetas de producto a medida que recibas sus campos y presenta una línea sencilla de progreso mientras se completa una consulta lenta.

Anthropic señala que una respuesta comercial renderizada suele tener entre 500 y 700 tokens de salida, suficientes para dejar un indicador de carga sin contenido útil durante cinco segundos o más si no hay renderizado progresivo. También informa que la activación anticipada de herramientas ha reducido intervalos observados de varios segundos a unos pocos cientos de milisegundos. Haz este trabajo de ingeniería antes de cambiar a un modelo inferior. Un modelo menos capaz puede necesitar más turnos y terminar costando más por cada tarea completada.

9. Convierte los requisitos del producto en evaluaciones

Una evaluación es un caso repetible que comprueba cómo actúa el agente desde un estado conocido. Construye los mensajes, registros del catálogo, carrito, datos del usuario y fallos relevantes; después califica el estado final y la respuesta presentada.

Cubre cinco grupos: solicitudes básicas de compra, turnos que dependen del contexto, casos de seguridad y marca, comportamiento de la interfaz y mensajes que cruzan dos capacidades. Para cada caso positivo, escribe su contraparte negativa. Si el agente debe recomendar una variante disponible, prueba también qué sucede cuando todas las variantes válidas están agotadas. Incluye texto hostil dentro de una ficha, el ID de pedido de otro usuario, tiempos de espera agotados, búsquedas vacías, el mismo artículo añadido varias veces al carrito y un cambio de precio entre la búsqueda y el carrito.

Anthropic recomienda empezar con entre 50 y 100 casos por flujo de usuario. Créelos junto con los equipos de producto, legal, atención al cliente y merchandising; luego convierte los incidentes reales en casos permanentes de regresión. Condiciona las versiones canary a la precisión sustentada en datos, la finalización de tareas, la tasa de aprobación de seguridad, la latencia p50 y p99, la tasa de acierto de caché y el costo por tarea completada.

Siete casos de uso en ecommerce, ordenados por quién obtiene más valor

Las tiendas con clientes sujetos a restricciones reales y catálogos con decisiones relevantes son las que más ganan. Un bot genérico de preguntas frecuentes es el uso más débil de esta arquitectura.

1. Asesor para productos de compra meditada

Para quién: Tiendas de colchones, electrodomésticos, equipo para actividades al aire libre o electrónica cuyos productos exigen comparaciones.

Flujo: El comprador indica un objetivo, presupuesto, dimensiones y preferencias. El agente consulta resultados de catálogo ya ordenados, obtiene detalles de los candidatos más sólidos, muestra una comparación estructurada, confirma la variante exacta y prepara el carrito.

Por qué resulta rentable: Lleva la ayuda para decidir al momento mismo de la compra. Es el caso más cercano a los resultados de Anthropic sobre carritos más grandes y mayor finalización de compra, porque el agente puede despejar dudas antes de que el cliente abandone la tienda.

2. Creador de paquetes según el objetivo

Para quién: Tiendas con productos que funcionan juntos, como artículos de campamento, equipamiento para oficina en casa, rutinas de cuidado de la piel o una primera cocina.

Flujo: El agente divide un objetivo en varias necesidades de producto, ejecuta búsquedas independientes en paralelo, comprueba el presupuesto combinado, explica las concesiones y añade al mismo carrito las variantes aprobadas.

Por qué resulta rentable: Puede aumentar el valor de la cesta al completar una tarea, en vez de limitarse a promocionar otro artículo. También evita que el comprador abra varias páginas de categorías y tenga que comprobar por su cuenta la compatibilidad.

3. Guía de variantes y ajuste

Para quién: Comercios de moda, cosmética, muebles y productos configurables con alto riesgo de devoluciones.

Flujo: El comprador proporciona condiciones de ajuste, tono, espacio o compatibilidad. El agente consulta las opciones de la familia, comprueba las existencias de la variante exacta, muestra solo combinaciones válidas y se niega a añadir un registro de familia sin resolver.

Por qué resulta rentable: El valor está en reducir las decisiones equivocadas, no en generar más conversación. Llegar al checkout con una variante válida puede disminuir cancelaciones y devoluciones evitables sin frenar al comprador.

4. Descubrimiento y atención posventa

Para quién: Tiendas cuyo equipo de soporte atiende una y otra vez consultas sobre estado de pedidos, devoluciones, garantías y políticas.

Flujo: Una misma conversación pasa del descubrimiento de productos a la consulta de un pedido, tras iniciar sesión, o a la búsqueda de una política. El agente lee únicamente los registros del cliente, muestra el estado y deriva las excepciones a una persona junto con su contexto.

Por qué resulta rentable: Una única interfaz puede favorecer tanto la conversión como la resolución automática. El comprador no necesita repetir el contexto del producto, el pedido y la política ante otro bot.

5. Asistente de compras B2B adaptado a cada cuenta

Para quién: Distribuidores y empresas de suscripción con precios contractuales, reglas de elegibilidad o surtidos aprobados.

Flujo: La aplicación anfitriona vincula la cuenta y el rol del comprador con la sesión. Las herramientas del backend devuelven solo el precio, los productos permitidos y las opciones de despacho de esa cuenta. El agente prepara una cotización o una transferencia a una orden de compra, en lugar de fingir que un checkout de consumo sirve para ese caso.

Por qué resulta rentable: Acorta un proceso de compra cargado de reglas sin vulnerar los derechos asociados a la cuenta. El modelo explica las alternativas, pero el sistema de cuentas conserva la autoridad.

6. Coordinador de carritos para marketplaces

Para quién: Marketplaces en los que varios vendedores pueden satisfacer una misma solicitud.

Flujo: El vendedor se convierte en una dimensión de búsqueda. El agente compara ofertas, agrupa las líneas del carrito por vendedor y la aplicación anfitriona muestra un enlace de checkout independiente para cada uno cuando sea necesario.

Por qué resulta rentable: Convierte una compra fragmentada en una sola conversación de planificación sin ocultar la realidad comercial: el pago y el despacho corresponden a distintos vendedores.

7. Copiloto de inventario y promociones para comercios

Para quién: Equipos de merchandising que gestionan ventas, existencias, precios y campañas para muchos SKU.

Flujo: El agente para comercios consulta las alertas de rendimiento e inventario, propone una reposición o promoción, prepara el cambio y espera la aprobación en una interfaz real para operadores antes de aplicarlo.

Por qué resulta rentable: Puede acortar el análisis y la preparación sin eliminar los controles de doble validación que ya usa el negocio. La persona mantiene la autoridad sobre precios, presupuesto y publicaciones activas.

Tres productos que vale la pena construir

1. Un kit de lanzamiento vertical para agentes de compras

Crea un paquete listo para producción en una categoría de compra meditada —por ejemplo, equipamiento para exteriores, muebles o belleza— y véndelo a comercios que ya superaron las posibilidades de un widget de chat genérico.

La escala de precios ya existe. Brambles publica planes para asistentes de compra de $29 a $499 al mes, con entre 10,000 y 500,000 sesiones. Rye cobra $149 mensuales por infraestructura de comercio agéntico, más $0.02 por consulta de producto y $0.05 por pedido realizado. Estas cifras muestran tanto el gasto de los comercios en suscripciones como el gasto medido por uso en infraestructura.

La versión comercializable más pequeña admite una plataforma de comercio y una categoría. Mapea familias y variantes, vincula sesiones de invitados y usuarios autenticados, implementa la búsqueda y los detalles de producto, arma un carrito, transfiere al checkout alojado, muestra por streaming dos o tres componentes de interfaz tipados e incluye un paquete de evaluaciones específico de la categoría y una ruta de transferencia humana.

El problema es la presión sobre el precio. Las plataformas y los asistentes económicos de las tiendas de aplicaciones pueden resolver preguntas y respuestas genéricas sobre productos. La ventaja defendible debe residir en la lógica de la categoría, un mapeo fiable del catálogo, la atribución de conversiones y casos construidos con fallos reales de ese sector.

Esta es la oportunidad más sólida. Es la más cercana a los ingresos del comercio, y el proyecto de referencia elimina suficiente estructura genérica para que un equipo pequeño dedique su tiempo al trabajo específico de la categoría por el que los clientes sí pagarán.

2. Preparación del catálogo y control de variantes para agentes

Crea un servicio que compruebe si un catálogo puede responder de forma segura a las consultas de un agente antes de ponerlo frente a los clientes.

Ya existe infraestructura importante alrededor de este problema. Channel3 afirma que su capa de producto abarca 100 millones de productos de 25,000 comercios y responde en menos de un segundo. Rye cobra $0.02 por consulta de producto. Google fija el precio de AI Commerce Search en $2.50 por cada 1,000 consultas. La recuperación estructurada y actualizada ya es una partida presupuestaria.

Un MVP importa un feed, construye las relaciones entre familias y variantes, verifica los atributos obligatorios, compara las marcas de tiempo de precios y existencias, ejecuta una biblioteca de condiciones reales de compra y señala por SKU las respuestas ausentes o contradictorias. Añade una prueba de repetición que confirme que una misma consulta nunca produce una variante agotada al llegar al carrito sin ofrecer una ruta explícita de recuperación.

El problema es el peso de las plataformas. Shopify y otras plataformas comerciales controlan los feeds de catálogo que actúan como fuente de verdad y pueden incorporar la validación básica. El producto necesita normalización entre plataformas, priorización de incidencias vinculada con tareas de compra perdidas y pruebas de que las correcciones reducen las malas recomendaciones.

3. Evaluaciones y barreras de publicación específicas para ecommerce

Crea la capa de pruebas que decide si es seguro publicar un cambio de prompt, modelo, herramienta o catálogo.

Ya existe presupuesto para evaluar agentes. Langfuse indica que más de 50,000 empresas usan su plataforma y ofrece planes de producción de $29 y $199 al mes, mientras Enterprise parte de $2,499. Anthropic recomienda entre 50 y 100 casos de evaluación para cada flujo comercial. Lo que falta no es otro visor de trazas, sino una biblioteca mantenida de estados comerciales, datos de catálogo contaminados, invariantes del carrito y políticas de publicación.

El MVP importa transcripciones, convierte incidentes en casos basados en instantáneas e incluye evaluadores deterministas para la procedencia de productos, la fidelidad de los precios, la selección de variantes, los límites de cantidad, las fronteras del checkout, las filtraciones de identidad, la recuperación tras tiempos de espera agotados y la calidad de las transferencias. Debe comparar modelos y prompts por finalización de tareas, latencia p99 y costo por tarea completada.

El problema es un mercado horizontal saturado. La ventaja debe surgir de los datos de prueba específicos para comercio, la precisión de los evaluadores, los conectores de plataformas y los datos comparativos. La observabilidad genérica acabará copiada o incluida en otros productos.

Lo que Claude Commerce Agents no resuelve

La lectura honesta es que este proyecto resuelve mejor la estructura del agente que la integración con una tienda. Es un punto de partida serio, no un producto de compras alojado.

• No autentica a los compradores ni autoriza al personal. Esa tarea corresponde a la aplicación anfitriona y al gateway.
• No corrige datos deficientes del catálogo, un mal ranking ni la latencia del inventario. Los sistemas comerciales siguen siendo responsables.
• No realiza pedidos, guarda credenciales de pago, cobra tarjetas ni decide la política contra el fraude.
• No elige las reglas de escalamiento humano, las colas de servicio ni los roles de aprobación.
• No garantiza que las mejoras de conversión declaradas por Anthropic se reproduzcan en todos los catálogos. Cada empresa necesita sus propias mediciones controladas.
• No elimina la necesidad de tomar decisiones de privacidad sobre la memoria. Las preferencias almacenadas exigen tipos de datos aceptados, plazos de conservación, acceso, corrección y eliminación.

No construyas esto para un catálogo diminuto donde los filtros ya resuelven cada compra con un clic. No lo lances si los precios y las existencias están desactualizados. No concedas acceso de escritura porque el prompt parece prudente. El agente se gana su lugar cuando la conversación resuelve una tarea de compra realmente compleja y los sistemas pueden proporcionar datos actuales con los permisos adecuados.

Qué hacer el lunes

Elige para la próxima semana un flujo que genere ingresos. Toma 50 ejemplos reales de las búsquedas del sitio, los chats de ventas y las conversaciones de soporte. Conecta primero únicamente la búsqueda del catálogo y los detalles de producto, y haz que todas las demás herramientas devuelvan que no están disponibles. Mide si el agente selecciona variantes disponibles y respaldadas por datos, y si los compradores aceptan la recomendación. Añade el carrito y el checkout solo cuando la ruta de lectura supere sus casos. Esa secuencia transforma Claude Commerce Agents de una demo atractiva en un despliegue comercial controlado.

¿Cómo funciona un asistente de compras con IA?

Un agente Claude conserva la conversación y llama a herramientas tipadas para buscar en el catálogo, consultar detalles de productos, gestionar el carrito, las políticas, los pedidos y la memoria, y presentar los resultados. El backend autentica al comprador, aplica las reglas de precios e inventario y devuelve datos estructurados. El modelo razona a partir de esos datos, pero no se convierte en la fuente de verdad.

¿Cómo conecto mi catálogo de productos?

Implementa el backend de tienda del proyecto de referencia sobre los servicios existentes de búsqueda y productos. Devuelve familias ya ordenadas desde la búsqueda, variantes comprables exactas desde los detalles del producto y precios y disponibilidad actuales desde los sistemas que actúan como fuente de verdad. Mantén las credenciales y la identidad del comprador en el servidor.

¿Cómo funcionan los permisos de usuario en Sidekick?

Para un agente propio de compras o para comercios, adopta el principio subyacente, no la implementación de Sidekick. Determina el usuario y su rol antes del turno del agente, expón solo las herramientas permitidas, conserva las credenciales en el servidor, vuelve a aplicar la autorización en cada método del backend y exige una aprobación real en la aplicación anfitriona para las escrituras comerciales sensibles.

¿Puedo construirlo por mi cuenta con Claude o una herramienta similar?

Sí. El repositorio de código abierto incluye ejemplos ejecutables y un plugin de Claude Code capaz de generar la estructura inicial sobre tu backend. El trabajo restante para construirlo internamente sigue siendo considerable: autenticación, mapeo del catálogo, inventario en tiempo real, integración del carrito y el checkout, permisos, transferencia humana, supervisión y evaluaciones.

Si quieres implementar una de estas ideas según tu catálogo y tus reglas operativas, consulta el servicio de desarrollo de agentes de IA.