The single hardest problem in commerce AI is not making an assistant sound helpful — language models are already good at that. It is stopping the assistant from being confidently wrong. An agent that invents a product, misquotes a price, or claims something is in stock when it is not does real damage to a real store. When we built Kiln, the agent layer behind our store Frela, every architectural decision flowed from one rule: the agent can only say what the catalogue actually knows. Here is how we enforced that.
Retrieval before generation
The pattern underneath Kiln is retrieval-augmented generation, applied strictly. Nothing the model says about products comes from its training data or its imagination — it comes from a retrieval step that runs first. We embed the catalogue into vectors, store them, and at query time we fetch the closest real products and pass only those to the model as context. The model’s job is to interpret the customer’s intent and explain the retrieved options, not to be the source of facts. Generation without retrieval is where hallucinated products come from; putting retrieval first closes that door.
Why pgvector
We store embeddings in Postgres using the pgvector extension rather than reaching for a dedicated vector database. For a catalogue the size of a single store, Postgres handles vector similarity search comfortably, and keeping vectors in a familiar database meant one less moving part to operate, back up, and reason about. Kiln runs its own Postgres instance — separate from the commerce backend — so we can reindex, change dimensions, or experiment with embedding strategies without touching the database that processes orders.
Semantic search beats keyword search for shoppers
Customers do not search the way a SQL LIKE clause wants them to. They type “something cosy for a north-facing living room” or “a bed that won’t overwhelm a box room.” Keyword search falls apart on phrasing like that; semantic search thrives on it. By embedding both the catalogue and the customer’s natural-language query into the same vector space, Kiln can match on meaning rather than exact words — surfacing the low-profile oak frame for the box-room question even if the listing never used the word “small.”
Tool calling closes the loop
Retrieval grounds what the agent knows; tool calling grounds what it can do. Kiln cannot free-text a product detail — it has to call a tool such as search products or get product, and that tool returns structured data straight from the catalogue. This matters more than it first appears: it means the price, the title, and the availability a customer sees in the conversation are the same values the store would render on the product page, because they come from the same source. The model orchestrates; the tools provide the facts.
From recommendation to cart
A grounded answer is useful, but a grounded action is what moves a sale forward. Kiln’s toolkit goes beyond search: it can fetch recommendations for a product the customer is looking at, and it can add an item to the cart on request. Because those operations run through the same tool boundary as everything else, “add the walnut version to my basket” becomes a real, auditable action against the real cart — not a polite simulation that leaves the customer to go and do it themselves.
Guardrails: the catalogue is the source of truth
The strongest guardrail in Kiln is structural rather than written into a prompt. Because prices, stock, and product details only ever enter the conversation through tool results, the model is never in a position to make them up. We do not have to ask it nicely not to hallucinate a discount — it simply has no path to invent one. Prompt instructions still matter for tone and behaviour, but we treat them as a complement to the architecture, not a substitute for it. Trust comes from the data flow, not from politeness.
Keep the model swappable
Models change fast, so we kept the chat model behind a provider abstraction. Kiln can run on Anthropic, OpenAI, or Gemini, and moving between them is a configuration change. We pin one thing deliberately: embeddings always go through OpenAI, so the vector space stays stable even as the chat model rotates. The result is a system where we can adopt a better or cheaper model the week it ships, without re-grounding the entire catalogue or rewriting the agent.
Takeaways for building commerce agents
If you take one thing from how we built Kiln, make it this: ground the agent in retrieval and constrain it with tools before you spend any time tuning prompts. Embed your catalogue and retrieve real products before the model speaks. Route every fact through a tool that reads your source of truth, so prices and stock can never be invented. Keep the toolkit small and the agent service isolated from the systems that handle money. Do those things and the model underneath becomes a swappable detail — which is exactly what you want it to be.