Tu IA de Comercio No Puede Recordar Lo Que Hizo Hace 5 Segundos. Una Nueva Arquitectura Puede Arreglar Eso.

Resumen: Tu Agente Tiene Amnesia

• La mayoría de los agentes de IA hoy son sin estado. No tienen memoria confiable de acciones pasadas, lo que los hace inapropiados para operaciones críticas de comercio como la gestión de inventarios o los viajes de cliente de múltiples etapas. Esto no es un error; es un fallo fundamental en su diseño que lleva a fallos impredecibles y no auditable.
• Un nuevo artículo de arXiv esta semana, "ESAA: Event Sourcing for Autonomous Agents in LLM" (arXiv:2602.23193v1), propone una solución adaptando un patrón empresarial probado: el event sourcing para sistemas agentic [5]. Separa las intenciones de un agente (lo que quiere hacer) de sus efectos (lo que realmente sucede).
• Este cambio arquitectónico permite crear flujos de trabajo agentic auditable, reproducible y resilientes. Permite a las marcas utilizar LLM heterogéneos (como GPT-5 y Claude Sonnet 4.6), evitar el bloqueo de proveedores y construir agentes a largo plazo en los que finalmente se puede confiar para tareas críticas sin alucinar su propio estado [6].

He aquí un escenario cada vez más plausible. El CTO de una marca DTC de rápido crecimiento—llamémosla "Melrose Active"—estaba en un pánico total. Su nuevo agente de inventario autónomo, un sistema que le habían vendido como la cúspide del "comercio agentic", había intentado pedir 50,000 unidades de un SKU de bajo movimiento. ¿El desencadenante? Un pequeño problema en la red durante un chequeo rutinario de stock. El agente, habiendo perdido su contexto a mitad de operación, volvió a ejecutar su lógica inicial, malinterpretó los datos parciales del primer intento fallido y concluyó que el almacén estaba vacío. Fue un error de un millón de dólares, atrapado solo por una alerta de humano en el ciclo que, francamente, derrotó todo el propósito del sistema autónomo.

El escenario es ilustrativo, pero no es descabellado. Es la consecuencia directa del sucio pequeño secreto del auge de la IA agentic: la mayoría de estos sistemas están construidos sobre arena. Son sin estado, amnésicos que operan en un presente perpetuo. No pueden recordar de manera confiable lo que hicieron hace un minuto, y mucho menos ayer. Para chatbots de preguntas y respuestas simples, esto es un inconveniente. Para los procesos complejos, con estado y de larga duración que definen el comercio real—inventario, logística, personalización, servicio al cliente—es una responsabilidad catastrófica.

Mientras el resto del mundo está hipnotizado por demostraciones de agentes de IA reservando vuelos o "investigando vibras" itinerarios de viaje [1], nosotros en las trincheras de construir sistemas de comercio reales estamos luchando en una batalla mucho más fundamental: la batalla por el estado. Y un artículo que quietamente se publicó en arXiv esta semana podría ser uno de los desarrollos más importantes en esa lucha.

Entonces, Tres Agentes de IA Entran a un Bar... y Prenden Fuego?

El problema con el agente de Melrose Active no era solo un único punto de falla. Era un síntoma de un problema mucho más profundo y sistémico con sistemas multi-agentes. Cuando implementas múltiples agentes autónomos que comparten recursos—como bases de datos de inventario, motores de precios, o puertas de enlace de API—no solo fallan individualmente. A menudo fallan de maneras sincronizadas y correlacionadas que amplifican el daño.

Un fascinante artículo de arXiv publicado esta semana, "Three AI-agents walk into a bar … ‘Lord of the Flies’ tribalism," ilustra perfectamente este escenario de pesadilla [2]. Los investigadores pusieron agentes LLM autónomos en un escenario clásico de contención de recursos (el problema del bar El Farol) y observaron lo que sucedía. En lugar de actuar como actores racionales e independientes, los agentes rápidamente formaron "tribus" basadas en sus patrones de razonamiento subyacentes. Algunos se volvieron "Agresivos" (27.3% de la población), siempre tratando de acceder al recurso. Otros eran "Conservadores" (24.7%), y una gran pluralidad se convirtió en "Oportunistas" (48.1%).

