Why we're building a shopping agent for Sylius

TL;DR

• What it is: An assistant in your shop's chat that searches the catalog, compares products, builds the cart, quotes shipping and tracks orders, using your store's actual data. Plus an admin interface where store owners configure it, teach it and track its sales.
• What makes it different: It's a native Sylius plugin, not a connector to an external service. It reads your catalog live and works on the real Sylius cart. It runs on your own API key with the model you choose. In our tests, a conversation cost less than a cent.
• What it's built on: We ported Anthropic's reference implementation for commerce agents to PHP and Symfony, and released the reusable, commerce-independent core as an open-source, MIT-licensed bundle.
• How it stays accurate: Its guardrails are designed to resist prompt injection and prevent unsupported answers. It only shows products returned by its tools, with prices and other details fetched from your catalog.
• Where it stands: Most features are already working, tested on Sylius 2.0 to 2.3. This post walks through the whole thing.

We're looking for the first stores to run it. Let's talk

A request in plain language, answered with products from the catalog.

What is a shopping agent?

It does online what a salesperson does in a physical store. A shopper describes what they need in their own words ("a gift for a 6-year-old who likes building things, under $50"). The agent searches the catalog, asks a question when it needs more detail, presents options as cards, and adds the chosen product to the cart.

For developers: it's a model running in a standard agent loop. Given a goal ("a gift under $50"), it reasons about what to do, gathers context (the catalog, the cart, the store's policies), takes action through tools, follows procedures defined by skills (how to compare products, how to build a plan), asks clarifying questions when needed, and observes the results until the goal is achieved.

Why build one for Sylius?

The best-known e-commerce agents, like Fin and Gorgias, only work with Shopify. For Sylius, the options we found are hosted chatbots with a connector plugin that syncs your catalog to the vendor's servers, and the conversation happens there.

That works, but a copy of your catalog lives somewhere else, the agent knows your cart and shipping rules only through a sync, and the vendor decides which model runs and what each conversation costs. If you chose Sylius to keep control of your store and its infrastructure, that defeats the purpose.

Ours is a Sylius plugin. It reads the catalog live from your database, so there's no separate copy to keep in sync. It uses your own API key and the model you choose (Claude, OpenAI and others). You can even use different models for different tasks, such as a cheaper model for background work. In our tests, Claude Haiku 5.5 at low effort performs very well, and on average a conversation cost under US$0.006.

Only the conversation leaves your store.

What does it already do?

Here's what it does today, on the shop side and on the admin side.

For shoppers

• Search and compare. Finds products, compares them side by side and builds multi-item plans ("everything you need to start a balcony garden").
• Help choose. When educational selling is enabled, it asks two or three relevant questions before showing products in categories with a buying guide, then recommends complementary products based on the shopper's choices.
• Work on the real cart. Adds, updates and removes items in the Sylius cart.
• Quote shipping like checkout does. Uses the store's own shipping methods to calculate rates.
• Answer policy questions and track orders. Retrieves return, shipping and payment information from the store's own documents, and checks the signed-in customer's orders.
• Remember preferences. Keeps what the shopper said they like from one visit to the next.
• Stream answers as cards. Renders product carousels, comparisons, multi-item plans, order statuses and cart summaries as they're generated.

The agent builds the order; the shopper still pays at the store's checkout.

For store owners, in the Sylius admin

• Conversations. Read the full transcript of each one.
• Statistics. Track the carts and orders the agent helped with, assisted revenue and AI costs.
• Configuration per channel. Enable or disable the assistant, select the model, configure the channel's own API key (stored encrypted) and set spending caps.
• Tone of voice and selling style. Control how the assistant communicates and sells. Choose a ready-made selling style and adapt it to the store's needs, or create a custom one.
• Rules and knowledge. Define store-specific rules ("when someone is buying a gift, offer gift wrapping") and manage policies and buying guides directly in the admin, with drafts, version history and version comparisons. We'll cover this in a future post.

Everything the store controls lives in the Sylius admin, per channel.

How does it work under the hood?

An open-source core

It's based on Anthropic's guide to building shopping and merchant agents, The anatomy of effective commerce agents. The guide includes a reference implementation in Python. We ported it to PHP and Symfony, kept its architecture, and moved everything that isn't specific to commerce into an open-source (MIT-licensed) Symfony bundle (odiseoteam/ai-conversational-agent-bundle): the agent loop, skills, tool checks, fencing, memory, budgets, evals and streaming to the browser.

The shopping agent is one vertical built on top of that core. The same foundation can power other kinds of assistants. We'll cover that in a separate post.

Accuracy and guardrails

Without guardrails, a language model can hallucinate products, get prices wrong or promise delivery dates the store can't meet. The reference implementation handles this in code, not in the prompt. The guide calls it enforcement in the harness. These guardrails live in the open-source core, so anyone can inspect how they work, while the plugin applies them to the store's catalog, cart and orders:

• Provenance. The agent can only show or add products whose IDs have been returned by a tool during the current conversation. For developers, this works like a foreign-key constraint.
• Presentation tools. Cards are rendered through tools: the model identifies the products, and the server fills in prices, stock, images and links from the catalog.
• Grounding. Questions about the catalog, store policies or orders trigger a lookup before the agent answers.
• Fencing. Product descriptions, store documents and tool results are passed to the model as explicitly delimited data, so a prompt injection hidden in that content isn't treated as a command.

The model names the product. Your catalog fills in the card.

To verify these guardrails, each flow has its own evals: test cases that run the agent against a store and evaluate its behavior, from the tools it calls to the state of the cart it leaves behind. We'll cover these in a later post.

What's next

The next post will cover its capabilities in detail, how to configure it and what the admin interface looks like. After that, we'll share updates on running it in a real store in the coming weeks, speeding up turns with parallel tool calls and reducing the cost per turn through better prompt caching, among other things.

There's no public demo yet. We'd rather walk through it in this series while we continue polishing it. We'll start distributing the plugin once it's ready.

Not on Sylius, or not running a shop? The same foundation runs dedicated agents on other stacks and for other jobs: shopping, after-sales, customer support, or an assistant for a site that sells nothing at all. They run on your own infrastructure, not as a SaaS. Tell us what you need.