Tres capas donde la IA entra en Sylius
Diseñamos y desarrollamos agentes de IA que viven dentro del Sylius del cliente: en el checkout, en el merchandising y en el motor de pricing. Conectados al CRM, al ERP y al catálogo, ejecutan acciones reales sobre la tienda — no responden chats.
Sylius da el sustrato técnico ideal para meter agentes en producción: API Platform expone REST y GraphQL sobre cada entidad del dominio, los servicios de pricing y checkout son extensibles vía decoradores, y los eventos del checkout viajan a un bus al que un agente se suscribe sin tocar el core. Esa apertura natural reduce el coste de integración a un par de semanas en lugar de meses.
Aquí va la arquitectura, los cuatro casos de uso con mayor retorno y las métricas que se han movido en clientes en producción.
Caso 1 — Agente de checkout asistido
Durante el flujo de pago, un agente observa los eventos del carrito en tiempo real y decide si intervenir. El criterio no es publicitario sino comercial: el agente pesa señales del CRM (historial del cliente, segmento, last orders), del catálogo (stock, alternativas equivalentes) y del propio checkout (productos compatibles, descuentos aplicables). Cuando aparece una decisión accionable — sugerir un complemento que evita devolución, aplicar un descuento contractual que el cliente B2B no había activado, avisar de un envío express disponible — la presenta sobre el checkout sin romper el flujo.
Arquitectura: hook en el evento sylius.checkout.pre_complete que dispara la consulta al agente. El agente decide vía tools sobre las entidades de Sylius (OrderRepository, ProductRepository, PromotionRepository) y sobre fuentes externas (CRM, ERP). La respuesta del agente vuelve al checkout como un componente Twig adicional, no como un redirect.
Métrica habitual en clientes B2B con catálogo complejo: aumento de 8-14% en el ticket medio y reducción medible del % de devoluciones por incompatibilidad de producto.
Caso 2 — Merchandising en tiempo real
El merchandising tradicional vive en reglas pre-pintadas: cross-sell por categoría, up-sell por margen, recomendaciones por afinidad histórica. Un agente añade una capa que razona sobre la sesión actual: qué ha visto el cliente, qué ha descartado, qué stock crítico hay, qué próximas reposiciones llegan, qué temporada está activa.
Sylius expone el catálogo y los Channels vía API Platform. El agente lee, decide y escribe — por ejemplo, reordenando los productos destacados en la home del Channel B2B Norte para los clientes con perfil técnico durante la sesión, o activando un bundle dinámico para clientes que ya tienen el producto base.
Pieza clave: el agente no genera SQL sobre la base de datos del cliente. Llama a tools acotadas (set_featured_products(channel_id, product_ids), activate_dynamic_bundle(rule_id)) que el equipo controla, valida y audita. Sin allowlist de tools, no hay agente en producción.
Caso 3 — Pricing dinámico con guardrails comerciales
El motor de pricing de Sylius soporta reglas complejas de serie: catálogos por Channel, promociones combinables, descuentos por volumen, pricing por cliente. Un agente añade la capa que el motor no cubre: ajuste de precio en tiempo real con base en señales — competencia, demanda, margen objetivo, contratos vivos.
El agente no escribe precios libremente. Opera dentro de bandas comerciales definidas como reglas de Sylius: min_price, max_discount_pct, protected_skus, requires_approval_over. Las decisiones de pricing dentro de banda se aplican automáticamente; las que rozan el umbral se quedan en revisión para un comercial humano con todo el contexto cargado.
En un cliente distribuidor B2B con pricing negociado por cliente, este patrón aumentó el margen medio cerca de 2 puntos porcentuales sobre catálogo no estratégico, sin afectar al pricing pactado por contrato. La diferencia clave: las decisiones críticas siguen siendo del comercial, no del agente.
Caso 4 — Rescate de carritos vía agente conversacional
Un porcentaje conocido del carrito abandonado responde a fricción concreta: dudas sobre envío, sobre devolución, sobre características del producto, sobre pago. Un agente conversacional integrado en WhatsApp, Telegram o el chat de la tienda recupera la conversación con contexto completo del Sylius del cliente: qué intentó añadir, en qué paso se detuvo, qué cliente es, qué pedidos previos tiene.
Arquitectura: webhook desde Sylius al detectar abandono (con ventana configurable), agente que opera vía tools sobre OrderRepository y ShipmentMethodRepository, integración WhatsApp Business API o widget de chat embebido en la tienda. La conversación, cuando termina en éxito, modifica el Order real del cliente: aplica descuento, cambia método de envío, lo cierra.
Las acciones irreversibles — cierre de pedido con descuento, cambio de dirección, modificación de método de pago — pasan siempre por aprobación humana cuando superan el umbral comercial pactado. El log queda en el repositorio del agente, replicable, auditable.
Arquitectura: Sylius API + agente + tools
La arquitectura común a los cuatro casos:
- Sylius como sistema de registro. El estado de la tienda — catálogo, pedidos, clientes, pricing — vive en Sylius. El agente no duplica datos.
- API Platform como contrato. El agente consume REST/GraphQL de Sylius, no escribe SQL directo. Cada operación pasa por un endpoint con validación de schema, permisos y eventos.
- Tools acotadas, no acceso libre. Cada acción del agente se expone como una tool con contrato: parámetros tipados, rangos válidos, ámbito de actuación. El agente puede pedir cualquier cosa; solo se ejecuta lo que pasa el contrato.
- Eventos como punto de entrada. El agente reacciona a eventos del checkout, del carrito y del catálogo. La integración es event-driven, no polling.
- Guardrails y HITL. Operaciones críticas requieren aprobación humana. El log queda completo: prompt, decisión, parámetros, resultado.
- Pipeline de evals. Cada caso de uso tiene un dataset de evaluación con casos reales que se ejecuta tras cada cambio del prompt o del modelo. Métricas operativas (tasa de éxito, coste por decisión, tiempo de respuesta) viven en dashboard.
Stack típico cuando entregamos el sistema: Sylius 2 · Symfony 7 · API Platform · agentes orquestados con un runtime propio sobre Quarkus o Node.js · servidores MCP custom para CRM/ERP del cliente · WhatsApp Business API o chat embebido · PostgreSQL · OpenTelemetry para trazabilidad.
Métricas que importan
Las métricas que vigilamos en estos sistemas son operativas y comparables contra una línea base sin IA:
- Ticket medio: variación porcentual por segmento de cliente y Channel.
- Tasa de conversión del checkout: % de carritos iniciados que terminan en pedido confirmado.
- Margen medio: punto porcentual sobre catálogo afectado por pricing dinámico.
- % de rescate de carrito: conversaciones de abandono que terminan en pedido cerrado.
- Coste por interacción del agente: tokens del modelo, llamadas a APIs externas, tiempo humano si hubo HITL.
- Tiempo de respuesta del agente: p95 por tipo de decisión.
- Calidad de decisiones: muestreo semanal revisado por humanos sobre casos críticos.
Estas métricas se reportan en dashboard al que el responsable de e-commerce y el responsable de tecnología tienen acceso, no en informe mensual.
Cómo lo construimos en producción
El primer entregable de un proyecto Sylius + IA no es código. Es el mapa de casos: qué señales tiene el sistema, qué decisiones aportan retorno medible, qué umbrales operativos definen el HITL, qué tools acotadas necesita el agente. Sobre ese mapa montamos la arquitectura: hooks de Sylius, tools sobre API Platform, agente orquestado, guardrails, panel de métricas.
El repositorio del agente vive junto al repositorio del Sylius del cliente, versionado, con CI/CD y tests sobre los prompts críticos. Las decisiones de pricing, merchandising y promociones que el agente toma quedan registradas como entradas de dominio en Sylius, no como cajas negras en un servicio externo. La trazabilidad es ejecutable desde el primer commit.
Detrás de cada uno de estos sistemas hay un equipo de desarrolladores que cree que la ingeniería seria de IA aplicada a e-commerce empieza por entender el catálogo, el pricing y el cliente — no por enchufar el último modelo al checkout. Sistemas listos para producción, no prototipos.
Si tu Sylius ya está en producción y quieres explorar dónde la IA aporta retorno real sobre catálogo, checkout y pricing, podemos auditar tu tienda y entregarte el plan con los dos o tres casos con mayor retorno para tu modelo de negocio antes de comprometer ningún sprint.
