Giving an LLM real hands

Function-calling that drives a real WooCommerce cart on a live store

Most "AI chatbots" on shopping sites can talk but can't do anything — they answer, then leave the customer to go find and click everything themselves. On a building-materials store I built a sales chatbot with a different goal: it should recommend the right product out of thousands of SKUs and then act — add it to the cart, adjust quantities, open checkout — all inside one chat window. This is a write-up of how that works, why the interesting part is the function-calling contract and the tool layer, not the prompt, and the production traps I hit making it reliable.

01The problem: an assistant that can act

The store runs on WordPress + WooCommerce. A shopper asking "tôi cần gạch ốp lát phòng tắm" doesn't want a paragraph — they want the two or three right products and a fast path to buy. So the chatbot needs three capabilities beyond chatting: retrieve matching products from the live catalog, render them as real product cards, and mutate the cart on the customer's behalf. The last one is where an LLM stops being a text box and starts being an agent with tools.

02Architecture: keep the model on the server

The whole thing is a self-contained WordPress plugin. The browser widget is deliberately dumb: it renders messages and calls one endpoint. The LLM lives server-side, reached through OpenRouter (one endpoint, swappable models, no lock-in). The API key never touches the client.

  Browser widget (vanilla JS)
        │  POST { messages: last 10, page_url }   + X-WP-Nonce
        ▼
  Plugin REST route  (WordPress)  ──►  OpenRouter  ──►  LLM
        │                                   │
        │            structured JSON  ◄──────┘
        │      { reply, products[], add[] }
        ▼
  Widget renders reply + product cards, then EXECUTES actions
        │
        ▼
  WooCommerce Store API   (view / add / update / remove / checkout)

Two design decisions matter here. First, the API key is a server secret — a browser-side LLM call would leak it to anyone who opens devtools. Second, the model never touches the database directly. It emits intents; the client turns them into calls against WooCommerce's official Store API. That boundary is what keeps a chatty model from becoming a security problem.

03Context: last 10 messages + the page

Every turn sends the last 10 messages (a rolling window — enough memory to stay coherent, bounded so tokens and latency stay flat) plus the current page URL. That URL is cheap grounding: if the customer is already on a product page, the model can talk about this product without being told which one.

04The contract: structured output as the tool interface

The heart of the system is the shape of what comes back. The LLM doesn't return prose — it returns a small JSON object the client knows how to act on:

{
  "reply": "Dạ bên em gợi ý 2 mẫu gạch ốp phòng tắm chống trơn ạ:",
  "products": [
    { "id": 1841, "name": "...", "price": "...", "image": "...", "url": "...", "addable": true }
  ],
  "add": [ { "url": "https://.../san-pham/..." } ]   // an action: put this in the cart
}

Three channels in one response:

• reply — the text bubble (light markdown: links, bold, prices auto-styled).
• products — structured cards with image, price, quantity stepper and an add button. A card is not a link the customer has to decode; it's the product, ready to buy.
• add — a function call. When the customer says "thêm mẫu đầu vào giỏ giúp em", the model doesn't describe how; it emits an add intent and the client performs it.

This is function-calling in spirit: the model chooses an action and its arguments; deterministic code validates and executes it. The LLM proposes; the commerce API disposes.

05The tool layer: driving a real cart

Actions run against the WooCommerce Store API — the same API the theme's own cart uses — so the chatbot's cart is the site's cart. Inside the chat the customer can view the cart, change quantities, remove lines, see the live total, and jump to checkout. Two things made this genuinely hard in production:

• Nonce lifecycle. The Store API is protected by a rotating Nonce header. Every response can hand back a fresh nonce, so the client has to capture and reuse the latest one on every call — cache a stale nonce and the next +/− or remove silently fails.
• The cache trap. The site runs LiteSpeed cache, which happily cached the GET cart REST response — serving a stale cart with an expired nonce key and breaking the quantity buttons. The fix: bust it explicitly (cache: 'no-store' + a ?_=timestamp param) on every cart read. This is the kind of bug that only shows up on a real, cached, production host — never on localhost.

Add-to-cart also refreshes the theme's own cart fragments and fires WooCommerce's added_to_cart event, so the header cart count and the theme drawer stay in sync — the chatbot feels like part of the store, not a bolted-on widget. When the theme's slide-out cart opens, a MutationObserver hides the chatbot so the two never overlap.

06Safety & failure modes

• Treat model output as data, not commands. An add intent resolves to a server-verified product id before anything touches the cart; the client never executes arbitrary instructions from the model.
• Key isolation. The model runs server-side; the browser only ever sees the structured reply.
• Graceful degradation. If the network or the model hiccups, the bot falls back to a human handoff (hotline) instead of dead-ending — every failure path ends somewhere useful.

07What it does, live

The result is a 24/7 assistant that advises, recommends real products, fills the cart, and walks the customer to checkout — one conversation, no page hunting. It's live in production on a real store. You can open the chat bubble on tanphatsolutions.vn and ask it for a product.

08Takeaways

• The prompt is the easy part. The engineering is the contract (structured output), the tool layer (a real, stateful commerce API), and the boundary between them.
• Function-calling = a model that acts. The moment the model can emit an action the client will execute, a chatbot becomes an agent — and the whole game becomes making those actions safe and reliable.
• Production is where the real bugs live. Rotating nonces and a caching layer don't exist on your laptop; budget for them.