¿El resultado aterrador? Este tribalismo emergente condujo a un comportamiento sincronizado, causando sobrecargas y fallos sistémicos mucho peores de lo que hubiera producido una simple distribución aleatoria. Cuando un agente decide inundar tu API de inventario, es probable que decenas de otros, construidos sobre el mismo modelo y lógica fundamentales, estén a punto de hacer lo mismo. Este es el peligro de desplegar sistemas aparentemente autónomos que carecen de verdadera independencia en sus modos de falla. Sin una base arquitectónica robusta, tu fuerza laboral agentic no es un equipo de individuos; es una multitud, propensa a caídas rápidas y estupidez de manada.

Por eso, la obsesión por capacidades de los agentes—lo que pueden hacer—está tan mal encaminada. El verdadero desafío es construir una arquitectura de IA en comercio que pueda manejar con gracia no solo un agente fallando, sino docenas de ellos fallando al unísono. Necesitamos sistemas que sean deterministas, auditables y resilientes al caos inherente de la lógica impulsada por LLM. Necesitamos planificar para la falla, no solo maravillarnos del éxito.

La Máquina de Amnesia: Por Qué Tu Actual Agente de IA Falta en Comercio

La causa raíz de esta fragilidad es algo que los ingenieros llaman "gestión de estado." O, en este caso, una falta total de ella. La mayoría de los marcos agentic hoy, como los populares bucles ReAct (Razona + Actúa), tratan cada interacción como un evento en gran medida independiente. La "memoria" del agente a menudo es solo el historial de conversación metido en la ventana de contexto de una llamada LLM. Esto no es memoria; es una nota adhesiva, y muy pequeña al mismo tiempo.

Un artículo de principios de esta semana sobre la evaluación de memoria de largo plazo para aplicaciones agentic confirmó lo que muchos de nosotros hemos visto en la práctica: este enfoque se degrada catastróficamente con el tiempo [7]. A medida que la tarea se vuelve más compleja y el número de turnos aumenta, la ventana de contexto se llena, se pierde información crítica, y el agente comienza a desviarse. Olvida sus instrucciones iniciales, sus acciones anteriores y el estado del mundo que se supone debe estar manipulando.

Esto tiene consecuencias profundas y tangibles para cualquier caso de uso serio en comercio:

1. Falta de Auditabilidad: Si las acciones de un agente son solo llamadas API transitorias impulsadas por un LLM probabilístico, ¿cuál es la fuente de verdad? Cuando tu departamento de finanzas pregunta por qué tu agente de precios dinámicos recortó el precio de un producto insignia en un 90% en medio de la noche, tu única respuesta es "el LLM decidió hacerlo." No hay ningún registro inmutable de las decisiones, los datos que las informaron, o la secuencia de eventos. Esto es un punto muerto para cualquier proceso regulado o crítico para la misión.

2. Sin Idempotencia: En sistemas distribuidos, la idempotencia es clave. Es la garantía de que hacer la misma solicitud varias veces produce el mismo resultado que hacerlo una vez. Cuando el agente de Melrose Active reintentó su chequeo de stock después de un error de red, debería haber sido una operación inocua e idempotente. En cambio, debido a que su estado se perdió, el nuevo intento se convirtió en una nueva acción independiente con un resultado desastroso. La mayoría de los marcos de agentes no imponen ni consideran la idempotencia, haciéndolos frágiles ante las inevitables fallas de red del mundo real.

3. Incapacidad para Reproducir y Depurar: Cuando el sistema falla, ¿cómo lo depuras? Con un agente sin estado, no puedes. No puedes reproducir la secuencia exacta de eventos y estados que llevaron a la falla. Te quedas mirando registros opacos del proveedor de LLM, tratando de retroceder y desentrañar una caja negra probabilística. Es como intentar depurar un complejo modelo financiero viendo un debate de noticias por cable.

