A Grab construiu um sistema multi-agente de produção para suporte de engenharia em sua plataforma Analytics Data Warehouse, implantado para 1,000+ usuários internos que gerenciam 15,000+ tabelas. A arquitetura: um agente supervisor controla comunicação e delegação de tarefas; agentes especializados lidam com recuperação de contexto, busca de código, e geração de solução. Dois fluxos primários — investigação (análise de consulta, depuração SQL, recuperação de log, busca de esquema) e aprimoramento (correções de código, merge requests automatizados). Construído sobre LangGraph para o motor de fluxo de trabalho e serviços FastAPI para roteamento, execução de ferramentas, e gerenciamento de estado. Ecossistema de ferramentas consolidado de 30+ ferramentas para um conjunto curado: execução SQL controlada, acesso a metadados, recuperação de log, fluxos baseados em Git. Modelos específicos usados não divulgados. Impacto reportado: "centenas de horas de engenharia recuperadas a cada mês" segundo o Head of Analytics, mais uma mudança de combate a incêndios reativo para trabalho de desenvolvimento de plataforma.
As escolhas arquiteturais são a parte que vale a pena estudar. Primeiro, **responsabilidades de agente restringidas** — cada agente especializado tem um escopo estreito para reduzir ambiguidade de raciocínio. É o mesmo instinto que a divisão proposta-execução no artigo de segurança de agentes desta manhã: limite o que o agente pode decidir para que os portões possam verificar o que ele faz. Segundo, **human-in-the-loop em todas as mudanças de código** — nenhum agente escreve para produção sem revisão. Terceiro, **camadas de validação de execução SQL com proteção de dados sensíveis** — o agente não executa SQL arbitrário; executa SQL através de um portão de execução controlada que limpa dados sensíveis e valida antes de executar. Quarto, **compressão de contexto estruturada para raciocínio multi-passo dentro de limites de token** — o problema de contexto longo (15K tabelas significa que buscas de esquema explodem o orçamento de contexto rápido) é resolvido com compressão explícita, não confiando no modelo para descobrir o que é relevante. A redução de 30-ferramentas-para-curado é a lição operacional: a proliferação de ferramentas torna o agente menos confiável, não mais capaz. A curadoria é o trabalho.
Por que importa aos builders. Implantações multi-agente de produção nesta escala (1K usuários, 15K tabelas) com esta concretude (stack LangGraph + FastAPI nomeada, human-in-the-loop nomeado, consolidação de ferramentas nomeada) são raras em relatórios públicos. A maioria dos casos de estudo de agentes publicados são demos ou pilotos. Os específicos da Grab te dizem como grau-produção realmente se parece: a escolha de framework (LangGraph sobre AutoGen, CrewAI, ou personalizado) é um sinal real — as primitivas checkpointing e supervisor-pattern do LangGraph são battle-tested para esse caso de uso. O caso de uso Analytics Data Warehouse também é generalizável: em qualquer lugar onde você tem uma plataforma interna complexa (data warehouse, superfície de API interna, automação de infraestrutura) suportando muitos engenheiros com carga de suporte repetitiva, o padrão Grab aplica — agente supervisor, recuperadores especializados, portões de execução controlada, human-in-loop em escritas.
Segunda-feira: se você está considerando uma implantação multi-agente de suporte-engenharia, o padrão Grab é um template sólido. Pontos de partida concretos. (1) Escolha LangGraph para a camada de orquestração se seu time ainda não tem uma opinião forte — as primitivas supervisor-pattern mapeiam limpamente para as divisões de fluxo investigação/aprimoramento. (2) Audite sua superfície de ferramentas internas existente; a redução de 30-para-curado na Grab é a lição — ferramentas demais pioram o agente. Comece nomeando as 5 a 10 ferramentas que cobrem 80% da carga de suporte e construa a partir daí. (3) Configure o portão de execução controlada antes de deixar o agente escrever qualquer coisa para produção. A validação de execução SQL + limpeza de dados sensíveis é o padrão específico que a Grab usa; o padrão geral é execução verificada por política que é não-bypaseável. (4) Planeje human-in-the-loop em todas as mudanças de código desde o dia um — fazer retrofit depois é muito mais difícil que construir desde o início. (5) Meça "horas de engenharia recuperadas" como sua métrica primária, não "tickets resolvidos" ou precisão do modelo — o caso de negócio para o agente é tempo de engenheiro recuperado, e isso é o que o Head of Analytics citou na Grab. A métrica de eval deveria corresponder à métrica de negócio.