Google zeigt HappyDelivery: Multi-Agenten-Prototyp für den Lebensmitteleinkauf per Chat auf der GCP

Vom Entwurf zum Prototyp

Der Beitrag stammt vom Software-Entwickler Prateek Khushalani und ist auf den 27. Oktober 2026 datiert. Er knüpft an einen früheren Artikel über den Aufbau von Conversational Commerce mit Multi-Agenten-Schwärmen auf der GCP an. Dieser schlug eine entkoppelte Architektur mit drei Schichten vor, bestehend aus Ingress, Memory und Cognition, die Probleme mit Timeouts bei Messaging-Diensten, der Zustandsverfolgung und der Verlässlichkeit von Antworten lösen soll.

Der neue Beitrag setzt diesen Entwurf in Software um. Laut dem Autor führt er durch den Code, die Zustandsmaschine, deterministische Finanzwerkzeuge und eine automatisierte Verifikations-Suite, die zeigt, wie der Schwarm in der Praxis arbeitet. Das Beispielszenario: Ein Kunde schreibt, dass im Haushalt Milch und Eier ausgegangen sind, und bittet darum, Snacks für einen Filmabend am Freitag hinzuzufügen.

Schicht 1: ein Gateway für viele Messaging-Kanäle

Die Ingress-Schicht läuft als Webhook-Gateway auf GKE oder Cloud Run mit Cloud Pub/Sub. Dem Beitrag zufolge folgen alle großen Messaging-Plattformen für Verbraucher demselben Grundprinzip: einem asynchronen HTTPS-POST-Webhook mit strengem Timeout für die Bestätigung. Behandelt werden vier Kanäle:

• WhatsApp (Meta Cloud API): erfordert ein umgehendes HTTP 200 OK und die Prüfung des Headers X-Hub-Signature-256 mit HMAC-SHA256. Läuft der Server in einen Timeout oder liefert einen Status ungleich 200, markiert Meta die Zustellung als fehlgeschlagen und wiederholt sie mit exponentiellem Backoff bis zu 7 Tage lang, was zu doppelt zugestellten Bestellungen führen kann.
• Google RCS Business Messaging: Zustellung per Pub/Sub-Push oder HTTPS-Webhooks, mit OAuth2, Service-Account-JWT-Bearer-Tokens oder Prüfung der HMAC-Signatur der Nutzdaten.
• Apple Messages for Business: Zustellung über einen von Apple zugelassenen Messaging Service Provider, authentifiziert mit Webhook-Signaturen des Anbieters, JSON Web Signatures oder Mutual TLS.
• SMS und MMS: Anbieter wie Twilio, Sinch und Infobip senden formularkodierte oder JSON-Webhooks, die mit herstellerspezifischen HMAC-Tokens signiert sind.

Um diese Unterschiede zu verbergen, setzt die Schicht auf plattformspezifische Signaturprüfer und einen Adapter zur Normalisierung der Nutzdaten. Der Adapter wandelt jede Herstellernachricht in ein kanalunabhängiges Schema namens CommonMessageEvent um, mit Feldern für Kanal, Absender-ID, Text, Zeitstempel und Roh-Metadaten. Die Nachricht wird in Pub/Sub eingereiht und HTTP 200 OK wird in unter 150 ms zurückgegeben, sodass Session-Speicher und Agenten-Schwarm nur normalisierte Daten sehen.

Schicht 2: Sitzungs- und Warenkorbzustand in Redis

Da Messaging-Plattformen zustandslos sind und jede Nachricht als isoliertes Ereignis eintrifft, hält der Prototyp den Kontext in Cloud Memorystore (Redis), adressiert über die verifizierte Telefonnummer des Kunden. Der Beitrag beschreibt mehrere Kundenabläufe, die dadurch möglich werden.

• Pausieren und Fortsetzen: Fügt ein Kunde um 9:00 Uhr Milch hinzu und kehrt um 14:00 Uhr zurück, um Brot und Eier zu ergänzen, wird der Warenkorb wiederhergestellt und die Summen werden neu berechnet.
• Kontextbezogene Leitplanken: Ein Profil mit nussfreier Ernährungspräferenz wird vom Inventory Agent berücksichtigt, wenn er Snacks vorschlägt.
• Tokenisierter Checkout: Das Sprachmodell sieht nur eine maskierte Bezeichnung wie "Visa endet auf 4242", während die Transaktionswerkzeuge eine tokenisierte Kunden-ID an Stripe übergeben. Laut Beitrag gelangen echte Kartennummern nie in Chat-Prompts oder Logs.

Zur Leistung gibt der Autor an, dass eine Basis-Instanz von Memorystore for Redis (Basic Tier, 1 bis 5 GB) 10.000 bis über 50.000 Abfragen pro Sekunde bei Latenzen im Submillisekundenbereich schafft. Bei 2 bis 3 Redis-Operationen pro Chat-Runde entspricht das 3.000 bis 15.000 Gesprächsrunden pro Sekunde. Eine aktive Sitzung belegt etwa 2 bis 5 KB, sodass eine 5-GB-Instanz laut Beitrag über 1.000.000 gleichzeitige Warenkörbe aufnehmen kann.

Schicht 3: ein Schwarm spezialisierter Agenten

Statt eines monolithischen Prompts verteilt die Cognition-Schicht die Arbeit auf Spezialisten, die auf Gemini basieren:

• Supervisor (Gemini Flash): ein Router mit niedriger Latenz, der Anfragen klassifiziert und weiterreicht.
• Profile Specialist: ruft Präferenzen ab und stellt für Neukunden sichere Einmal-Authentifizierungslinks aus.
• Inventory Specialist (Gemini Pro): an Lagerwerkzeuge angebunden, fragt er Bestände ab, empfiehlt passende Artikel und ändert den Warenkorb.
• Transaction Specialist (Gemini Pro): an Zahlungswerkzeuge angebunden, berechnet er Summen deterministisch und löst Abbuchungen aus.

Der Code für Schicht 1 ist in Python mit FastAPI und Pydantic geschrieben und nutzt austauschbare Adapter für jeden Kanal.

Was das für Entwickler bedeutet

Der Beitrag bietet Entwicklern eine konkrete Referenz für Chat-basiertes Einkaufen auf der Google Cloud: eingehende Kanäle früh normalisieren, Webhooks schnell bestätigen, den Zustand außerhalb des Modells halten und begrenzen, was das Modell rund um Zahlungen sehen kann. Der hier vorliegende Quelltext bricht mitten im Code von Schicht 1 ab, weshalb Details zum restlichen Code und zur Verifikations-Suite in diesem Bericht nicht behandelt werden.