Como a Grab usou agentes de IA para automatizar suporte de engenharia no data warehouse — e o que dá para copiar

Resumo: Um relato técnico publicado pelo InfoQ em maio/junho de 2026 detalha como o time central de dados da Grab (super-app líder no sudeste asiático) construiu um sistema multi-agente para automatizar tarefas repetitivas de suporte de engenharia sobre o seu data warehouse. A arquitetura separa agentes de investigação de agentes de melhoria, coordena tudo via camada de orquestração, e entrega resultados auditáveis. É um dos primeiros estudos de caso públicos e bem documentados sobre multi-agentes em engenharia de dados — e tem lições reaproveitáveis para qualquer time de dados no Brasil.

O problema da Grab

A Grab opera petabytes de dados gerados por motoristas, restaurantes parceiros, entregadores e usuários. Como em qualquer organização desse porte, parte significativa do tempo do time de engenharia de dados era consumida por pedidos de suporte: “essa query está lenta”, “essa tabela mudou de schema”, “esse job falhou e não sei por quê”, “preciso de uma view nova”. Essas demandas vinham por Slack, Jira, e tiquetes diversos — e a velocidade média de resolução não escalava com o aumento de produtos analíticos.

A arquitetura: investigação vs melhoria

O time desenhou dois fluxos paralelos.

Agentes de Investigação

Cuidam de tarefas diagnósticas: análise de consultas, leitura de logs do warehouse (Spark, Presto/Trino), busca de schemas, identificação de quem é dono da tabela, geração de resumo do problema. O agente tem ferramentas que lêem catálogos (DataHub), histórico de execuções e métricas de uso. O output típico é um diagnóstico textual com referências aos artefatos relevantes — não muda dado, não escreve em produção.

Agentes de Melhoria

Cuidam de geração de outputs acionáveis: ajustes de SQL, propostas de novas views, fixes em pipelines, pull requests para o repositório de Airflow/dbt. Cada saída passa por revisão humana — o agente abre um MR, mas humano aprova merge. Há uma fronteira clara entre “ler e propor” e “executar”.

Camada de Orquestração

Existe um coordenador que recebe a demanda, escolhe se ela cabe num fluxo de investigação, melhoria ou ambos, atribui ao agente certo e mantém o contexto. Esse coordenador também aplica políticas: o que é permitido propor automaticamente, o que exige aprovação, qual escalonamento usar quando o agente fica em dúvida.

O que dá para copiar

Para times brasileiros de dados (varejo, fintech, telecom, saúde) o caso da Grab é prático porque mostra três decisões reaproveitáveis:

• Separar leitura de escrita. Agentes que só leem e diagnosticam têm risco baixo e ganho enorme — é o melhor primeiro projeto.
• Sempre passar por MR. Toda mudança em pipeline/SQL produtivo vira PR/MR aprovado por humano. O agente não escreve direto em produção.
• Catálogo bem mantido é pré-requisito. Sem DataHub, OpenMetadata, Amundsen, Unity Catalog ou similar atualizado, o agente cega. Vale investir antes de partir para multi-agente.

Status no Brasil

Times de plataforma de dados em Itaú, Nubank, iFood, Magalu, Mercado Livre, Vivo e B3 já testam padrões semelhantes — agente “explica essa query” no Slack, agente “abre PR de schema”, agente “rastreia este job lento”. A maioria, hoje, opera no estágio “investigação” — diagnóstico apenas. Os mais avançados começam a propor PRs no dbt para revisão. O salto seguinte, na linha do que a Grab fez, é separar formalmente os papéis e ter um orquestrador. Vale lembrar que LGPD e auditoria interna pedem trilha completa para qualquer mudança que toque dado pessoal — o desenho da Grab, com humano no merge, encaixa direto nessa exigência.

Riscos e limitações

O case da Grab admite limites explícitos. Agentes de investigação às vezes fabricam relação de causalidade onde só há correlação — quem aceita o diagnóstico sem leitura crítica decide errado. Agentes de melhoria propõem SQL plausível, mas nem sempre semanticamente correto, por isso o gate humano é inegociável. E há um custo escondido importante: catálogo desatualizado é veneno — quanto mais lixo no metadata, mais o agente alucina sobre dono, finalidade e dependências.

Cenário e indicativo de futuro

O movimento da Grab é parte de uma onda maior: “engenharia de dados assistida por agentes”. A consequência mais provável é que em 12 a 18 meses tenhamos:

• Times de plataforma com indicadores específicos de “produtividade aumentada por agente” — tempo médio de resolução, tickets fechados por agente, retrabalho.
• Catálogos de metadados (DataHub, OpenMetadata, Unity Catalog) virando produtos centrais — porque ali roda toda decisão dos agentes.
• Padrões abertos de “Agent SDK para dados” (LangGraph, OpenAI Swarm, Anthropic MCP) ganhando tração, com módulos prontos para Spark, dbt, Airflow.
• Discussão regulatória entrando: até onde é razoável um agente modificar pipeline em ambiente regulado (saúde, financeiro)?

Conclusão prática

Se você lidera plataforma de dados, três passos cabem nos próximos noventa dias. Um, mapeie os cinco tipos de pedido de suporte mais comuns no seu time — provavelmente, três deles encaixam num “agente de investigação” de risco baixo. Dois, garanta catálogo (DataHub/OpenMetadata) atualizado e com dono claro por tabela. Três, comece pelo modo “leitura” e só evolua para “melhoria” depois de medir taxa de acerto e nível de confiança do time. O caso da Grab é uma referência sólida — e está bem documentado pelo InfoQ.

Fonte original: InfoQ — Designing a Multi-Agent System for Engineering Support at Scale: a Case Study from Grab.