Por que Open-Sourcamos 14 Agentes Autônomos de Engenharia de Dados

Hoje lançamos a edição comunitária do Data Workers: 14 agentes autônomos para engenharia de dados, open-source sob a licença Apache 2.0. Este post explica por que tomamos essa decisão, como funciona o modelo de confiança e o que estamos buscando da comunidade.

O Que Está Disponível no Open

A edição comunitária inclui 14 agentes cobrindo o ciclo de vida central da engenharia de dados: depuração de incidentes, monitoramento de qualidade, evolução de esquemas, construção de pipelines, contexto e catalogação de dados, governança e segurança, otimização de custos, migração de dados, insights e análises, operações de streaming, coordenação de orquestração, gerenciamento de conectores, observabilidade e inteligência de uso.

Em termos concretos, isso é 202+ ferramentas MCP, 15 conectores de catálogo (Snowflake, Databricks, BigQuery, Unity Catalog, Hive Metastore e mais), e 3.000+ testes bem-sucedidos. Cada agente possui seu próprio servidor MCP. Cada chamada de ferramenta é auditável.

Um 15º agente para monitoramento de modelos de ML é disponibilizado apenas para empresas, juntamente com 35 conectores e recursos adicionais para empresas, como middleware de detecção de PII, trilhas de auditoria à prova de adulteração e autenticação OAuth 2.1. A edição comunitária não possui restrições de recursos nos 14 agentes que inclui.

Por Que Open Source?

A resposta curta: porque agentes de caixa-preta e infraestrutura de dados crítica não se misturam.

Quando um agente modifica seus DAGs do Airflow, evolui um esquema em produção ou recomenda a exclusão de uma tabela não utilizada que acaba sendo consumida por uma equipe downstream da qual você não sabia, você precisa entender exatamente qual lógica levou a essa decisão. Você precisa ler o código. Você precisa auditar as chamadas de ferramenta. Você precisa verificar o raciocínio.

Esse requisito não é compatível com um produto de código fechado. Consideramos oferecer um serviço apenas hospedado e rejeitamos. Engenheiros de dados são justificadamente céticos em relação a sistemas autônomos que não podem inspecionar. Nós também seríamos.

• A dependência de fornecedor se acumula ao longo do tempo. Uma vez que um agente gerencia suas configurações de pipeline, resposta a incidentes e políticas de governança, os custos de mudança se tornam proibitivos. Seu conhecimento operacional vive em um sistema que você não possui.
• A personalização encontra barreiras. Cada ambiente de dados é diferente. Quando um agente proprietário não lida com seu padrão específico de migração, você faz um pedido de recurso e espera. Com o código aberto, você corrige isso você mesmo.
• Os requisitos de auditoria crescem. Indústrias regulamentadas precisam demonstrar exatamente como os sistemas autônomos tomam decisões. Ler o código-fonte real satisfaz os auditores de uma maneira que as garantias do fornecedor não fazem.
• A resposta a incidentes é cega. Quando um agente proprietário toma uma má decisão às 2 da manhã, seu engenheiro de plantão não pode ler o código para entender o que aconteceu.

Porque é Apache 2.0, seu investimento está protegido mesmo se nós desaparecermos amanhã. Fork, modifique, execute em produção indefinidamente. A licença garante isso.

O Modelo de Confiança: Somente Leitura por Padrão

Cada agente no grupo é projetado para operar em modo somente leitura por padrão. Os agentes observam, diagnosticam e recomendam. Eles não realizam ações de escrita a menos que você opte explicitamente por isso.

Esta é uma decisão arquitetônica deliberada, não uma limitação temporária. O modelo de confiança funciona em três níveis:

• Observar. Os agentes se conectam ao seu stack de dados, leem metadados, rastreiam a linhagem e apresentam descobertas. Nenhum acesso de escrita é necessário.
• Recomendar. Com base nas observações, os agentes propõem ações específicas: conserte esta consulta, evolua este esquema, exclua esta tabela não utilizada. Cada recomendação inclui a cadeia de raciocínio e as chamadas de ferramenta que a produziram.
• Agir (somente com opt-in). Com configuração explícita, os agentes podem executar tipos de ações aprovadas de forma autônoma. Portões de aprovação humana estão disponíveis para cada operação de escrita. Você controla exatamente quanta autonomia cada agente recebe.

