Grab construyó un sistema multi-agente de producción para soporte de ingeniería en su plataforma Analytics Data Warehouse, desplegado a 1,000+ usuarios internos que manejan 15,000+ tablas. La arquitectura: un agente supervisor controla la comunicación y la delegación de tareas; agentes especializados manejan recuperación de contexto, búsqueda de código, y generación de solución. Dos flujos primarios — investigación (análisis de consulta, depuración SQL, recuperación de log, búsqueda de esquema) y mejora (correcciones de código, merge requests automatizados). Construido sobre LangGraph para el motor de flujo de trabajo y servicios FastAPI para enrutamiento, ejecución de herramientas, y gestión de estado. Ecosistema de herramientas consolidado de 30+ herramientas a un conjunto curado: ejecución SQL controlada, acceso a metadatos, recuperación de log, flujos basados en Git. Modelos específicos usados no divulgados. Impacto reportado: "cientos de horas de ingeniería recuperadas cada mes" según el Head of Analytics, más un cambio de extinción de incendios reactiva a trabajo de desarrollo de plataforma.
Las elecciones arquitectónicas son la parte que vale la pena estudiar. Primero, **responsabilidades de agente restringidas** — cada agente especializado tiene un alcance estrecho para reducir ambigüedad de razonamiento. Es el mismo instinto que la división propuesta-ejecución en el artículo de seguridad de agentes de esta mañana: limita lo que el agente puede decidir para que las compuertas puedan verificar lo que hace. Segundo, **human-in-the-loop en todos los cambios de código** — ningún agente escribe a producción sin revisión. Tercero, **capas de validación de ejecución SQL con protección de datos sensibles** — el agente no ejecuta SQL arbitrario; ejecuta SQL a través de una compuerta de ejecución controlada que limpia datos sensibles y valida antes de ejecutar. Cuarto, **compresión de contexto estructurada para razonamiento multi-paso dentro de límites de token** — el problema de contexto largo (15K tablas significa que las búsquedas de esquema explotan el presupuesto de contexto rápido) se resuelve con compresión explícita, no confiando en que el modelo averigüe qué es relevante. La reducción de 30-herramientas-a-curado es la lección operacional: la proliferación de herramientas hace al agente menos confiable, no más capaz. La curación es el trabajo.
Por qué importa a los builders. Despliegues multi-agente de producción a esta escala (1K usuarios, 15K tablas) con esta concreción (stack LangGraph + FastAPI nombrado, human-in-the-loop nombrado, consolidación de herramientas nombrada) son raros en reportes públicos. La mayoría de casos de estudio de agentes publicados son demos o pilotos. Los detalles de Grab te dicen cómo se ve grado-producción realmente: la elección de framework (LangGraph sobre AutoGen, CrewAI, o personalizado) es una señal real — las primitivas checkpointing y supervisor-pattern de LangGraph están probadas en batalla para este caso de uso. El caso de uso Analytics Data Warehouse también es generalizable: en cualquier lugar donde tienes una plataforma interna compleja (data warehouse, superficie de API interna, automatización de infraestructura) soportando muchos ingenieros con carga de soporte repetitiva, el patrón Grab aplica — agente supervisor, recuperadores especializados, compuertas de ejecución controlada, human-in-loop en escrituras.
Lunes: si estás considerando un despliegue multi-agente de soporte-ingeniería, el patrón Grab es una plantilla sólida. Puntos de partida concretos. (1) Elige LangGraph para la capa de orquestación si tu equipo aún no tiene una opinión fuerte — las primitivas supervisor-pattern mapean limpiamente a las divisiones de flujo investigación/mejora. (2) Audita tu superficie de herramientas internas existente; la reducción de 30-a-curado en Grab es la lección — demasiadas herramientas empeoran al agente. Comienza nombrando las 5 a 10 herramientas que cubren 80% de la carga de soporte y construye desde ahí. (3) Configura la compuerta de ejecución controlada antes de dejar que el agente escriba algo a producción. La validación de ejecución SQL + limpieza de datos sensibles es el patrón específico que Grab usa; el patrón general es ejecución verificada por política que es no-bypaseable. (4) Planea human-in-the-loop en todos los cambios de código desde el día uno — retrofitearlo después es mucho más difícil que construirlo. (5) Mide "horas de ingeniería recuperadas" como tu métrica primaria, no "tickets resueltos" o precisión del modelo — el caso de negocio para el agente es tiempo de ingeniero recuperado, y eso es lo que citó el Head of Analytics en Grab. La métrica de eval debería coincidir con la métrica de negocio.