Applying GenAI design patterns to a real project

I have been building AI systems professionally for a few years now, and something that keeps frustrating me is the gap between what works in a demo and what survives in production. Every conference talk shows a chatbot answering questions about a PDF. Every tutorial builds a RAG pipeline that retrieves three documents and calls it done. Meanwhile the actual problems (how do you stop an agent from hallucinating a price, how do you coordinate five agents that share state, how do you generate product descriptions that actually convert) tend to get figured out the hard way.

When I picked up Lakshmanan and Hapke’s Generative AI Design Patterns (O’Reilly, 2025), I was curious whether the 32 patterns they catalog would actually map to something I’m working on. Turns out, 29 of them do. The application is an AI agent system for an online educational toy store my family is setting up on WooCommerce. Support, product catalog, orders, marketing, inventory, all handled by specialized agents coordinated through Google ADK 2.0.

This is going to be a 10-part series documenting every pattern, every tradeoff, and the code that connects it all. Not hypothetical examples. Everything runs against a real store with real products and real consequences when the AI gets things wrong.

Why e-commerce

I picked this domain because it touches almost everything. You need content generation for product descriptions, knowledge grounding for support agents, tool integration for inventory and orders, safety mechanisms for prices and policies, and multi-agent coordination to tie it all together. It is hard to find another single application that exercises this many patterns at once.

The personal angle matters too. My wife and I are building this store for educational toys. STEM kits, Montessori materials, creative play sets. When I write about an agent that should never hallucinate a price, it’s because I genuinely need one that won’t tell a customer a $45 toy costs $29. When I write about RAG for support, it’s because our return policy has enough nuance that a generic chatbot will get it wrong in ways that cost us trust.

Building something your family depends on changes how you engineer it. You don’t ship a pattern because it’s clever. You ship it because your wife will text you at 11 PM if the agent sends someone the wrong tracking number.

All 32 patterns and where they fit

Here’s every pattern from the book, organized by chapter, and whether it applies to the store. Twenty-nine do. Three don’t.

Controlling Content Style (Chapter 2)

P1: Logits Masking, needs direct access to token-level generation, which means self-hosting models. Skipping it.

P2: Grammar, forces structured JSON outputs, essential for product data and order processing.

P3: Style Transfer, teaches the model our brand voice instead of writing generic copy.

P4: Reverse Neutralization, takes one description and restyles it for different channels (formal for Amazon listings, playful for Instagram).

P5: Content Optimization, uses preference tuning to A/B test which descriptions and email subject lines actually convert.

All four apply.

Adding Knowledge / RAG (Chapters 3 and 4)

This is where the bulk of the safety-critical work lives.

P6: Basic RAG, grounds every response in real product data, policies, and FAQs.

P7: Semantic Indexing: a parent searching for “STEM toys for 5 year olds” needs to match a product called “Junior Engineer Building Blocks Ages 4 to 6,” which keyword search will never do.

P8: Indexing at Scale, handles the fact that prices change, stock goes in and out, seasonal products rotate.

P9: Index-Aware Retrieval, covers HyDE for vague customer queries and GraphRAG for “what goes with this product” relationships.

P10: Node Postprocessing: reranking, deduplication, entity resolution before the LLM sees any of it.

P11: Trustworthy Generation: citations, confidence detection, knowing when to say “I don’t know” instead of guessing.

P12: Deep Search, enables multi-hop retrieval for complex gift research where simple queries aren’t enough.

Every single one applies.

Extending Model Capabilities (Chapter 5)

P13: Chain of Thought, adds step-by-step reasoning for marketing copy and order processing logic.

P14: Tree of Thoughts, explores multiple reasoning branches in parallel. Overkill here. Chain of Thought gets you most of the benefit at a fraction of the cost.

P15: Adapter Tuning, is fine-tuning for product domain knowledge and customer service tone.

P16: Evol-Instruct, generates training data for that fine-tuning without doing it all manually.

Three of four apply. Tree of Thoughts is the second skip.

Improving Reliability (Chapter 6)

P17: LLM-as-Judge, automates quality scoring for generated descriptions and support responses.

P18: Reflection, adds draft, critique, revise loops for marketing content.

P19: Dependency Injection, lets you swap models and mock payment gateways so you can actually test things.

P20: Prompt Optimization, handles systematic prompt updates when models change or the catalog shifts.

All four apply.

Agents Taking Action (Chapter 7)

P21: Tool Calling, turns WooCommerce API endpoints into functions the agent can invoke.

P22: Code Execution, lets the agent write SQL or Python for ad-hoc analytics.

P23: Multiagent Collaboration, is the supervisor pattern that ties the whole architecture together.

All three are core to the system.

Addressing Constraints (Chapter 8)

P24: Small Language Model, uses cheaper models for high-volume classification.

P25: Prompt Caching: the same 50 support questions account for 80% of traffic, so cache them.

P26: Inference Optimization, covers continuous batching and speculative decoding, but only if you self-host. Third skip.

P27: Degradation Testing, measures quality under load, not just uptime.

