Google shows HappyDelivery, a multi-agent grocery chat prototype on GCP

From blueprint to prototype

The post, written by software engineer Prateek Khushalani and dated Oct. 27, 2026, follows an earlier article on building conversational commerce with multi-agent swarms on GCP. That article proposed a 3-layer decoupled design made up of Ingress, Memory and Cognition, intended to address messaging timeouts, state tracking and response reliability.

The new post turns that design into software. According to the author, it walks through the code, the state machine, deterministic financial tools and an automated verification suite that shows how the swarm operates in practice. The example scenario is a shopper texting that the household is out of milk and eggs and asking to add snacks for a Friday movie night.

Layer 1: one gateway for many messaging channels

The Ingress layer runs as a webhook gateway on GKE or Cloud Run with Cloud Pub/Sub. The post says all major consumer messaging platforms share the same basic contract: an asynchronous HTTPS POST webhook with a strict acknowledgement timeout. It covers four channels:

• WhatsApp (Meta Cloud API): requires a prompt HTTP 200 OK and validation of the X-Hub-Signature-256 header with HMAC-SHA256. If the server times out or returns a non-200 status, Meta marks delivery as failed and retries with exponential backoff for up to 7 days, which can cause duplicate order deliveries.
• Google RCS Business Messaging: delivered through Pub/Sub push or HTTPS webhooks, with OAuth2, Service Account JWT bearer tokens or payload HMAC signature verification.
• Apple Messages for Business: delivered through an Apple-approved Messaging Service Provider and authenticated with provider webhook signatures, JSON Web Signatures or Mutual TLS.
• SMS and MMS: providers such as Twilio, Sinch and Infobip send form-encoded or JSON webhooks signed with vendor-specific HMAC tokens.

To hide these differences, the layer uses platform-specific signature validators and a payload normalization adapter. The adapter converts each vendor payload into a channel-agnostic schema called CommonMessageEvent, with fields for channel, sender ID, text, timestamp and raw metadata. The message is queued on Pub/Sub and HTTP 200 OK is returned in under 150ms, so the session store and agent swarm only see normalized data.

Layer 2: session and cart state in Redis

Because messaging platforms are stateless and each text arrives as an isolated event, the prototype keeps context in Cloud Memorystore (Redis), keyed by the customer's verified phone number. The post describes several customer journeys this supports.

• Pause and resume: a customer who adds milk at 9:00 AM and returns at 2:00 PM to add bread and eggs has the cart restored and totals recalculated.
• Contextual guardrails: a profile with a nut-free dietary preference is respected by the Inventory Agent when it suggests snacks.
• Tokenized checkout: the language model only sees a masked label such as "Visa ending in 4242", while transaction tools pass a tokenized customer ID to Stripe. According to the post, raw card numbers never touch chat prompts or logs.

On performance, the author states that a baseline Memorystore for Redis instance (Basic Tier, 1 to 5 GB) delivers 10,000 to 50,000+ QPS with sub-millisecond latency. With 2 to 3 Redis operations per chat turn, that equals 3,000 to 15,000 conversational turns per second. An active session takes roughly 2 KB to 5 KB, so a 5 GB instance can hold over 1,000,000 concurrent carts, according to the post.

Layer 3: a swarm of specialized agents

Instead of one monolithic prompt, the Cognition layer splits work among specialists built on Gemini:

• Supervisor (Gemini Flash): a low-latency router that classifies requests and delegates them.
• Profile Specialist: retrieves preferences and issues secure single-use auth links for new buyers.
• Inventory Specialist (Gemini Pro): bound to warehouse tools, it queries stock, recommends pairing items and changes the cart.
• Transaction Specialist (Gemini Pro): bound to payment tools, it calculates totals deterministically and starts charges.

The Layer 1 code is written in Python with FastAPI and Pydantic, using pluggable adapters for each channel.

What it means for developers

The post offers developers a concrete reference for building chat-based shopping on Google Cloud: normalize inbound channels early, acknowledge webhooks fast, keep state outside the model, and limit what the model can see around payments. The source text provided here is cut off during the Layer 1 code, so details of the remaining code and the verification suite are not covered in this report.