Estos no son casos extremos. Este es el comportamiento por defecto de la mayoría de los sistemas de comercio agentic que se están promoviendo hoy. Son fundamentalmente poco confiables, no auditables y no aptos para entornos de producción donde hay dinero real y inventario real en juego. Son una responsabilidad arquitectónica que espera ocurrir.

¿Es Event Sourcing la Solución No Sexy y Necesaria para el Comercio Agentic?

Esto me lleva al artículo que apareció esta semana con el título decididamente no sexy: "ESAA: Event Sourcing for Autonomous Agents in LLM" (arXiv:2602.23193v1) [5]. Propone una solución que no es una indicación más ingeniosa o un modelo más grande. Es un patrón arquitectónico tomado del mundo de sistemas empresariales a gran escala y de alto riesgo: event sourcing.

El event sourcing no es nuevo. Es un patrón central en arquitecturas como CQRS (Separación de Responsabilidad de Comando y Consulta) que se han utilizado durante años en fintech, banca y logística—cualquier lugar donde la auditabilidad y la fiabilidad son innegociables. La idea central es simple: en lugar de almacenar el estado actual de un sistema, se almacena un registro solo de apéndice de todos los eventos que han tenido lugar. El estado actual se deriva al reproducir estos eventos.

El artículo ESAA propone aplicar este patrón exacto a los agentes de IA. En lugar de permitir que un LLM llame directamente a herramientas y cambie el estado del mundo, la única tarea del agente es emitir un objeto JSON que describa su intención. Eso es todo. Esta intención se trata como un evento. Un sistema separado y determinista—el orquestador—es el responsable de validar este evento, persistirlo en un registro inmutable, y solo entonces aplicar sus efectos (como llamar a una API de Shopify o actualizar una base de datos).

Esta separación es la clave. La parte del sistema probabilística, impredecible y creativa (el LLM) está aislada del lado determinista, fiable y cambiante del estado del sistema (el orquestador).

Cómo Funciona ESAA: Intenciones, No Acciones

El flujo de datos en un sistema basado en ESAA proporciona las barandillas que los agentes de hoy necesitan desesperadamente. Impone un nivel de disciplina que evita los tipos de fallas que vimos con Melrose Active.

El proceso se ve así:

Esto no es solo un diagrama teórico. El artículo ESAA demuestra esta arquitectura funcionando con modelos heterogéneos como el GPT-5 de OpenAI y el Claude Sonnet 4.6 [6]. La belleza es que el registro de eventos y el orquestador son agnósticos al modelo. El papel del LLM se reduce a ser un "motor de sugerencias", pero el orquestador sigue siendo la única fuente de verdad para todos los cambios de estado.

Un Paso a Paso para un Agente de Inventario Autónomo

Reproducimos el escenario de Melrose Active usando esta arquitectura. La marca, con sede aquí en Los Ángeles, necesita gestionar el inventario para su tienda insignia en Abbot Kinney.

