A Datadog Governa Suas Ferramentas de Agente Com Uma Regra: Sem Eval, Sem Merge

O time de Cloud SIEM da Datadog construiu mais de uma dezena de ferramentas MCP para seu agente de segurança, e o controle que mantém o conjunto coerente cabe em duas frases do próprio post de engenharia deles: “Qualquer regressão maior que 5% no score base de eval é sinalizada. O runner também sinaliza qualquer ferramenta que entre sem cobertura de eval, o que se tornou um dos nossos primeiros mecanismos de governança.”

É essa a camada de enforcement inteira. Não existe comitê de arquitetura com poder de veto. Não existe fila de RFC. Existe um job de CI que se recusa a deixar passar uma ferramenta sem teste, e se recusa a deixar uma ferramenta testada degradar as que já estão em produção.

Vale registrar de saída: isso é conteúdo de fornecedor. O post funciona também como pitch do Datadog Agent Observability e do runner interno de eval deles, e todos os números vêm da telemetria do próprio produto da Datadog, sem medição independente. Foi publicado em 17 de julho de 2026 por Chelsea Xu, Eddie Cai, Romain Kirszbaum e Mohamed Hachem Ouertani, todos da Datadog. Leia as recomendações de ferramenta com essa ressalva. Leia a estrutura de governança de qualquer forma, porque a estrutura é reaproveitável sem comprar nada.

A Janela de Contexto É Um Recurso Compartilhado

Quando vários times contribuem ferramentas para o mesmo agente, todos escrevem em um único espaço finito: a janela de contexto do modelo no momento da decisão. Cada schema, cada descrição, cada lista de parâmetros disputa o mesmo orçamento de atenção. A Datadog descreve o modo de falha sem rodeios: “Adicione ferramentas suficientes e o agente pode perder a noção de qual delas serve para a tarefa que está na frente dele.”

Isso faz a janela de contexto se comportar como um bem comum. A contribuição de cada time é localmente racional. O time de detecção adiciona uma ferramenta de autoria de regras porque autoria de regras representa 44% do que os clientes dele fazem no produto. O time de triagem adiciona uma ferramenta de sinais em lote porque cerca de 25% dos clientes fazem triagem em massa e 14% batem no teto de 50 sinais da interface. Nenhum dos dois está errado. As duas adições apertam a mesma abertura, e o custo cai sobre a acurácia de seleção de ferramentas do conjunto todo, que nenhum time contribuinte mede nem possui.

Code review comum não pega isso. Uma ferramenta nova pode estar individualmente bem desenhada, bem documentada e correta, e ainda assim piorar a capacidade do agente de escolher entre as onze que já estavam ali. A regressão é uma propriedade do conjunto, e a mudança apenas a dispara.

Cinco Comportamentos, Um Score Ponderado

A resposta da Datadog é medir o conjunto em cada pull request. O framework de eval pontua cinco comportamentos:

O agente chamou as ferramentas que deveria chamar?
Evitou as que não deveria chamar?
Usou um número sensato de ferramentas?
Passou os argumentos corretos?
Seguiu uma trajetória razoável até a resposta?

Esses cinco viram um único score ponderado, com a acurácia de seleção de ferramentas recebendo o peso mais alto. Cada cenário roda várias vezes e os resultados são somados em média, o que amortece o não determinismo que torna teste de agente desconfortável desde o começo. Nas palavras deles: “Testes tradicionais assumem que a mesma entrada produz a mesma saída, e um agente não oferece essa garantia.” As respostas das ferramentas são mockadas, o que mantém o custo de tokens de saída baixo o suficiente para a suíte rodar em cada mudança em vez de uma vez por noite.

A taxa de sucesso base almejada gira em torno de 80%, e o raciocínio atrás desse número é o detalhe mais transferível do post. Oitenta por cento “deixa espaço para a alucinação ocasional sem mascarar regressões reais”. Coloque a régua em 95% e a suíte fica vermelha o tempo todo por motivos sobre os quais ninguém consegue agir, então os times passam a ignorá-la. Coloque em 60% e uma degradação legítima desaparece no ruído. O limite é calibrado contra a variância real do modelo, e escolhê-lo deliberadamente é o que transforma uma suíte de eval em um portão em que as pessoas confiam.

Cada execução de eval também gera um experimento no Datadog Agent Observability que localiza qual passo falhou. Essa parte é específica do produto. A exigência de localização, por outro lado, vale em qualquer stack: um portão que só informa que o score caiu produz um exercício de bisect, enquanto um portão que informa qual cenário e qual passo caíram produz uma correção.

telemetry.intent Como Primitiva de Governança

Escondido no schema da ferramenta existe um campo chamado telemetry.intent. O agente precisa declarar, como entrada da chamada, o que está tentando realizar.

É uma decisão de design pequena com uma vida dupla incomum. Como observabilidade, significa que toda invocação de ferramenta chega com a razão declarada pelo próprio agente anexada, então um trace fica legível sem reconstruir a intenção a partir dos argumentos depois do fato. Como governança, converte intenção de algo que se infere em algo que se consulta, alerta e audita. Dá para perguntar quais intenções o agente declara com mais frequência, se a intenção declarada combina com a ferramenta efetivamente escolhida, e se uma classe de intenção deveria ter sido recusada em vez de atendida.

