Integrei Agentes de IA em Nossos Pipelines de Dados. Aqui Está o Que de Fato Funcionou.

Nos últimos dois anos, integrei agentes baseados em LLM aos fluxos de engenharia de dados de uma grande plataforma de dados B2B — não como ferramenta paralela, mas como parte central de como construíamos, mantínhamos e operávamos pipelines processando terabytes diariamente.

Construí cinco agentes: scaffolding de pipeline, code review, resposta a incidentes, geração de documentação e geração de código. Conectei todos via MCP (Model Context Protocol) para que pudessem acessar nossa infraestrutura viva — esquemas, definições de DAGs, históricos de execução, convenções do time.

Eles eram úteis. Alguns foram genuinamente transformadores. Mas cada um bateu no mesmo teto, e levei meses para entender qual era esse teto.

Este é o relato honesto — o que funcionou, onde estava o teto, e o que eu faria primeiro em qualquer novo engajamento hoje.

A base: MCP mudou como os agentes enxergam infraestrutura

A maior alavanca na primeira fase foi o MCP. Antes dele, usar um LLM para nossa base de código específica significava despejar milhares de linhas em um prompt ou aceitar conselhos genéricos. O MCP me permitiu construir servidores de contexto estruturado que davam aos agentes exatamente o que eles precisavam:

Metadados de pipeline — definições de DAGs, configurações de agendamento, grafos de dependência, históricos recentes de execução
Informações de esquema — esquemas de tabelas do warehouse, tipos de colunas, metadados de frescor, lineage
Definições de modelos — SQL de transformação, documentação, definições de testes, dependências upstream/downstream
Convenções do time — padrões de nomenclatura, estratégias de particionamento, requisitos de testes, checklists de PR

Com esse contexto, os agentes passaram de "aqui está um Python genérico" para "o modelo upstream atualiza às 06:00 UTC, então sua dependência deve esperar até 06:30 para acomodar o buffer de SLA de 15 minutos que usamos". Especificidade mudou tudo.

Cinco agentes, resultados reais

Sobre o MCP, construí cinco agentes, cada um integrado a uma etapa existente do nosso fluxo de engenharia:

Cada agente produziu resultados reais:

Scaffolder de pipeline — reduziu o setup de novos pipelines de 45-60 minutos para 15 minutos. Nomenclatura consistente, particionamento correto, testes pré-populados.
Assistente de code review — capturou questões mecânicas (checagens de null ausentes, riscos de skew de partição, schema drift) antes da revisão humana, liberando engenheiros sêniores para feedback arquitetural.
Resposta a incidentes — montava briefings de contexto em segundos em vez de 15-20 minutos de reconstrução manual às 3 da manhã. O agente de maior impacto na qualidade de vida do plantão.
Gerador de documentação — mantinha o "o quê" em sincronia com mudanças de código automaticamente. Humanos escreviam o "porquê".

MCP tornou tudo isso possível. Sem ele, os agentes davam conselhos genéricos. Com ele, davam respostas fundamentadas na nossa infraestrutura específica.

Mas aí cada agente bateu na mesma parede.

O teto: os agentes enxergavam o sistema, mas não conseguiam lembrar da organização

O MCP dava aos agentes acesso a como nosso sistema era naquele momento — esquemas vivos, definições atuais de DAG, históricos recentes de execução. Isso é dado de infraestrutura. É tempo real e é preciso.

Mas existe uma categoria inteira de conhecimento que não vive na infraestrutura:

Por que este pipeline foi desenhado dessa forma? Que restrições moldaram a decisão?
Nas últimas três vezes em que tentamos migrar este serviço, o que deu errado?
Este padrão de falha recorre a cada fim de trimestre por causa de picos sazonais de carga — mas isso não está em lugar algum na definição do DAG
O time decidiu há seis meses padronizar uma abordagem específica — mas isso está em uma thread do Slack, não no código
O engenheiro sênior que construiu este sistema está de licença e ninguém mais entende completamente o mecanismo de rotação de tokens

Isto é conhecimento institucional — a sabedoria acumulada do time, espalhada pela cabeça das pessoas, threads antigas do Slack, postmortems e design docs que ninguém mantém. MCP não consegue ver nada disso. E todo agente que construí estava limitado pela sua ausência.

O agente de resposta a incidentes conseguia puxar históricos de execução e status de upstream — mas não sabia que esse padrão exato de falha aconteceu no trimestre passado e que a causa raiz foi uma mudança de esquema upstream, não o pipeline em si. O agente de code review pegava checagens de null ausentes — mas não conseguia sinalizar que a abordagem proposta contradizia uma decisão de arquitetura que o time tomou seis meses atrás. O scaffolder gerava pipelines corretos — mas não conseguia levar em conta uma depreciação que existia só em um documento de planejamento do time.

Cada agente era tecnicamente correto e arquiteturalmente ingênuo. Conseguiam ver o sistema. Não conseguiam lembrar da organização.

A virada: uma base de conhecimento como memória do agente

