PDP Storytelling vs Spec-Sheets: The DACH Conversion LeverMost DACH mid-market product detail pages …
From API Gateway to AI Agent Layer: BFF in Agentic Commerce
From API Gateway to AI Agent Layer: How the BFF Pattern Makes Agentic Commerce Possible
If you look at Chapter 4 of Kelly Goetsch's Microservices for Modern Commerce (O'Reilly, 2016), you find a passage on API gateways that takes on a new significance in 2026.
Goetsch describes the API gateway as an aggregator layer: "A web page or screen on a mobile device might require retrieving data from dozens of different microservices. Each of those clients will need data tailored to it." He then names API gateways as "often called 'Backends for your Frontend'", BFF for short.
The idea: a dedicated aggregator layer that returns different data shapes depending on consumer context. Apple Watch needs one attribute. Web page needs twenty. Mobile app needs fifteen different ones. The BFF handles this aggregation and transformation.
Ten years later, this layer is more important than ever. Not because of new devices. Because of a new class of API consumers: AI agents.
What the BFF pattern meant in 2016
In Goetsch's model, the BFF is an optimisation layer for user interfaces. It solves a concrete performance problem: if a mobile app client had to call directly against dozens of microservices, too many round-trips would occur, too much overfetching (too much data for the context), too much coupling between client and individual microservices.
The BFF handles this coordination server-side:
- It aggregates data from multiple microservices into a single response
- It transforms data into the optimal shape for the client
- It keeps client-side logic out of the microservices themselves
Goetsch also warns about the anti-pattern: "The issue with API gateways is that they become tightly coupled monoliths because they need to know how to interact with every client (dozens) and every microservice (dozens, hundreds or even thousands). The very problem you sought to remedy with microservices can reappear if you're not careful."
That is the BFF core tension that emerged in 2016 and still holds in 2026.
What AI agents mean as a new consumer class
In 2026, there is a new class of API consumers for which Goetsch's BFF concept is directly relevant: AI agents.
AI agents, whether as buyer agents (searching and purchasing products on behalf of customers), productivity agents (creating content or optimising campaigns on behalf of commerce teams) or service agents (handling customer communication), consume commerce APIs in a fundamentally different way from classical UIs.
The difference from a classical UI:
A classical web UI is operated by humans. It follows a predetermined user journey: category page → product detail page → basket → checkout. The API calls are predictable, their schema is documented, their sequence is defined.
An AI agent follows no predetermined journey. It plans its actions dynamically based on goal and context. It needs:
- Machine-readable schemas: Not just "what does the API return" but "what can this API do", Swagger/OpenAPI alone is insufficient; semantic descriptions of actions are needed.
- Tool manifests: A list of available actions (search product, add to cart, apply coupon, check inventory) with their parameters and side effects.
- Action semantics: Not just read APIs, but actions with defined preconditions, postconditions and failure behaviour.
- State tracking: Agents need a mechanism to maintain current context (basket, session, user profile) across multiple calls.
This is fundamentally different from a UI-optimised REST API.
BFF 2.0: an agent-capable aggregation layer
The implication: BFFs need to be designed differently for agents than for UIs. A modern BFF in an agentic commerce context has two layers:
Layer 1: The classical BFF layer (for UIs) Aggregates microservice data into UI-optimised response shapes. Functions as described in 2016.
Layer 2: The agent interface layer (new) Exposes not page-oriented views but tool interfaces:
searchProducts(query, filters, maxResults), returns structured product list, agent-readableaddToCart(productId, quantity, customerId), idempotent action with explicit result stategetInventory(productId, warehouseContext), real-time, strongly consistent (no cache)applyPromotion(cartId, promoCode), with explicit success/failure schemainitiateCheckout(cartId, paymentContext), with complete error manifest
Each of these actions is designed for machine-to-machine consumption: clearly defined input schema, clearly defined output schema, clearly defined error codes, idempotent where possible.
Goetsch describes in a different context the HATEOAS idea (Level 3 REST): "The APIs become self-documenting, allowing the caller of the API to very easily interact with the API and not know very much about it." That is exactly the principle that applies to agent interfaces in modern form, but with a tool manifest instead of HATEOAS links.
Why the frontend layer is the natural place for the agent layer
Here is the non-obvious argument: the agent layer does not belong in the backend. It belongs in the frontend management tier.
Why? Because agents, whether buyer agents or productivity agents, need access to the composited state of the commerce stack: the current price for this user, in this market, with these active promotions, with this inventory situation. This composited state does not exist in any single backend microservice. It is created through the aggregation of multiple microservices, exactly what the BFF does.
An FMP that already manages this aggregation layer is the natural place to also expose agent tool interfaces. The FMP already knows:
- Which microservices are responsible for which data
- Which caching policies apply to which data
- Which personalisation rules are active for which user
- Which markets and localisations exist
An agent accessing this FMP layer receives composited, personalised, market-aware data, without the agent logic having to carry that complexity itself.
Larry AI: Laioutr's approach to agentic commerce
Laioutr's Agentic Frontend Management Platform exposes not only page rendering. It exposes agent tool interfaces as a first-class feature.
Larry AI, Laioutr's integrated AI agent, demonstrates this pattern: it works on the same FMP layer that serves the classical UIs. It can search products, execute basket actions, apply personalisation rules and test content variants, not through direct backend microservice calls, but through the defined tool interfaces of the FMP.
This means: new AI agents can build on an already existing, well-structured aggregation layer, instead of starting from scratch each time. New commerce capabilities (a new microservice in the backend) are registered once in the FMP tool interface layer and are immediately available to all agents.
This is the direct evolution of Goetsch's BFF concept: from "Backend for your Frontend" to "Backend for your Agents and Frontends."
Requirements for agentic readiness in your commerce stack
If you are planning today to integrate AI agents into your commerce stack, these are the questions that determine success:
1. Do your APIs have machine-readable schemas? OpenAPI spec is a start. But for agent consumption you need semantic descriptions: what is the intent of this action? What are the side effects?
2. Do you have an aggregation layer that exposes composited state? An agent that has to call directly against 20 microservices is not an agent, it is a script with a lot of error handling. You need a BFF layer that handles composition.
3. Are your commerce actions idempotent? Agents can execute actions multiple times (retry logic, parallelism). If "add to cart" is not idempotent, duplicate orders occur. That is not an AI problem, it is an API design problem.
4. Do you have a state layer for agent sessions? A buyer agent preparing a purchase across multiple interactions needs persisted state: active basket, saved products, ongoing negotiation with a service agent. This state needs to exist in the FMP layer, not in the agent itself.
5. How do you isolate agent traffic from UI traffic? Agents can generate burst traffic (parallel reasoning, multiple tool calls per second). You need rate limiting and throttling on the agent interface layer that does not affect your UI traffic.
Conclusion: the BFF from 2016 is the agent layer foundation of 2026
Goetsch's description of the API gateway as "Backend for your Frontend" was in 2016 a pragmatic architecture decision for multi-channel UI optimisation. In 2026, the same layer is the decisive lever for agentic commerce.
The continuity is direct: BFF thinking, a dedicated aggregation layer that decouples consumers from backend complexity, is not outdated. It is the architecture foundation for everything that comes after the classical web UI.
The difference is: consumers are no longer only human users. They are buyer agents, productivity agents, service agents. And these new consumers need a layer that goes beyond page rendering: tool interfaces, action semantics, machine-readable schemas.
An FMP that manages this layer today is not only an optimisation for existing UIs. It is the infrastructure for commerce in the next decade.
More on how the decade retrospective of the Goetsch book frames the other developments: 10 Years of Microservices in Commerce. And on how eventual consistency works in agent flows: Eventual Consistency in the Composable Storefront.
[See Larry AI in action, book a free demo](https://www.laioutr.com/demo)
Source: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.