Compare com o funcionamento da maioria das trilhas de auditoria de agente. Elas registram o que aconteceu: esta ferramenta, estes argumentos, esta resposta, esta latência. Reconstruir o porquê exige ler a conversa em volta e adivinhar. Já argumentamos que o registro que o próprio agente faz do seu raciocínio é a superfície de auditoria que importa, e um campo de intenção obrigatório é a versão mais barata possível dessa ideia: uma string, obrigatória, na fronteira em que o agente pede ao sistema que faça algo.

Se você está desenhando um schema interno de ferramentas neste trimestre, inclua o campo. Ele custa alguns tokens por chamada e é praticamente impossível de aplicar retroativamente sobre um ano de traces históricos.

A Correção Para Um Agente Confuso É Menos Entrada

A segunda coisa que a Datadog inverte é o que fazer quando a performance das ferramentas cai. O instinto é somar: mais descrição, mais exemplos, mais parâmetros, mais orientação. Os movimentos deles foram na direção oposta.

Eles quebraram o schema em seções nomeadas (campos de topo, sintaxe de query, opções, exemplos) e o fizeram aceitar filtros, para o agente puxar apenas a fatia de que precisa. “Deixe os filtros de fora e a ferramenta retorna tudo. Passe os filtros e ela retorna só a fatia correspondente.” Filtrar para um único tipo de regra cortou o uso de tokens em cerca de 15%. Adicionar um filtro por método de detecção chegou a algo entre 41% e 47%.

O redesenho da triagem em lote é o exemplo mais afiado. A ferramenta antiga obrigava o agente a carregar os IDs dos sinais no contexto. A nova aceita uma query de busca e resolve os IDs correspondentes internamente: “Os IDs nunca entram no contexto do agente, então o custo de tokens de entrada permanece estável por mais sinais que a query encontre.” A ferramenta redesenhada lida com 500 sinais por chamada, e atualizar 50 sinais saiu de mais de dois minutos para algumas centenas de sinais em pouco mais de um minuto.

Nada disso saiu de uma reunião de design. Saiu da leitura de comportamento: 44% das mensagens analisadas envolviam criar ou editar regras de detecção, 14% dos clientes batiam no teto de 50 sinais, e um cliente fez sete chamadas de triagem em lote numa janela de nove minutos, cada resposta com exatamente 52.366 bytes, movendo mais de 350 sinais numa sentada. Esse último dado é o tipo de coisa que nenhum documento de requisitos produz.

Por Que o Comitê Cuida de Padrões e a CI Cuida de Enforcement

A Datadog tem um comitê, sim. Ele cuida de infraestrutura e padrões, e o foco declarado é estreito: “A preocupação principal do comitê é se uma ferramenta nova degrada o conjunto que já está em produção.” A contribuição segue totalmente self-service em todos os estágios anteriores ao GA.

O raciocínio para manter a aprovação leve merece citação: “Diferente de features determinísticas, ferramentas MCP melhoram principalmente por iteração rápida e dogfooding intenso contra casos de uso reais, então um processo pesado de aprovação atrasaria justamente o ciclo de feedback que as torna melhores.” Revisão humana é o instrumento errado aqui porque o que está sendo protegido é uma propriedade numérica de um conjunto, mensurável em cada commit. Comitês são lentos e inconsistentes nisso. A CI é rápida e idêntica sempre.

A honestidade deles sobre conclusão também é útil: “nenhum checklist marca uma ferramenta MCP como pronta… o sinal mais confiável é observar como agentes e usuários se comportam juntos na prática.” Isso é coerente com o que escrevemos sobre dificuldade de eval como sintoma de produto. Uma ferramenta para a qual você não consegue escrever um cenário costuma ser uma ferramenta cujo trabalho ainda está indefinido.

Faça Isso Agora

Pegue o registro de ferramentas do seu agente interno e responda a uma pergunta: quantas dessas ferramentas têm cenário de eval, e o que acontece na CI com um pull request que adiciona uma ferramenta sem cenário?

Se a resposta for “nada acontece”, você tem o mesmo problema de bem comum sem nenhuma instrumentação, e só vai perceber a degradação quando alguém reportar que o agente escolhe a ferramenta errada. Construa a menor versão possível: três ou quatro cenários por ferramenta, acurácia de seleção com o peso mais alto, respostas mockadas, várias execuções somadas em média, uma base calibrada onde a variância do seu modelo de fato está, e um check de CI que falha por cobertura ausente antes de precisar falhar por regressão. O check de cobertura é a parte que governa. Todo o resto é medição.

Fontes

Datadog. “Creating MCP tools for Cloud SIEM.” Julho de 2026. Escrito por Chelsea Xu, Eddie Cai, Romain Kirszbaum e Mohamed Hachem Ouertani. Conteúdo de fornecedor que promove o Datadog Agent Observability; todos os números são telemetria do próprio produto da empresa.

A Victorino ajuda organizações de engenharia a desenhar portões de eval e padrões de contribuição de ferramentas para plataformas internas de agentes: contato@victorino.com.br | www.victorino.com.br