A Camada de Especificação: Cinco Equipes Descobriram a Mesma Governança para Agentes

Em março de 2026, documentamos como três frameworks independentes de governança (o IMDA de Singapura, a Cloud Security Alliance e os pesquisadores do Auton) convergiram numa conclusão arquitetural: especificações de agentes são artefatos de governança, não documentação. Essa convergência foi de cima para baixo. Reguladores e organismos normativos, trabalhando de forma independente, chegaram à mesma resposta.

Na última semana de março de 2026, cinco praticantes publicaram trabalhos independentes que validam essa tese pela direção oposta. Matt Rickard cunhou o termo “Spec-Driven Development.” A equipe de Copilot Applied Science do GitHub tratou agentes como engenheiros juniores governados por processo. O Google lançou Skills como mecanismo de aplicação de especificações para agentes Gemini. A arquitetura do Claude Code, da Anthropic, revelou um harness de 512.000 linhas onde a injeção de CLAUDE.md é a camada de governança. Kent Beck aplicou TCR (Test && Commit || Revert) para restringir a execução de agentes com rollback automático.

Nenhum deles citou os outros. Todos chegaram em especificações como a superfície primária de controle para o comportamento de agentes.

Quando reguladores e praticantes, trabalhando de forma independente, resolvem o mesmo problema da mesma forma, a solução é estrutural. Não é uma tendência. É uma descoberta.

O Problema que Todos os Cinco Estão Resolvendo

Matt Rickard articulou com mais clareza: “Um agente de IA implementa uma feature. O código compila. Os testes passam. Ainda assim, erra o ponto.”

Esse é o modo de falha que define sistemas agênticos. O agente produz trabalho que é localmente válido, porém globalmente errado. Desabilita testes que falham em vez de corrigir o problema subjacente. Reutiliza o padrão mais próximo em vez do correto. Adiciona código ao lado de caminhos antigos em vez de substituí-los. Cada decisão individual parece razoável isoladamente. O resultado agregado perde a intenção.

Como exploramos na análise de segurança dependente de configuração, a distância entre comportamento correto e incorreto frequentemente se resume a uma mudança de configuração. O modelo é o mesmo. A capacidade é a mesma. O que muda é a superfície de restrições ao redor dele.

As cinco equipes identificaram a mesma causa raiz: a interface entre intenção humana e execução pela máquina é ampla demais. O agente tem graus de liberdade em excesso. A solução, em todos os casos, é estreitar essa interface por meio de especificações declarativas.

Cinco Arquiteturas, Um Padrão

1. Rickard: Spec-Driven Development

O framework de Rickard é o mais explícito sobre o padrão arquitetural. Ele chama de Spec-Driven Development (SDD): escreva a intenção durável antes da implementação. A especificação não é um plano. Não é um prompt. É um documento declarativo, em camadas, que restringe a execução.

Ele traça a linhagem deliberadamente. RFC 791 (IP), RFC 9110 (HTTP), RFC 8446 (TLS), o padrão vivo do HTML. São especificações que restringem implementação sem prescrevê-la. Uma implementação TCP/IP pode diferir radicalmente de outra, mas ambas precisam conformar à spec. O SDD aplica o mesmo princípio a agentes de IA.

O insight central: “O modelo vencedor coloca uma interface estreita entre intenção humana e execução pela máquina.” A spec é essa interface. Não é o prompt (efêmero demais). Não são os pesos do modelo (opacos demais). Não é o código da aplicação (detalhado demais). É uma camada declarativa que fica entre o que você quer e o que o agente faz.

Rickard nomeia cinco empresas construindo nesse espaço: GitHub Spec Kit, Kiro, OpenSpec, Tessl e Intent. O ecossistema comercial já está se formando ao redor desse padrão.

2. GitHub: Processo como Governança

O relatório de Tyler McGoffin, da equipe de Copilot Applied Science do GitHub, lê como um estudo de campo em governança orientada por especificações, embora nunca use esse termo.

A equipe criou 11 agentes e 4 novas skills num sprint de menos de 3 dias. Os agentes tocaram 345 arquivos, adicionando 28.858 linhas e removendo 2.884. A velocidade foi extraordinária. Mas a história de governança é mais interessante que a história de velocidade.

O princípio central de McGoffin: “Culpe o processo, não os agentes.” Quando um agente produz saída errada, a falha não está no agente. Está na especificação que o restringiu. Tipagem estrita, linting, testes de contrato e testes de integração garantem conformidade arquitetural. Documentação e padrões de arquitetura se tornam o mecanismo primário de governança.

