Por Qué Ganó la Arquitectura Agentic
¡Hola Devs! La mayoría de los equipos de ingeniería enfrentan una tensión familiar: consolidaste tus servicios de backend, pero la capa de workflow sigue fragmentada. Cada canal de compra — Directo, Self-Serve, Programático — corre sobre infraestructura compartida, pero la lógica de decisión diverge. Asignación de presupuesto, selección de inventario y tradeoffs de rendimiento se reimplementan por canal y por superficie. Con el tiempo, se desvían.
El equipo de Ads AI de Spotify confrontó exactamente este problema. En lugar de construir otro servicio REST con caminos felices hardcodeados, apostaron por un enfoque agentic: una capa de decisión unificada y programable que puede entender objetivos, razonar sobre señales compartidas y orquestar APIs de anuncios existentes de manera consistente en todos los canales y superficies.
El insight clave: los workflows son combinatorios. No puedes capturar planificación, pronóstico, selección de audiencia y optimización en un árbol de decisión estático. Necesitas agentes que puedan razonar, adaptarse y usar herramientas.
Fuente: Spotify Engineering Blog
El Blueprint Multi-Agente
Spotify descompuso el workflow de planificación de medios en agentes especializados, cada uno con una responsabilidad enfocada y un prompt optimizado. La arquitectura usa el Google Agent Development Kit (ADK) 0.2.0 para orquestación y Vertex AI (Gemini 2.5 Pro) para comprensión de lenguaje natural.
Desglose de Agentes
-
RouterAgent — El controlador de tráfico. Analiza mensajes entrantes y determina qué información está presente, evitando llamadas LLM innecesarias.
-
Agentes de Resolución — Cada uno maneja una dimensión distinta:
- GoalResolverAgent: Mapea la intención del usuario a objetivos de campaña (ALCANCE, CLICS, INSTALACIONES) y busca categorías de anuncio apropiadas
- AudienceResolverAgent: Extrae criterios de segmentación de una taxonomía predefinida — intereses, geografía, rango de edad, género
- BudgetAgent: Interpreta varios formatos de presupuesto ($5000, 5k, €10,000) y convierte a micro-unidades
- ScheduleAgent: Maneja el parseo de fechas, incluyendo fechas relativas como "el próximo mes"
-
MediaPlannerAgent — El optimizador. Toma toda la información resuelta y genera recomendaciones optimizadas de conjuntos de anuncios usando un motor heurístico basado en datos históricos de rendimiento.
Reglas Clave de Optimización
- Minimizar métricas de costo (CPM, CPC, CPI) en relación a las medianas históricas
- Apuntar a campañas con tasas de entrega cercanas al 100%
- Encontrar campañas históricamente exitosas con rangos de presupuesto similares
- Puntuar basado en superposición demográfica y de intereses
- Asegurar diversidad en combinaciones de formato/objetivo
- Escalar recomendaciones por presupuesto: €0-1,000 → 1 recomendación; €15,000+ → 4-5 recomendaciones
Ejecución Paralela en Acción
# Flujo de orquestación simplificado usando Google ADK
from google.adk import Agent, FunctionTool
router = Agent(
name="RouterAgent",
model="gemini-2.5-pro",
tools=[
FunctionTool.from_func(extract_goal),
FunctionTool.from_func(extract_audience),
FunctionTool.from_func(extract_budget),
FunctionTool.from_func(extract_schedule)
],
instruction="""
Analiza el mensaje del usuario y determina qué agentes de resolución invocar.
Devuelve un plan estructurado solo con la información faltante.
"""
)
# Cada agente de resolución corre en paralelo
resolved_data = await asyncio.gather(
goal_resolver.resolve(user_message),
audience_resolver.resolve(user_message),
budget_resolver.resolve(user_message),
schedule_resolver.resolve(user_message)
)
# El MediaPlannerAgent usa todos los datos resueltos para generar recomendaciones
plan = await media_planner.generate(resolved_data)
Impacto en el Rendimiento: La creación de planes de medios pasó de 15-30 minutos a 5-10 segundos. Las entradas requeridas del usuario pasaron de 20+ campos de formulario a 1-3 mensajes en lenguaje natural. La latencia de respuesta del agente es de ~3-5s con ejecución paralela.
Integración de Herramientas vía Function Calling
Spotify usa el FunctionTool de Google ADK para dar a los agentes acceso a datos reales. Las anotaciones @Schema proporcionan al LLM información estructurada sobre los parámetros de las herramientas, anclando las salidas en la realidad y previniendo alucinaciones.
Trade-offs y Lecciones Aprendidas
Decisiones de Diseño
| Decisión | Enfoque Elegido | Justificación |
|---|---|---|
| Agente único vs. multi-agente | Multi-agente | Mejor latencia, mantenibilidad y paralelización |
| Estrategia de caché | Caché en memoria para datos históricos | Minimiza latencia; datos de rendimiento son acotados y refrescados periódicamente |
| Modo de respuesta | Síncrono | Implementación inicial más simple; streaming planeado para el futuro |
Principales Aprendizajes
1. Prompt engineering es ingeniería de software Trata los prompts como código — control de versiones, pruebas, iteración. Pequeños cambios en las palabras afectan drásticamente la consistencia de la salida. Sé explícito sobre el formato, proporciona ejemplos concretos y construye guardrails tanto en la capa de prompt como en la de parseo.
2. Los límites de los agentes importan Demasiados agentes aumentan la latencia y la sobrecarga de coordinación. Muy pocos crean prompts monolíticos y difíciles de mantener. Regla de oro: un agente por habilidad o fuente de datos distinta.
3. Las herramientas permiten anclaje Los LLMs alucinan. Al proporcionar a los agentes herramientas que acceden a datos reales (objetivos geográficos, categorías de anuncios, rendimiento histórico), anclas las salidas en la realidad. El LLM razona sobre qué hacer; las herramientas proporcionan datos precisos.
Limitaciones y Precauciones
- El riesgo de alucinación permanece: Incluso con salidas ancladas en herramientas, el LLM puede malinterpretar los resultados o inventar pasos de razonamiento intermedios. El monitoreo continuo y los guardrails son esenciales.
- Sobrecarga de coordinación de agentes: Aunque la ejecución paralela ayuda, la propia capa de orquestación introduce latencia y complejidad. Para workflows más simples, un enfoque de agente único puede ser más pragmático.
- Problema de cold start: El motor heurístico depende de datos históricos. Para campañas nuevas u objetivos de nicho con datos dispersos, las recomendaciones pueden ser menos confiables.
- Carga de mantenimiento de prompts: A medida que el sistema evoluciona, los prompts de cada agente necesitan refinamiento continuo. La deriva de prompts puede degradar silenciosamente el rendimiento.
Próximos Pasos
El roadmap de Spotify incluye:
- Respuestas en streaming vía server-sent events para retroalimentación en tiempo real
- Refinamiento multi-turn para optimización iterativa de campañas
- Integración de A/B testing para probar automáticamente planes recomendados por IA contra líneas base
- Modelos fine-tuned para terminología de publicidad específica del dominio
Para equipos considerando un camino similar: comienza pequeño. Elige un workflow acotado donde la fragmentación duela más, construye un prototipo multi-agente mínimo y mide el trade-off entre latencia y calidad antes de escalar.
Conclusión: El Futuro de la Automatización de Workflows
El Ads AI de Spotify demuestra que los workflows complejos y de múltiples pasos son adecuados para arquitecturas multi-agente. Al descomponer la planificación de medios en agentes especializados — cada uno con prompts enfocados, herramientas relevantes y responsabilidades claras — crearon un sistema que es a la vez poderoso y mantenible.
La combinación de Google ADK para orquestación, Vertex AI para capacidades de LLM y datos históricos de rendimiento crea un sistema que no solo entiende lo que los anunciantes quieren — sabe lo que realmente funciona.
La lección: En lugar de hardcodear más workflows determinísticos por canal, trata tu dominio como un conjunto de agentes modulares que consumen señales compartidas, optimizan conjuntamente para objetivos del usuario y restricciones de negocio, y usan APIs existentes como herramientas. Así es como centralizas la toma de decisiones una vez y la proyectas en todas partes.
Lectura Recomendada
- Pandas loc vs iloc: La Guía Definitiva para Indexación de DataFrames — Entiende los fundamentos de la indexación de datos, una habilidad esencial para cualquier sistema de agente intensivo en datos.
- Data Commons MCP Ahora Alojado en Google Cloud: Consulta Datos Públicos con IA, Sin Configuración — Explora cómo usar datasets públicos para enriquecer el conocimiento del agente sin sobrecarga de infraestructura.