Arquitectura multiagente de IA: las lecciones de Spotify tras generar 20.000 anuncios para 7.000 anunciantes

Más del 70% de los anuncios de Spotify Ads Manager ya usan herramientas de IA, y la plataforma ha generado unas 20.000 creatividades para más de 7.000 anunciantes. Son campañas reales, con dinero y audiencias reales. Detrás hay una arquitectura multiagente de IA que Pratik Rasam, ingeniero senior de Spotify, detalló en QCon AI. Su advertencia es lo más valioso de la charla: no se trata de un experimento de laboratorio, y la plataforma se construyó cometiendo errores que conviene no repetir.

El punto de partida fue un problema estructural, no una moda. Según el blog de ingeniería de Spotify, el negocio publicitario vende por tres canales (Direct, Self-Serve y Programmatic) sobre un backend casi unificado. Aun así, cada canal arrastraba sus propios flujos y heurísticas, y decisiones como asignar presupuesto o priorizar inventario se reimplementaban en Ads Manager, Salesforce y Slack. Con el tiempo derivaban en comportamientos distintos. Un único agente monolítico que intentó cubrir todo (audiencias, guiones, objetivos, presupuesto) dio resultados lentos, inconsistentes y difíciles de depurar. La solución fue dividir el trabajo: el anunciante describe en lenguaje natural lo que quiere, un LLM extrae la intención (por ejemplo, audiencia tecnológica, geografía EE. UU., objetivo de awareness) y una capa de orquestación sobre Google ADK para Java y Vertex AI lanza agentes especializados. Hay un agente de guiones, uno de guardrails de políticas y otro de recomendación de audiencias, aún en piloto. Sus salidas se combinan en dos objetos: la audiencia recomendada y la creatividad final.

Agentes de IA en producción: una regla de propiedad que se aplica al compilar

La regla más llamativa es «un agente, un paquete, un responsable». Cada agente vive en su propio paquete Bazel con su equipo propietario, su revisión de PRs, su archivo de monitoreo (dashboards y alertas de PagerDuty) y su configuración de prompt y modelo. Las métricas y alertas existen antes de escribir la primera instrucción. Además, la visibilidad entre agentes se impone en compilación: si el agente de guiones quiere usar el resolvedor de audiencias y este no lo autoriza, el build falla. Seguridad y orquestación viven en una capa común, no dentro de cada agente.

Otra pieza clave es el reparto de responsabilidades. Según el resumen de la charla en QCon Boston, los agentes razonan (traducir un brief a objetivos, interpretar audiencias), las herramientas acceden a datos (geografías, categorías, rendimiento histórico) y el código de aplicación ejecuta lo determinista (puntuar recomendaciones, repartir presupuestos, validar restricciones). Spotify trata el diseño de herramientas como ingeniería de prompts: la misma API de anuncios se expone con esquemas distintos según el agente, y los mensajes de error estructurados permiten que el modelo se recupere solo. Anclar al LLM en datos reales de la API es, según el equipo, lo que ataca la alucinación en origen.

Cómo aplicar una arquitectura multiagente de IA en tu empresa

La lección de fondo es que los agentes no sustituyen a tus sistemas, sino que añaden la capa de intención que les faltaba. Spotify evitó dos extremos: más flujos rígidos por canal y un gigantesco motor de reglas. Para replicarlo:

Detecta dónde se duplica la lógica de decisión. Si la misma regla vive en tres superficies, ahí hay un candidato a agente compartido.

Traza fronteras antes de escribir prompts. Pregunta qué requiere razonamiento, qué es acceso a datos y qué debe ser código determinista. No todo debe ser un agente.

Asigna dueño desde el día uno. Un agente sin responsable, dashboard ni alerta es una deuda técnica anunciada.

Diseña las herramientas con el mismo cuidado que los prompts. Descripciones claras de esquemas y errores explicativos reducen reintentos y alucinaciones. Si te preocupa ese riesgo, mira cómo un retailer redujo las alucinaciones del 15% al 1,5% sin cambiar de modelo.

Pon guardrails deterministas y moderación fuera de los agentes. Así la política es común y no depende del criterio de cada equipo. Un enfoque complementario es el de AWS y Cisco para automatizar la seguridad de agentes empresariales.

Evaluación de agentes de IA: pruebas ligadas a trazas de producción

El testing tradicional falla con sistemas probabilísticos, y Spotify lo resolvió integrando la evaluación en el pipeline de trazabilidad. Cada ejecución en producción puede reproducirse, inspeccionarse y puntuarse en tres niveles: trayectoria de herramientas (¿llamó a las correctas y en orden?), aserciones deterministas sobre campos críticos y LLM-as-judge para la calidad semántica. Los checks deterministas bloquean la integración continua; el juez corre en experimentos nocturnos para seguir la calidad en el tiempo. Así detectan regresiones por cambios de prompt, modelo o herramienta antes de que lleguen al anunciante. Quien quiera ver cómo escala esto en otra organización puede leer cómo Elastic unificó la evaluación de agentes tras casi dos años en producción.

El equipo también menciona el control de costos y los errores al trazar las fronteras entre agentes, aunque en el material disponible no publica cifras de gasto. Si tu empresa está pensando en escalar, conviene medir desde el principio cuánto cuesta cada ejecución y cada herramienta.

El momento de decidir

La arquitectura multiagente de IA de Spotify muestra que el valor no está en un modelo más potente, sino en la disciplina de ingeniería: propiedad clara, herramientas bien diseñadas, reglas deterministas donde importan y evaluación continua. Antes de lanzar tu próximo agente, ¿sabes quién es su dueño, qué parte del flujo debe seguir siendo código y cómo vas a saber si empeoró tras el próximo cambio de modelo?