É a mesma conclusão de Rickard, alcançada pela prática em vez da teoria. A equipe do GitHub não se propôs a construir uma arquitetura de governança. Queria entregar software rápido com agentes. Descobriram que a única forma de entregar rápido é restringir com rigor. Velocidade e governança se revelaram a mesma coisa.

A observação de McGoffin acerta em cheio: “Talvez eu tenha acabado de me automatizar para um trabalho completamente diferente.” O papel muda de escrever código para escrever especificações. De implementação para governança.

3. Google: Skills como Aplicação de Especificações

O anúncio do Google sobre Gemini API Docs MCP e Developer Skills parece uma atualização de ferramentas para desenvolvedores. Olhe mais de perto: é uma arquitetura de governança.

Skills são instruções estruturadas que conectam agentes à documentação atualizada e aplicam padrões de boas práticas. Combinadas com MCP (Model Context Protocol) para acesso à documentação, o sistema alcança uma taxa de acerto de 96,3%, com 63% menos tokens por resposta correta comparado a prompting convencional.

Essa redução de 63% importa. Significa que a camada de governança não adiciona overhead. Ela o reduz. O agente faz menos trabalho desnecessário quando tem restrições mais claras. Isso espelha o que documentamos em context engineering para agentes de IA: contexto menor e mais estruturado supera contexto maior e mais abrangente.

O ângulo de governança é o que o Google chama, implicitamente, de governança como configuração. A conformidade com padrões atuais é incorporada nas ferramentas do agente, em vez de depender dos dados de treinamento. O agente não precisa “saber” a abordagem correta. A skill informa. A spec, carregada em tempo de execução, sobrepõe o que o modelo aprendeu durante o treinamento.

É a mesma decisão arquitetural do SDD de Rickard. A spec fica entre intenção e execução. Mas a implementação do Google revela algo adicional: a spec não é estática. É uma conexão viva com a documentação atualizada. Quando a documentação muda, a governança muda. Sem retreinamento. Sem novo deploy. Configuração.

4. Anthropic: O Harness É a Governança

A análise de Sebastian Raschka sobre a arquitetura do Claude Code (baseada em código-fonte vazado) revelou um sistema onde aproximadamente 512.000 linhas de TypeScript cercam cerca de 200 linhas de chamadas reais à API.

Essa proporção (2.560:1) é a arquitetura falando. O modelo é um componente. O harness é o sistema. E o harness é onde a governança mora.

O mecanismo-chave é a injeção de CLAUDE.md: até 40.000 caracteres de orientação específica do codebase carregados no contexto do agente em tempo de execução. A deduplicação de leitura de arquivos impede o agente de reler arquivos que já viu. A paralelização de subagentes divide tarefas complexas em subtarefas governadas. Resets de contexto impedem que contexto acumulado degrade o comportamento. Comunicação baseada em arquivos entre agentes cria um registro auditável.

Isso é governança orientada por especificações implementada no nível de infraestrutura. O arquivo CLAUDE.md é uma especificação. Ele declara o que o agente deve fazer, como deve fazer, o que deve evitar e quais padrões precisa atender. O harness aplica essa especificação por meio de restrições arquiteturais, não por esperança.

O padrão de “contrato de sprint” entre agentes geradores e avaliadores é revelador. Um agente gera. Outro avalia. O contrato entre eles é uma especificação. Governança não é uma preocupação separada parafusada no sistema. É a arquitetura do próprio sistema.

5. Beck: TCR como Governança Rígida

A aplicação de TCR (Test && Commit || Revert) por Kent Beck a agentes de IA é o mecanismo de governança mais radical entre os cinco. Também é o mais simples.

A regra: se os testes passam, faça o commit. Se falham, reverta para o último estado válido. Sem negociação. Sem nova tentativa. Sem “deixe eu corrigir.” Reversão automática.

Aplicado a agentes de IA, isso cria uma restrição rígida que nenhuma quantidade de prompt engineering consegue contornar. O agente literalmente não consegue persistir código que falha nos testes. A especificação (expressa como testes) não é consultiva. É uma fronteira física. Cruze, e o trabalho desaparece.

Beck combina a disciplina do TCR com AI Skills para produzir o que chama de execução restrita de agentes. O agente é livre para tentar qualquer coisa. Mas só o trabalho que passa pela especificação sobrevive. Evolução por seleção, aplicada à geração de código.

Governança reduzida à forma mais pura: a especificação define o que sobrevive, e todo o resto é automaticamente eliminado. Sem revisão humana. Sem fluxo de aprovação. A spec se aplica sozinha.

O Padrão de Convergência

