Datos de producto estructurados significa que cada dato del producto vive en un atributo tipado, con…
Del API Gateway a la capa de agentes de IA: BFF en el commerce agéntico
Si te fijas en el capítulo 4 de Microservices for Modern Commerce de Kelly Goetsch (O'Reilly, 2016), encontrarás un pasaje sobre los API gateways que cobra un nuevo significado en 2026.
Goetsch describe el API gateway como una capa agregadora: «Una página web o una pantalla en un dispositivo móvil puede requerir la recuperación de datos de docenas de microservicios diferentes. Cada uno de esos clientes necesitará datos adaptados a él.» A continuación denomina a los API gateways como «a menudo llamados 'Backends for your Frontend'», BFF para abreviar.
La idea: una capa agregadora dedicada que devuelve diferentes formas de datos según el contexto del consumidor. El Apple Watch necesita un atributo. La página web necesita veinte. La app móvil necesita quince distintos. El BFF se encarga de esta agregación y transformación.
Diez años después, esta capa es más importante que nunca. No por los nuevos dispositivos. Por una nueva clase de consumidores de API: los agentes de IA.
Qué significaba el patrón BFF en 2016
En el modelo de Goetsch, el BFF es una capa de optimización para las interfaces de usuario. Resuelve un problema de rendimiento concreto: si un cliente de app móvil tuviera que llamar directamente a docenas de microservicios, se producirían demasiados round-trips, demasiado overfetching (demasiados datos para el contexto), demasiado acoplamiento entre el cliente y los microservicios individuales.
El BFF gestiona esta coordinación en el lado del servidor:
- Agrega datos de múltiples microservicios en una única respuesta
- Transforma los datos en la forma óptima para el cliente
- Mantiene la lógica del lado del cliente fuera de los propios microservicios
Goetsch también advierte sobre el antipatrón: «El problema con los API gateways es que se convierten en monolitos fuertemente acoplados porque necesitan saber cómo interactuar con cada cliente (docenas) y cada microservicio (docenas, cientos o incluso miles). El mismo problema que buscabas remediar con los microservicios puede reaparecer si no tienes cuidado.»
Esa es la tensión central del BFF que surgió en 2016 y que sigue vigente en 2026.
Qué significan los agentes de IA como nueva clase de consumidor
En 2026, hay una nueva clase de consumidores de API para la que el concepto de BFF de Goetsch es directamente relevante: los agentes de IA.
Los agentes de IA, ya sea como agentes compradores (que buscan y compran productos en nombre de los clientes), agentes de productividad (que crean contenido u optimizan campañas en nombre de los equipos de commerce) o agentes de servicio (que gestionan la comunicación con el cliente), consumen las APIs de commerce de una forma fundamentalmente distinta a las UIs clásicas.
La diferencia respecto a una UI clásica:
Una UI web clásica la operan humanos. Sigue un user journey predeterminado: página de categoría → página de detalle de producto → cesta → checkout. Las llamadas a la API son predecibles, su esquema está documentado, su secuencia está definida.
Un agente de IA no sigue ningún journey predeterminado. Planifica sus acciones de forma dinámica en función del objetivo y el contexto. Necesita:
- Esquemas legibles por máquina: No solo «qué devuelve la API» sino «qué puede hacer esta API», Swagger/OpenAPI por sí solo es insuficiente; se necesitan descripciones semánticas de las acciones.
- Manifiestos de herramientas: Una lista de las acciones disponibles (buscar producto, añadir al carrito, aplicar cupón, comprobar inventario) con sus parámetros y efectos secundarios.
- Semántica de acciones: No solo APIs de lectura, sino acciones con precondiciones, postcondiciones y comportamiento ante fallos definidos.
- Seguimiento de estado: Los agentes necesitan un mecanismo para mantener el contexto actual (cesta, sesión, perfil de usuario) a lo largo de múltiples llamadas.
Esto es fundamentalmente distinto de una API REST optimizada para UI.
BFF 2.0: una capa de agregación con capacidad para agentes
La implicación: los BFF deben diseñarse de forma diferente para los agentes que para las UIs. Un BFF moderno en un contexto de commerce agéntico tiene dos capas:
Capa 1: La capa BFF clásica (para UIs) Agrega los datos de los microservicios en formas de respuesta optimizadas para UI. Funciona como se describió en 2016.
Capa 2: La capa de interfaz de agentes (nueva) No expone vistas orientadas a páginas, sino interfaces de herramientas:
searchProducts(query, filters, maxResults), devuelve una lista estructurada de productos, legible por agentesaddToCart(productId, quantity, customerId), acción idempotente con estado de resultado explícitogetInventory(productId, warehouseContext), en tiempo real, fuertemente consistente (sin caché)applyPromotion(cartId, promoCode), con un esquema explícito de éxito/falloinitiateCheckout(cartId, paymentContext), con un manifiesto de errores completo
Cada una de estas acciones está diseñada para el consumo máquina a máquina: un esquema de entrada claramente definido, un esquema de salida claramente definido, códigos de error claramente definidos, idempotente siempre que sea posible.
Goetsch describe en un contexto diferente la idea de HATEOAS (REST de nivel 3): «Las APIs se vuelven autodocumentadas, lo que permite a quien llama a la API interactuar con ella muy fácilmente sin saber demasiado sobre ella.» Ese es exactamente el principio que se aplica a las interfaces de agentes en su forma moderna, pero con un manifiesto de herramientas en lugar de enlaces HATEOAS.
Por qué la capa de frontend es el lugar natural para la capa de agentes
He aquí el argumento no obvio: la capa de agentes no pertenece al backend. Pertenece al nivel de gestión del frontend.
¿Por qué? Porque los agentes, ya sean agentes compradores o agentes de productividad, necesitan acceso al estado compuesto del stack de commerce: el precio actual para este usuario, en este mercado, con estas promociones activas, con esta situación de inventario. Este estado compuesto no existe en ningún microservicio de backend por sí solo. Se crea mediante la agregación de múltiples microservicios, exactamente lo que hace el BFF.
Una FMP que ya gestiona esta capa de agregación es el lugar natural para exponer también las interfaces de herramientas de los agentes. La FMP ya sabe:
- Qué microservicios son responsables de qué datos
- Qué políticas de caché se aplican a qué datos
- Qué reglas de personalización están activas para qué usuario
- Qué mercados y localizaciones existen
Un agente que accede a esta capa de FMP recibe datos compuestos, personalizados y conscientes del mercado, sin que la lógica del agente tenga que soportar esa complejidad por sí misma.
Larry AI: el enfoque de Laioutr para el commerce agéntico
La Agentic Frontend Management Platform de Laioutr no solo expone el renderizado de páginas. Expone las interfaces de herramientas de los agentes como una funcionalidad de primera clase.
Larry AI, el agente de IA integrado de Laioutr, demuestra este patrón: trabaja sobre la misma capa de FMP que sirve a las UIs clásicas. Puede buscar productos, ejecutar acciones de cesta, aplicar reglas de personalización y probar variantes de contenido, no a través de llamadas directas a los microservicios del backend, sino a través de las interfaces de herramientas definidas de la FMP.
Esto significa: los nuevos agentes de IA pueden construir sobre una capa de agregación ya existente y bien estructurada, en lugar de empezar de cero cada vez. Las nuevas capacidades de commerce (un nuevo microservicio en el backend) se registran una vez en la capa de interfaz de herramientas de la FMP y quedan disponibles de inmediato para todos los agentes.
Esta es la evolución directa del concepto de BFF de Goetsch: de «Backend for your Frontend» a «Backend for your Agents and Frontends».
Requisitos para la preparación agéntica de tu stack de commerce
Si hoy estás planeando integrar agentes de IA en tu stack de commerce, estas son las preguntas que determinan el éxito:
1. ¿Tienen tus APIs esquemas legibles por máquina? La especificación OpenAPI es un comienzo. Pero para el consumo por parte de agentes necesitas descripciones semánticas: ¿cuál es la intención de esta acción? ¿Cuáles son los efectos secundarios?
2. ¿Tienes una capa de agregación que exponga el estado compuesto? Un agente que tiene que llamar directamente a 20 microservicios no es un agente, es un script con mucha gestión de errores. Necesitas una capa BFF que se encargue de la composición.
3. ¿Son idempotentes tus acciones de commerce? Los agentes pueden ejecutar acciones varias veces (lógica de reintento, paralelismo). Si «añadir al carrito» no es idempotente, se producen pedidos duplicados. Eso no es un problema de IA, es un problema de diseño de la API.
4. ¿Tienes una capa de estado para las sesiones de los agentes? Un agente comprador que prepara una compra a lo largo de múltiples interacciones necesita un estado persistido: cesta activa, productos guardados, negociación en curso con un agente de servicio. Este estado debe existir en la capa de FMP, no en el propio agente.
5. ¿Cómo aíslas el tráfico de agentes del tráfico de UI? Los agentes pueden generar tráfico en ráfagas (razonamiento en paralelo, múltiples llamadas a herramientas por segundo). Necesitas rate limiting y throttling en la capa de interfaz de agentes que no afecte a tu tráfico de UI.
Conclusión: el BFF de 2016 es la base de la capa de agentes de 2026
La descripción de Goetsch del API gateway como «Backend for your Frontend» fue en 2016 una decisión de arquitectura pragmática para la optimización de UI multicanal. En 2026, esa misma capa es la palanca decisiva para el commerce agéntico.
La continuidad es directa: el pensamiento BFF, una capa de agregación dedicada que desacopla a los consumidores de la complejidad del backend, no está anticuado. Es la base arquitectónica de todo lo que viene después de la UI web clásica.
La diferencia es: los consumidores ya no son solo usuarios humanos. Son agentes compradores, agentes de productividad, agentes de servicio. Y estos nuevos consumidores necesitan una capa que vaya más allá del renderizado de páginas: interfaces de herramientas, semántica de acciones, esquemas legibles por máquina.
Una FMP que gestiona esta capa hoy no es solo una optimización para las UIs existentes. Es la infraestructura para el commerce de la próxima década.
Más sobre cómo la retrospectiva de la década del libro de Goetsch enmarca los demás avances: 10 años de microservicios en el commerce. Y sobre cómo funciona la consistencia eventual en los flujos de agentes: Consistencia eventual en el escaparate componible.
[Ve a Larry AI en acción, reserva una demo gratuita](https://www.laioutr.com/demo)
Fuente: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.
Insights relacionados
Recursos relacionados: Content Management y Composable Digital Experience Platform.