Vom API-Gateway zum AI-Agent-Layer: Wie das BFF-Pattern Agentic Commerce möglich macht

Wenn du dir Kapitel 4 von Kelly Goetschs Microservices for Modern Commerce (O'Reilly, 2016) anschaust, findest du eine Passage über API-Gateways, die 2026 plötzlich eine neue Bedeutung bekommt.

Goetsch beschreibt das API-Gateway als Aggregator-Schicht: "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." Und er nennt API-Gateways "often called 'Backends for your Frontend'", kurz BFF.

Die Idee: Eine dedizierte Aggregator-Schicht, die je nach Consumer-Kontext unterschiedliche Daten-Shapes zurückgibt. Apple Watch braucht ein Attribut. Web-Seite zwanzig. Mobil-App fünfzehn andere. Das BFF übernimmt diese Aggregation und Anpassung.

Zehn Jahre später ist diese Schicht wichtiger als je zuvor. Nicht wegen neuer Geräte. Sondern wegen einer neuen Klasse von API-Consumern: AI-Agents.

Was BFF-Pattern 2016 bedeutete

In Goetschs Modell ist das BFF eine Optimierungsschicht für User Interfaces. Es löst ein konkretes Performance-Problem: Wenn ein Mobile-App-Client direkt gegen Dutzende von Microservices calling müsste, entstünden zu viele Round-Trips, zu viele Overfetches (zu viele Daten für den Kontext), zu viel Coupling zwischen Client und einzelnen Microservices.

Das BFF übernimmt diese Koordination serverseitig:

• Es aggregiert Daten aus mehreren Microservices in einem einzigen Response
• Es transformiert Daten in das für den Client optimale Shape
• Es hält Client-seitige Logik aus den Microservices heraus

Goetsch warnt dabei auch vor dem 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."

Das ist die BFF-Grundspannung, die 2016 entstanden ist und 2026 noch immer gilt.

Was AI-Agents als neue Consumer-Klasse bedeuten

2026 gibt es eine neue Klasse von API-Consumern, für die Goetschs BFF-Konzept direkt relevant ist: AI-Agents.

AI-Agents, ob als Buyer-Agents (die im Auftrag von Kunden Produkte suchen und kaufen), als Productivity-Agents (die im Auftrag von Commerce-Teams Inhalte erstellen oder Kampagnen optimieren) oder als Service-Agents (die Kundenkommunikation übernehmen), konsumieren Commerce-APIs auf eine fundamental andere Weise als klassische UIs.

Der Unterschied zur klassischen UI:

Eine klassische Web-UI wird von Menschen bedient. Sie folgt einer vorherbestimmten User-Journey: Kategorie-Seite → Produktdetailseite → Warenkorb → Checkout. Die API-Calls sind vorhersehbar, ihr Schema ist dokumentiert, ihre Reihenfolge ist definiert.

Ein AI-Agent folgt keiner vorherbestimmten Journey. Er plant seine Actions dynamisch basierend auf Ziel und Kontext. Er braucht:

• Maschinenlesbare Schemas: Nicht nur "was gibt die API zurück", sondern "was kann diese API tun", Swagger/OpenAPI allein reicht nicht, es braucht semantische Beschreibungen von Actions.
• Tool-Manifests: Eine Liste von verfügbaren Actions (search product, add to cart, apply coupon, check inventory) mit ihren Parametern und Seiteneffekten.
• Action-Semantik: Nicht nur Read-APIs, sondern Actions mit definierten Preconditions, Postconditions und Fehler-Verhalten.
• State-Tracking: Agents brauchen einen Mechanismus, um den aktuellen Kontext (Warenkorb, Session, User-Profil) über mehrere Calls hinweg zu halten.

Das ist fundamental anders als eine UI-optimierte REST-API.

BFF 2.0: Agent-fähige Aggregationsschicht

Die Konsequenz: BFFs müssen für Agents anders gestaltet werden als für UIs. Ein modernes BFF im Agentic-Commerce-Kontext hat zwei Schichten:

Schicht 1: Die klassische BFF-Schicht (für UIs) Aggregiert Microservice-Daten in UI-optimierte Response-Shapes. Funktioniert wie 2016 beschrieben.

Schicht 2: Die Agent-Interface-Schicht (neu) Exposed keine Seiten-orientierten Views, sondern Tool-Interfaces:

• searchProducts(query, filters, maxResults), gibt strukturierte Produktliste zurück, Agent-lesbar
• addToCart(productId, quantity, customerId), idempotente Action mit explizitem Ergebnis-State
• getInventory(productId, warehouseContext), real-time, strong consistent (kein Cache)
• applyPromotion(cartId, promoCode), mit explizitem Success/Failure-Schema
• initiateCheckout(cartId, paymentContext), mit vollständigem Error-Manifest

Jede dieser Actions ist für Machine-to-Machine-Consumption designed: klar definiertes Input-Schema, klar definiertes Output-Schema, klar definierte Error-Codes, idempotent wo möglich.

Goetsch beschreibt in einem anderen Kontext die HATEOAS-Idee (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." Das ist genau das Prinzip, das für Agent-Interfaces in modernem Form gilt, aber mit Tool-Manifest statt HATEOAS-Links.

Warum der Frontend-Layer der natürliche Ort für den Agent-Layer ist

Hier ist die nicht-offensichtliche These: Der Agent-Layer gehört nicht ins Backend. Er gehört in die Frontend-Management-Schicht.

Warum? Weil Agents, ob Buyer-Agents oder Productivity-Agents, Zugriff auf den Composited-State des Commerce-Stacks brauchen: den aktuellen Preis für diesen Nutzer, in diesem Markt, mit diesen aktiven Promotions, mit dieser Inventory-Situation. Dieser Composited-State existiert nicht in einem einzelnen Backend-Microservice. Er entsteht durch die Aggregation mehrerer Microservices, genau das, was das BFF tut.

Ein FMP, das diese Aggregations-Schicht already managed, ist der natürliche Ort, um auch Agent-Tool-Interfaces zu exponieren. Der FMP kennt bereits:

• Welche Microservices für welche Daten zuständig sind
• Welche Caching-Policies für welche Daten gelten
• Welche Personalisierungs-Regeln für welchen Nutzer aktiv sind
• Welche Märkte und Localisierungen existieren

Ein Agent, der auf diese FMP-Schicht zugreift, bekommt composited, personalisiert, market-aware, ohne dass die Agent-Logik diese Komplexität selbst tragen muss.

Larry AI: Laioutrs Antwort auf Agentic Commerce

Laioutrs Agentic Frontend Management Platform exposed nicht nur Page-Rendering. Sie exposed Agent-Tool-Interfaces als First-Class-Feature.

Larry AI, Laioutrs integrierter AI-Agent, demonstriert dieses Muster: Er arbeitet auf derselben FMP-Schicht, die auch die klassischen UIs bedient. Er kann Produkte suchen, Warenkorb-Actions ausführen, Personalisierungs-Regeln anwenden und Content-Varianten testen, nicht durch direktes Backend-Microservice-Calling, sondern durch die definierten Tool-Interfaces der FMP.

Das bedeutet: Neue AI-Agents können auf einer bereits vorhandenen, gut strukturierten Aggregations-Schicht aufsetzen, anstatt jedes Mal von vorne anzufangen. Neue Commerce-Capabilities (neuer Microservice im Backend) werden einmal in der FMP-Tool-Interface-Schicht registriert und sind damit sofort für alle Agents verfügbar.

Das ist die direkte Evolution von Goetschs BFF-Konzept: Von "Backend for your Frontend" zu "Backend for your Agents and Frontends."

Anforderungen an deinen Commerce-Stack für Agentic Readiness

Wenn du heute planst, AI-Agents in deinen Commerce-Stack zu integrieren, sind das die Fragen, die über Erfolg und Misserfolg entscheiden:

1. Haben deine APIs maschinenlesbare Schemas? OpenAPI-Spec ist ein Start. Aber für Agent-Consumption brauchst du semantische Beschreibungen: Was ist die Intention dieser Action? Was sind die Seiteneffekte?

2. Hast du eine Aggregations-Schicht, die Composited-State exposed? Ein Agent, der direkt gegen 20 Microservices calling muss, ist kein Agent, er ist ein Skript mit viel Fehlerbehandlung. Du brauchst eine BFF-Schicht, die Komposition übernimmt.

3. Sind deine Commerce-Actions idempotent? Agents können Actions mehrfach ausführen (Retry-Logic, Parallelismus). Wenn "add to cart" nicht idempotent ist, entstehen doppelte Bestellungen. Das ist kein AI-Problem, das ist ein API-Design-Problem.

4. Hast du einen State-Layer für Agent-Sessions? Ein Buyer-Agent, der über mehrere Interaktionen hinweg einen Kauf vorbereitet, braucht persistierten State: aktiver Warenkorb, gemerkte Produkte, laufende Verhandlung mit einem Service-Agent. Dieser State muss in der FMP-Schicht existieren, nicht im Agent selbst.

5. Wie isolierst du Agent-Traffic von UI-Traffic? Agents können Burst-Traffic erzeugen (parallel reasoning, multiple tool calls pro Sekunde). Du brauchst Rate-Limiting und Throttling auf der Agent-Interface-Schicht, das deinen UI-Traffic nicht beeinflusst.

Fazit: Das BFF von 2016 ist die Agent-Layer-Grundlage von 2026

Goetschs Beschreibung des API-Gateways als "Backend for your Frontend" war 2016 eine pragmatische Architektur-Entscheidung für Multi-Channel-UI-Optimierung. 2026 ist dieselbe Schicht der entscheidende Hebel für Agentic Commerce.

Die Kontinuität ist direkt: BFF-Thinking, eine dedizierte Aggregations-Schicht, die Consumers von Backend-Complexity entkoppelt, ist nicht veraltet. Es ist die Architektur-Basis für alles, was nach dem klassischen Web-UI kommt.

Der Unterschied ist: Consumers sind nicht mehr nur menschliche Nutzer. Sie sind Buyer-Agents, Productivity-Agents, Service-Agents. Und diese neuen Consumers brauchen eine Schicht, die über Page-Rendering hinausgeht: Tool-Interfaces, Action-Semantik, maschinenlesbare Schemas.

Ein FMP, das diese Schicht heute managed, ist nicht nur eine Optimization für bestehende UIs. Es ist die Infrastruktur für Commerce der nächsten Dekade.

Mehr dazu, wie die Decade-Retrospektive des Goetsch-Buchs die anderen Entwicklungen einordnet: 10 Jahre Microservices im Commerce. Und wie Eventual Consistency in Agent-Flows funktioniert: Eventual Consistency im Composable-Storefront.

[Larry AI in Action sehen, kostenfreie Demo buchen](https://www.laioutr.com/demo)

Quelle: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.