Three layers where AI enters Sylius
We design and build AI agents that live inside the client's Sylius: in the checkout, in the merchandising layer, and in the pricing engine. Connected to the CRM, the ERP, and the catalog, they execute real actions on the store — they don't reply to chats.
Sylius provides the ideal technical substrate for putting agents into production: API Platform exposes REST and GraphQL on every domain entity, the pricing and checkout services are extensible via decorators, and checkout events flow into a bus an agent subscribes to without touching the core. That natural openness drops integration cost to a couple of weeks instead of months.
Here goes the architecture, the four use cases with the highest return, and the metrics that have moved on real client projects.
Case 1 — Assisted checkout agent
During the payment flow, an agent observes cart events in real time and decides whether to step in. The criterion isn't advertising but commercial: the agent weighs CRM signals (customer history, segment, last orders), catalog signals (stock, equivalent alternatives), and checkout signals (compatible products, applicable discounts). When an actionable decision appears — suggesting a complement that avoids a return, applying a contractual discount the B2B customer hadn't activated, flagging an available express shipping — it surfaces it over the checkout without breaking the flow.
Architecture: hook on the sylius.checkout.pre_complete event triggering the agent's query. The agent decides via tools over Sylius entities (OrderRepository, ProductRepository, PromotionRepository) and external sources (CRM, ERP). The agent's response returns to the checkout as an additional Twig component, not as a redirect.
Typical metric in B2B clients with complex catalogs: 8-14% average order value increase and a measurable drop in returns caused by product incompatibility.
Case 2 — Real-time merchandising
Traditional merchandising lives in pre-painted rules: cross-sell by category, up-sell by margin, recommendations by historical affinity. An agent adds a layer that reasons about the current session: what the customer has seen, what they discarded, what critical stock there is, what next restocks are arriving, what season is active.
Sylius exposes catalog and Channels via API Platform. The agent reads, decides, and writes — for example, reordering featured products on the B2B North Channel's home for customers with a technical profile during the session, or activating a dynamic bundle for customers who already own the base product.
Key piece: the agent doesn't write SQL against the client's database. It calls bounded tools (set_featured_products(channel_id, product_ids), activate_dynamic_bundle(rule_id)) the team controls, validates, and audits. No tool allowlist, no agent in production.
Case 3 — Dynamic pricing with commercial guardrails
Sylius's pricing engine supports complex rules out of the box: per-Channel catalogs, combinable promotions, volume discounts, per-customer pricing. An agent adds the layer the engine doesn't cover: real-time price adjustment based on signals — competition, demand, target margin, active contracts.
The agent doesn't write prices freely. It operates within commercial bands defined as Sylius rules: min_price, max_discount_pct, protected_skus, requires_approval_over. Pricing decisions inside the band get applied automatically; those approaching the threshold wait for review by a human salesperson with full context loaded.
In a B2B distributor client with per-customer negotiated pricing, this pattern lifted average margin by roughly 2 percentage points on non-strategic catalog, without affecting contract-agreed pricing. Key difference: critical decisions stay with the salesperson, not the agent.
Case 4 — Cart recovery via a conversational agent
A known percentage of abandoned carts responds to specific friction: doubts about shipping, returns, product features, or payment. A conversational agent integrated on WhatsApp, Telegram, or the store's chat picks up the conversation with full context from the client's Sylius: what they tried to add, which step they stopped at, who the customer is, what previous orders they have.
Architecture: webhook from Sylius on detected abandonment (with configurable window), agent operating via tools over OrderRepository and ShipmentMethodRepository, integration with WhatsApp Business API or a chat widget embedded in the store. When the conversation succeeds, it modifies the real Order: applies a discount, changes the shipping method, closes it.
Irreversible actions — closing an order with a discount, changing the address, modifying the payment method — always go through human approval when they exceed the agreed commercial threshold. The log stays in the agent's repository, replayable, auditable.
Architecture: Sylius API + agent + tools
The architecture common to all four cases:
- Sylius as system of record. The store's state — catalog, orders, customers, pricing — lives in Sylius. The agent doesn't duplicate data.
- API Platform as the contract. The agent consumes REST/GraphQL from Sylius, not direct SQL. Every operation goes through an endpoint with schema validation, permissions, and events.
- Bounded tools, not free access. Every agent action is exposed as a tool with a contract: typed parameters, valid ranges, scope of action. The agent can ask for whatever it wants; only what passes the contract gets executed.
- Events as entry point. The agent reacts to checkout, cart, and catalog events. Integration is event-driven, not polling.
- Guardrails and HITL. Critical operations require human approval. The log is complete: prompt, decision, parameters, result.
- Eval pipeline. Every use case has an evaluation dataset with real cases that runs after every prompt or model change. Operational metrics (success rate, cost per decision, response time) live on a dashboard.
Typical stack when we deliver the system: Sylius 2 · Symfony 7 · API Platform · agents orchestrated with a custom runtime on Quarkus or Node.js · custom MCP servers for the client's CRM/ERP · WhatsApp Business API or embedded chat · PostgreSQL · OpenTelemetry for traceability.
Metrics that matter
The metrics we watch in these systems are operational and comparable against a baseline without AI:
- Average order value: percentage variation by customer segment and Channel.
- Checkout conversion rate: percentage of started carts ending in a confirmed order.
- Average margin: percentage point on the catalog affected by dynamic pricing.
- Cart-recovery rate: abandonment conversations ending in a closed order.
- Cost per agent interaction: model tokens, external API calls, human time when HITL fired.
- Agent response time: p95 by decision type.
- Decision quality: weekly sampling reviewed by humans over critical cases.
These metrics get reported on a dashboard the e-commerce lead and the tech lead can access, not in a monthly report.
How we build it in production
The first deliverable of a Sylius + AI project is not code. It's the case map: what signals the system has, which decisions produce measurable return, which operational thresholds define HITL, which bounded tools the agent needs. On top of that map we set up the architecture: Sylius hooks, tools over API Platform, the orchestrated agent, the guardrails, the metrics dashboard.
The agent's repository lives next to the client's Sylius repository, versioned, with CI/CD and tests over the critical prompts. The pricing, merchandising, and promotion decisions the agent takes get recorded as domain entries in Sylius, not as black boxes in an external service. Traceability is executable from the first commit.
Behind each of these systems is a team of engineers who believe serious AI engineering applied to e-commerce starts by understanding the catalog, pricing, and customer — not by plugging the latest model into the checkout. Systems ready for production, not prototypes.
If your Sylius is already in production and you want to explore where AI brings real return on catalog, checkout, and pricing, we can audit your store and hand you the plan with the two or three highest-return cases for your business model before committing a single sprint.