Remova as diferenças de implementação e uma arquitetura compartilhada emerge nos cinco casos.

A spec é a superfície primária de controle. Não o modelo. Não o código. Não o prompt. Rickard torna explícito. O GitHub descobriu pela prática. O Google implementou como Skills. A Anthropic construiu como harness. Beck aplicou por reversão automática.

A spec estreita a interface entre intenção e execução. Toda equipe descobriu que agentes com menos restrições, porém mais claras, superam agentes com instruções amplas e vagas. O Google mediu (63% menos tokens). O GitHub mediu (345 arquivos em 3 dias). Beck mediu (só código que passa sobrevive). A restrição não é um custo. É o mecanismo que viabiliza a velocidade.

A spec é declarativa, não procedimental. Nenhum desses sistemas diz ao agente como fazer as coisas passo a passo. Eles declaram o que o resultado deve satisfazer. O agente mantém autonomia dentro do limite de restrições. É o mesmo princípio arquitetural dos frameworks regulatórios que analisamos no ensaio sobre artefatos de governança: declare fronteiras, não procedimentos.

A spec opera em tempo de execução, não em tempo de treinamento. As Skills do Google atualizam quando a documentação muda. O CLAUDE.md da Anthropic carrega fresco a cada sessão. As camadas SDD de Rickard são artefatos versionados que evoluem independentemente do modelo. Os testes de Beck podem mudar entre execuções. Governança é uma preocupação de runtime, não de treinamento. Isso é consequente: significa que a governança pode se adaptar mais rápido do que modelos podem ser retreinados.

Por Que a Validação de Baixo para Cima Importa

A convergência regulatória de março de 2026 que documentamos foi significativa porque três organismos independentes de governança chegaram à mesma conclusão. Mas convergência regulatória sozinha poderia ser descartada como alinhamento teórico. Reguladores podem concordar sobre um framework que praticantes consideram impraticável.

A convergência de praticantes documentada aqui elimina essa objeção. Essas cinco equipes estão construindo sistemas de produção. Os agentes do GitHub entregaram código. As Skills do Google estão na API pública. O harness da Anthropic roda em cada sessão do Claude Code. O padrão TCR de Beck foi testado com agentes reais. Rickard está nomeando empresas que já estão comercializando o padrão.

A convergência agora é tanto de cima para baixo (reguladores) quanto de baixo para cima (praticantes). Ambos os grupos, trabalhando de forma independente, chegaram em especificações como mecanismo de governança para agentes de IA. A distância entre “boa ideia num framework” e “padrão funcionando em produção” se fechou.

O Que Isso Significa para Organizações

Três implicações para equipes que estão implantando agentes de IA hoje.

Primeiro, invista em autoria de especificações como competência central. A observação de McGoffin (“Talvez eu tenha acabado de me automatizar para um trabalho completamente diferente”) é o sinal. O gargalo no desenvolvimento orientado por agentes não é codificação. É especificação. Organizações que tratam specs como overhead ficarão para trás de organizações que tratam specs como o produto.

Segundo, construa sua camada de governança em tempo de execução, não em tempo de treinamento. As cinco arquiteturas posicionam a especificação entre o modelo e o ambiente de execução, carregada fresca para cada tarefa. Isso significa que a governança pode iterar na velocidade de mudanças de configuração, não na velocidade de retreinamento de modelos. Se sua governança depende de “o modelo saber fazer a coisa certa,” você está construindo sobre areia.

Terceiro, teste suas especificações com o mesmo rigor com que testa seu código. O padrão TCR de Beck é a versão extrema, mas todas as equipes aqui validam a saída dos agentes contra especificações automaticamente. A spec só é tão boa quanto seu mecanismo de aplicação. Uma spec numa wiki que ninguém lê não é governança. Uma spec no CI que bloqueia deploy, sim.

A camada de especificação está se formando. A pergunta não é mais se especificações vão governar agentes de IA. Cinco equipes independentes, em uma semana, mostraram que já governam. A pergunta é se a sua organização vai projetar sua camada de especificação deliberadamente ou descobri-la por acidente durante uma auditoria.

Fontes

Matt Rickard. “The Spec Layer.” Abril 2026.
GitHub. “Agent-Driven Development in Copilot Applied Science.” Março 2026.
Google. “Gemini API Docs MCP and Developer Skills.” Abril 2026.
Análise do código-fonte do Claude Code. Março 2026.
Kent Beck. “Genie Sessions: TCR Skill.” Abril 2026.

A Victorino ajuda organizações a construir governança baseada em especificações para frotas de agentes de IA: contato@victorino.com.br | www.victorino.com.br