1. El Desencadenante: Un trabajo cron inicia al agente de inventario con la meta: "Asegurarse de que todos los productos centrales en la ubicación de Abbot Kinney estén por encima de los niveles de seguridad de stock."
2. Intención #1 (Consulta): El agente LLM primero emite una intención: {"intent": "get_inventory_levels", "location": "abbot_kinney"}. El orquestador registra esto, consulta el sistema de inventarios, y devuelve los datos al agente.
3. Falla de Red: Supongamos que la conexión se cae justo después de que el orquestador envía los datos. El agente no recibe nada. En un modelo sin estado, su siguiente acción es una conjetura. En el modelo ESAA, nada ha cambiado. No se ha mutado ningún estado. Lo único que existe es una intención registrada para consultar.
4. Reintento: Cuando el agente vuelve a intentar, emite la exacta misma intención de nuevo: {"intent": "get_inventory_levels", "location": "abbot_kinney"}. El orquestador, al ver esta solicitud idempotente, puede simplemente volver a ofrecer el resultado de la primera consulta o ejecutarlo de nuevo. El resultado es el mismo.
5. Intención #2 (Orden): Al ver que un SKU está bajo, el agente ahora emite un comando: {"intent": "create_purchase_order", "sku": "MA-LG-BLK", "quantity": 500, "reason": "Stock en 42, por debajo del umbral de 50"}. Nota el campo reason—ahora podemos forzar al LLM a justificar sus intenciones, y esa justificación se almacena para siempre en el registro de eventos.
6. Auditoría: Seis meses después, un auditor puede reconstruir el estado exacto del sistema de inventario para ese día reproduciendo el registro de eventos inmutable. Pueden ver no solo qué sucedió, sino por qué el agente decidió actuar. Esta es la base de una arquitectura de comercio agentic confiable.

¿Es Esto Simple Exageración Arquitectónica? La Perspectiva de los Escépticos

Por supuesto, ninguna arquitectura es una solución mágica. Lo primero que un escéptico—o un ingeniero con un plazo ajustado—señalará es el costo adicional. El event sourcing introduce complejidad y latencia. Escribir en un registro, validar esquemas y luego proyectar el estado es inherentemente más lento que simplemente mutar un registro de base de datos directamente.

Hay mérito en este argumento. Un artículo diferente enviado a arXiv esta misma semana, "Tool-R0" (arXiv:2602.21320v1), muestra una filosofía completamente diferente. Utiliza aprendizaje reforzado desde cero para enseñar a un agente cómo usar herramientas con increíble eficiencia, presumiblemente un 92.5% de mejora en benchmarks [9]. Su enfoque está en el rendimiento puro y la capacidad, no en la fiabilidad en tiempo de ejecución a través de registros. Para tareas que son efímeras y donde la falla es barata, el enfoque Tool-R0 es argumentablemente superior.

Además, la preocupación sobre la inflación del "defensa en profundidad" es real. ¿Necesitas esta maquinaria pesada para un simple chatbot de servicio al cliente que busca estados de pedidos? Probablemente no. Un bucle ReAct más simple o el modelo de bloqueo propuesto por el Protocolo OpenPort (OPP) [1] podrían ser suficientes. La clave es entender los compromisos.

Aquí hay un desglose de los enfoques competidores que surgieron en solo la última semana de febrero de 2026:

El patrón ESAA no es para cada problema. Pero para los procesos de alto riesgo, de larga duración y múltiples etapas que definen el comercio de back-office, sus compromisos—sacrificando unos pocos milisegundos de latencia por años de auditabilidad y fiabilidad—no solo son valiosos; son obligatorios.

Lo Que Esto Significa para la Preparación de la Vitrina Agentic de Tu Marca

Para cualquier CTO o Jefe de Ingeniería en una marca DTC, esto debería ser una llamada de atención. Tu preparación de vitrina agentic no tiene nada que ver con lo llamativa que sea tu chatbot. Se trata de la solidez de tu backend. Se trata de si tu infraestructura está preparada para agentes que son con estado, auditables y fiables.

Esto es lo que realmente se necesita:

1. APIs Estructuradas e Idempotentes: Tus APIs internas y externas deben ser a prueba de balas. ¿Puede tu endpoint create_order manejar ser llamado cinco veces con la misma carga útil sin crear cinco órdenes? Si no, no estás listo. Los agentes fallarán y volverán a intentar. Tus sistemas deben estar construidos para esto.

2. Una Capa de Datos Rica: Un agente es tan bueno como los datos a los que puede acceder. Invertir en datos estructurados para búsqueda de IA—catálogos de productos limpios, segmentos de clientes bien definidos, datos de inventario accesibles—es la base de cualquier sistema inteligente. Este es el núcleo de lo que equipos como el laboratorio GEO de Princeton están trabajando: optimizando el entorno para la generación, no solo el modelo.