P28: Long-Term Memory, remembers customers across sessions. “Maya is turning 7 next month, here’s the next set in the series she started.”

Four of five apply.

Setting Safeguards (Chapter 9)

P29: Template Generation, creates product descriptions with verified price and spec slots that the LLM cannot override.

P30: Assembled Reformat: pull facts from the database, let the LLM only handle the presentation.

P31: Self-Check, uses log-probabilities to flag uncertain factual claims.

P32: Guardrails, blocks prompt injection, verifies prices, prevents unauthorized discounts.

All four are non-negotiable for anything customer-facing.

So three patterns don’t fit: Logits Masking and Inference Optimization both require self-hosted models, and Tree of Thoughts adds cost without proportional benefit for the types of reasoning this system needs. Everything else maps to a real problem.

The architecture

The system follows a hub-and-spoke pattern. A Store Manager workflow classifies incoming requests and routes them to specialist agents. Each agent owns its own tools, instructions, and slice of the WooCommerce API.

                        ┌─────────────────┐
                        │  Store Manager  │
                        │   (Workflow)    │
                        └────────┬────────┘
                                 │
              ┌──────────┬───────┼───────┬──────────┐
              │          │       │       │          │
              ▼          ▼       ▼       ▼          ▼
        ┌──────────┐ ┌────────┐ ┌─────┐ ┌─────────┐ ┌──────────┐
        │ Support  │ │Catalog │ │Order│ │Marketing│ │Inventory │
        │  Agent   │ │ Agent  │ │Agent│ │  Agent  │ │  Agent   │
        └────┬─────┘ └───┬────┘ └──┬──┘ └────┬────┘ └────┬─────┘
             │           │        │          │           │
             ▼           ▼        ▼          ▼           ▼
        ┌─────────────────────────────────────────────────────┐
        │              WooCommerce REST API (v3)              │
        └─────────────────────────────────────────────────────┘

The Support Agent handles product questions, order status, and returns using RAG over product docs and store policies. The Catalog Agent writes and updates product descriptions using style transfer and template-based fact filling. The Order Agent processes orders, refunds, and shipping with human-in-the-loop approval for anything financial. The Marketing Agent writes emails and promotions using chain-of-thought reasoning and self-critique loops. The Inventory Agent monitors stock and forecasts demand by writing and executing analytical queries.

The Store Manager itself does no work. It classifies and routes. That separation is what lets you develop, test, and deploy each agent independently.

Why ADK 2.0

I went with Google’s Agent Development Kit 2.0 as the orchestration layer, mainly for three reasons.

First, ADK 2.0 introduced a Workflow class that models agent coordination as a directed graph (the thing I like about Langgraph). Nodes are agents or functions, edges define routing logic. That maps directly to the Store Manager architecture: classify intent at the root, route to specialists at the leaves.

Second, tool calling is built in. WooCommerce API endpoints become Python functions with type hints. The agent decides when to call them, ADK handles serialization and error handling.

Third, agents communicate through typed Event objects instead of passing strings around. When the Order Agent needs to hand structured data to the Inventory Agent for a stock adjustment, that matters.

ADK 2.0 is still in alpha, so the APIs will change. I’m building against it deliberately because the concepts (Workflow graphs, Events, collaborative agents) are stable ideas even if the syntax moves. The patterns outlast the framework version.

Here’s the skeleton. It starts with two agents and grows from there across the series:

from google.adk import Agent, Workflow, Event
from woocommerce import API as WooAPI

woo = WooAPI(
    url="https://yourstore.com",
    consumer_key="ck_xxx",
    consumer_secret="cs_xxx",
    version="wc/v3",
)

def search_products(query: str, category: str = None):
    params = {"search": query, "per_page": 5}
    if category:
        params["category"] = category
    return woo.get("products", params=params).json()

def get_order(order_id: int):
    return woo.get(f"orders/{order_id}").json()

support_agent = Agent(
    name="support_agent",
    model="gemini-2.5-flash",
    instruction="Help customers with product questions and order inquiries.",
    tools=[search_products, get_order],
    mode="task",
)

catalog_agent = Agent(
    name="catalog_agent",
    model="gemini-2.5-flash",
    instruction="Generate product descriptions and recommendations.",
    tools=[search_products],
    mode="task",
)

def classify_intent(node_input: str):
    if "order" in node_input.lower():
        return Event(route=["ORDER"])
    return Event(route=["PRODUCT"])

root_agent = Workflow(
    name="ecommerce_store",
    edges=[
        ("START", classify_intent),
        (classify_intent, {
            "PRODUCT": support_agent,
            "ORDER": support_agent,
        }),
    ],
)

By the end of the series, this two-agent skeleton becomes a five-agent system handling real traffic.

What’s coming

The series is structured so each post picks a specific agent and the 2 to 4 patterns that power it:

Every post includes working code and the specific tradeoffs I ran into building against a live WooCommerce instance. I’ll try to be honest about what worked and what didn’t.

The next post dives into the Support Agent and the four RAG patterns that keep it from hallucinating our return policy. Read it here.

Thanks for reading.