Depois de deixar aquele engajamento, construí o que gostaria de ter tido desde o início: uma base de conhecimento estruturada e mantida por LLM que captura o conhecimento institucional que o MCP não consegue ver.

O conceito se apoia no padrão LLM Wiki do Andrej Karpathy: em vez de fazer os agentes rederivarem entendimento toda vez (a abordagem RAG), o LLM constrói e mantém incrementalmente um wiki persistente. Você alimenta com documentos-fonte — architecture decision records, postmortems, design docs, notas de reunião — e ele cria páginas wiki cruzadas com pontuação de confiança, detecção de contradições e gerenciamento de ciclo de vida.

O conhecimento se acumula ao longo do tempo. Cada fonte ingerida torna toda interação futura de agente mais inteligente, porque a síntese já está feita e mantida.

Disponibilizei isso como um template reutilizável open source: knowledge-base-template.

Quando você combina MCP (infraestrutura viva) com a base de conhecimento (memória institucional), os agentes ganham o quadro completo de contexto:

Isso não é teórico. Veja como cada agente fica com a base de conhecimento:

Resposta a incidentes — não só mostra históricos de execução. Sabe que este pipeline tem um pico sazonal de carga de fim de trimestre, que da última vez que falhou dessa forma a causa raiz foi uma mudança de esquema upstream, e que a remediação preferida do time é aumentar a contagem de partições em vez do tamanho do cluster.
Code review — não só pega checagens de null. Sinaliza que a abordagem proposta contradiz o ADR-047 (a decisão do time de evitar joins cross-service), cita a decisão de arquitetura e sugere uma alternativa que se alinha.
Scaffolder — não só segue convenções de nomenclatura. Sabe que o Serviço X está sendo depreciado no próximo trimestre, então roteia o novo pipeline pelo Serviço Y. Esse plano de depreciação está na base de conhecimento, não em nenhum arquivo de config.
Documentação — não só descreve o que um pipeline faz. Aponta para a decisão de negócio que o criou, o incidente que moldou seu tratamento de erros e o design doc que explica sua estratégia incomum de particionamento.

Mesmos agentes. Mesmo MCP. Mas com a base de conhecimento, eles produzem trabalho que reflete um ano de contexto institucional em vez de uma leitura fria da base de código.

Se eu estivesse começando hoje: base de conhecimento primeiro

Este é o insight-chave, e ele inverte a ordem que segui: comece pela base de conhecimento, depois construa os agentes em cima dela.

Esta é a sequência que eu seguiria em qualquer novo engajamento:

Semanas 1-2: Construa a base de conhecimento. Ingira os documentos que guardam o conhecimento institucional — ADRs, postmortems, design docs, guias de onboarding. Use o template para montar a arquitetura de três camadas (fontes brutas, wiki mantido por LLM, esquema). Três bons ADRs no wiki vão melhorar a saída dos agentes mais do que cinquenta arquivos de código brutos.
Semanas 2-3: Configure o MCP. Conecte os agentes à infraestrutura viva — esquemas, metadados do orquestrador, históricos de execução. Esta é a camada dos "olhos".
Semanas 3-4: Construa o primeiro agente (resposta a incidentes). É o de maior razão impacto-por-esforço e o de adesão mais rápida do time. Com a base de conhecimento já no lugar, ele é imediatamente útil — não só montando contexto, mas entendendo-o.
Semana 4+: Adicione agentes incrementalmente. Code review, scaffolding, documentação. Cada um se beneficia da base de conhecimento que vem se acumulando desde a semana 1.

A diferença-chave: quando comecei em 2024, construí os agentes primeiro e gostaria de ter tido uma base de conhecimento. Se você começa pela base de conhecimento, cada agente que construir depois é imediatamente melhor — porque a memória institucional já está lá, acumulando desde o primeiro dia.

Os princípios que se sustentaram

Ao longo de dois anos e cinco agentes, três princípios separaram consistentemente o que foi entregue do que foi abandonado:

A conclusão

Agentes de IA em engenharia de dados estão prontos para produção. Mas seu valor é determinado inteiramente pela infraestrutura de contexto por baixo.

MCP dá aos agentes olhos sobre sua infraestrutura viva — o o quê. Uma base de conhecimento dá memória sobre sua organização — o porquê. Juntos, são a camada de contexto completa que transforma IA genérica na IA do seu time.

Se eu estivesse começando um novo engajamento de integração de IA hoje, começaria pela base de conhecimento. Não pelos agentes. Não pelos servidores MCP. A base de conhecimento — porque ela se acumula desde o primeiro dia, e cada agente que você construir em cima dela será imediatamente melhor por isso.

Os times que vão vencer com agentes de IA não são os com os melhores modelos. São os que constroem a infraestrutura de memória para fazer esses modelos realmente entenderem seu sistema.

Escrevi em profundidade sobre a estratégia de base de conhecimento: A Estratégia de Base de Conhecimento: Dando aos Agentes de IA uma Memória Que Se Acumula. E disponibilizei o template open source: knowledge-base-template.