O time Central Data da Grab montou um sistema multi-agente pra automatizar suporte interno no Analytics Data Warehouse. O numero que justifica a operacao: mais de 1.000 usuarios trabalhando com mais de 15 mil tabelas. O resultado: centenas de horas de engenharia liberadas por mes, deslocando o time de firefighting pra trabalho de plataforma.

O problema que justifica multi-agente

Time de plataforma de dados em empresa do tamanho da Grab convive com o mesmo problema todo dia: dev de produto chega no canal de suporte com pergunta sobre por que um job esta lento, qual o owner de uma tabela, como otimizar uma query, ou se uma coluna sumiu por mudanca de schema. Cada pergunta exige investigacao, troca de mensagens e tempo do time core.

Quando 1.000 usuarios fazem isso em paralelo, o time core vira call center. O custo de oportunidade e enorme — engenheiros senior gastam dia inteiro respondendo o que ja deveria estar em runbook ou ja foi respondido tres vezes.

A arquitetura: investigacao e melhoria separadas

A Grab desenhou o sistema separando dois workflows distintos com agentes especializados pra cada um. Investigacao cuida de pergunta diagnostica (“por que essa query e lenta?”, “essa tabela existe?”). Melhoria cuida de pedido de mudanca (“otimiza essa pipeline”, “adiciona essa coluna”).

Uma camada de orquestracao decide pra qual agente cada pedido vai. Pedido simples e respondido autonomamente pelo agente. Pedido complexo dispara colaboracao entre agentes — investigacao primeiro, depois melhoria com o contexto coletado.

O design e relevante porque rejeita a tentacao de fazer agente unico monolitico. A divisao por tipo de tarefa permite especializacao real do prompt, das ferramentas que cada agente acessa e dos guardrails sobre o que cada um pode fazer.

O ganho concreto

A Grab afirma reducao significativa de carga operacional, melhoria de tempo de resolucao e centenas de horas de engenharia liberadas por mes. O numero exato nao apareceu na nota, mas a Grab caracteriza o ganho como “deslocar engenheiros de firefighting pra trabalho de plataforma”.

A cultura de medir esse tipo de ganho como “horas liberadas” vale destacar. Em vez de medir agente por taxa de acerto ou por NPS de usuario, a Grab mede pela capacidade que os engenheiros recuperam pra fazer trabalho de maior valor. Esse e o ROI que justifica investimento continuado.

A licao replicavel

Pra times de plataforma de dados em outras orgs, o caso da Grab da tres pontos pra copiar:

• Comecar por suporte interno. O problema esta mapeado, os custos sao visiveis e o time consegue avaliar qualidade do agente sem expor cliente externo.
• Separar tipos de tarefa. Um agente “genio” que faz tudo perde precisao. Agente especializado por tipo de pedido (investigar vs alterar) ganha pelos dois lados.
• Medir em horas liberadas. Metrica de uso (“quantas perguntas o agente respondeu”) inflar facil. Metrica de tempo recuperado e o que importa pro CFO.

O que a Grab ainda nao detalhou

A nota nao especifica que LLM esta no backend do sistema, quanto custa a operacao por mes nem como o time monitora deriva de qualidade ao longo do tempo. Tambem nao detalha protocolo de escalation — quando o agente acerta que precisa entregar pra humano e como esse handoff acontece.

Quem quer replicar precisa preencher esses pontos com decisao propria.

Como avaliar isso na pratica

A Grab mostra que multi-agente em suporte interno tem ROI mensuravel quando o escopo e claro. Pra time que ainda nao tem agente em producao, o passo viavel e identificar a fila de pergunta mais repetitiva (suporte de plataforma, troubleshoot de pipeline, lookup de catalogo) e desenhar um agente por categoria. O segundo agente entra so depois do primeiro provar valor mensuravel.

Reportado originalmente por InfoQ em 2026-05-25.