3. Una Estrategia de Gestión de Estado: Esta es la gran cuestión. Necesitas decidir conscientemente cómo tus agentes manejarán el estado. ¿Aceptarás los riesgos de un bucle ReAct sin estado para interacciones de bajo riesgo? ¿O invertirás en un patrón como el event sourcing para flujos de trabajo críticos? No tener una estrategia es una estrategia para el fracaso.

4. Un Laboratorio de Experiencia de IA: No puedes construir esto sobre la marcha. Las marcas deben establecer laboratorios internos de experiencia de IA—entornos aislados donde puedas probar con seguridad estas arquitecturas agentic. Aquí es donde pones a prueba tus propios sistemas, simulas fallas de red y ves cómo se comportan tus agentes bajo presión antes de que puedan tocar el inventario de producción de tu tienda insignia en Santa Mónica.

En CTO.LA, trabajamos con marcas de comercio para construir esta infraestructura fundamental. No estamos vendiendo magia agentic; estamos implementando la tubería resiliente, aburrida pero esencial que lo hace posible. Actuamos como el arquitecto de comercio agentic que asegura que el sistema no colapsará la primera vez que un agente tenga un mal día.

No Construyas Otra Responsabilidad Agentic

La prisa por añadir un "agente de IA" a cada parte de la pila de comercio está creando una nueva generación de deuda técnica. Estos sistemas, construidos sin una estrategia arquitectónica coherente para el estado, la auditabilidad y la falla, no son activos. Son pasivos que esperan ser desencadenados.

Un estudio sobre agentes desplegados en laboratorio encontró 11 diferentes categorías de fallo, desde filtraciones de datos y denegación de servicio hasta simplemente mentir sobre la finalización de una tarea [1]. El problema no es que los agentes fallen; es que nuestros sistemas no están diseñados para contener esa falla.

El artículo ESAA es significativo no porque sea un descubrimiento revolucionario de IA, sino porque es un llamado a la cordura. Es un recordatorio de que las lecciones duras ganadas de la ingeniería de sistemas distribuidos en las últimas dos décadas no se descartan solo porque tengamos un nuevo LLM poderoso. De hecho, se vuelven más importantes que nunca.

No dejes que la próxima gran iniciativa de IA de tu empresa se convierta en su próximo gran corte de servicio. Enfócate en la arquitectura. Construye para la fiabilidad. Separa la intención de la ejecución. Y por el amor de Dios, dale a tu agente una memoria.

El futuro de la IA en comercio en Los Ángeles y más allá no será definido por los prompts más ingeniosos, sino por los sistemas más resilientes. CTO.LA trabaja con marcas de comercio construyendo esta infraestructura agentic. Hablemos.

Referencias

1. AnybodyCanPrompt - Anthropic Rechaza la Última Oferta del Pentágono...
2. arXiv:2602.23093v1 - Tres Agentes de IA entran a un bar... 'El Señor de las Moscas' tribalismo
3. arXiv:2602.23073 - Evaluación Acelerada de Políticas Aversiones al Riesgo en POMDPs
4. arXiv:2602.22915 - Diseño de Información Robusta para Sistemas Multi-Agente
5. arXiv:2602.23193 - ESAA: Event Sourcing for Autonomous Agents in LLM
6. PDF: ESAA: Event Sourcing for Autonomous Agents in LLM
7. arXiv:2602.22769 - Evaluando Memoria de Largo Plazo para Aplicaciones Agentic
8. arXiv:2602.23330 - Hacia Equipos Expertos de Inversión de Grandes Modelos de Lenguaje
9. arXiv:2602.21320 - Tool-R0: Potenciando Grandes Modelos de Lenguaje con Herramientas a través del Aprendizaje Reforzado desde Datos Cero
10. arXiv:2602.22302 - Contratos de Agentes: Un Lenguaje para Acuerdos Ejecutables entre Humanos y Agentes de IA

• agentic commerce
• commerce ai architecture
• event sourcing
• llm
• ai