Cada ferramenta MCP no sistema é marcada como uma operação LEITURA ou ESCRITA. Ferramentas de escrita estão desativadas por padrão e requerem habilitação explícita por agente, por ambiente.

Como Isso Funciona na Prática

Considere um incidente de produção: um pipeline chave falha às 2 da manhã. Sem os Data Workers, um engenheiro de plantão acorda, verifica os logs do Airflow, rastreia a falha para cima através do dbt, consulta o Snowflake para encontrar a causa raiz e aplica manualmente uma correção. Isso normalmente leva de 30 a 90 minutos em uma boa noite.

Com a edição comunitária, o agente de incidentes detecta a falha, rastreia a linhagem através das ferramentas, identifica a causa raiz e apresenta um diagnóstico com todas as evidências. O agente mostra exatamente o que encontrou, o que verificou e o que recomenda — projetado para comprimir esse diagnóstico de uma hora para minutos.

A edição comunitária informa a você a causa raiz. O nível Pro permite que o agente aplique automaticamente a correção e reexecute o pipeline, com portões de aprovação que você configura. Esse é o caminho de atualização: não recursos restritos sobre o mesmo trabalho, mas autonomia adicional em cima de total transparência.

Como Nós Construímos Isso

A arquitetura é centrada no MCP. Cada agente executa seu próprio servidor MCP, expondo ferramentas que outros agentes e clientes externos podem chamar. Os agentes coordenam através de um contexto compartilhado em vez de um orquestrador centralizado.

• 14 agentes especializados, cada um focado em um domínio da engenharia de dados
• 202+ ferramentas MCP em todos os agentes, com clara separação de LEITURA/ESCRITA
• 15 conectores de catálogo para descoberta de dados entre plataformas
• Infraestrutura em padrão de fábrica que autodetecta serviços reais a partir de variáveis de ambiente e recai em stubs em memória para desenvolvimento local
• 3.000+ testes cobrindo funcionalidade de ferramentas, coordenação de agentes e casos extremos

Passamos 12 meses em pesquisa e desenvolvimento antes deste lançamento. Os designs dos agentes são fundamentados em fluxos de trabalho reais de engenharia de dados, não em casos de uso hipotéticos. Dito isso, estamos em estágio inicial e somos honestos sobre isso. Esses agentes são projetados para lidar com cenários de produção, mas ainda não foram testados em batalha em centenas de ambientes. Essa é a finalidade da próxima fase.

O Modelo de Negócio

A edição comunitária é gratuita e totalmente funcional para os 14 agentes que inclui. Os níveis Pro e Enterprise adicionam autonomia operacional (ações de escrita, remediação automatizada), o 15º agente de monitoramento de ML, 35 conectores adicionais para empresas, detecção de PII, logs de auditoria à prova de adulteração, autenticação OAuth 2.1 e suporte dedicado.

A linha é clara: transparência e diagnóstico são gratuitos. Autonomia e segurança empresarial são pagos.

Estamos Buscando Parceiros de Design

Estamos buscando parceiros de design para validar esses agentes em ambientes reais. Se você gerencia um stack de dados com mais de alguns pipelines e já passou pelo incidente das 2 da manhã, pela mudança de esquema que quebrou consumidores downstream, ou pela conta do warehouse que silenciosamente dobrou, queremos trabalhar com você.

O que os parceiros de design recebem: acesso direto à equipe de engenharia, influência no roadmap, acesso antecipado a recursos Pro durante o período de validação e o conhecimento de que os agentes estão sendo moldados por suas necessidades do mundo real.

O que nós recebemos: feedback honesto sobre o que funciona, o que não funciona e o que perdemos.

Clone o repositório: github.com/DataWorkersProject/dataworkers-claw-community

Junte-se à comunidade: discord.com/invite/b8DR5J53

Leia a documentação e preços: dat