Nos dois posts anteriores montamos uma base de conhecimento. No primeiro, dissecamos a anatomia do agente, com a tese de que Agent = Model + Harness, o modelo de guides e sensors, o steering loop e os oito arquivos markdown que vivem no repo junto com o código. No segundo, pegamos um pedido real (uma VPC de staging pro projeto Atlas) e fomos do início ao fim. O agente consultou o FEEDFORWARD.md, registrou no FEEDBACK.md e parou pra pedir ajuda quando não sabia.

Só que os dois posts descrevem uma pessoa, com um agente, em um repositório. Mas no dia a dia não é bme assim, nas empresas a estrutura é feita por times, o código vive em vários repositórios, é feito com gente que entra e sai e conhecimento que precisa ser compartilhado.

Montar um harness que funciona pra você é a parte fácil. Fazer o time usar, e manter isso vivo, é outro problema. O risco não está em o modelo alucinar. É o time ignorar o agente e voltar a escrever Terraform na mão porque “assim é mais rápido”. Um harness que ninguém usa não serve pra nada, e adoção não se decreta por e-mail.

Neste último post vou falar de como empacotar o harness como template, compartilhar conhecimento entre projetos, decidir quem cuida dele, adotar aos poucos e lidar com os problemas que aparecem quando mais de uma pessoa entra na jogada.

Do repo único ao template distribuível

No post 2, os oito arquivos (AGENTS.md, MEMORY.md, HANDOFF.md, FEEDFORWARD.md, FEEDBACK.md, PROCESS.md, TASKS.md, CHECKLIST.md) viviam na raiz de um projeto. Como fazer o próximo projeto nascer com essa estrutura sem copiar e colar na mão?

A resposta é empacotar como template. Mas clonar o harness do Atlas leva lixo junto, como as decisões do MEMORY.md, as tasks do TASKS.md e o estado do HANDOFF.md. O agente do projeto novo vai ler uma decisão sobre subnets que não tem nada a ver com ele. Contexto errado é pior do que nenhum contexto.

A saída que eu proponho é separar o genérico do específico, por exemplo:

• O genérico vai no template. Isso inclui a estrutura do AGENTS.md, o PROCESS.md com os seis stages e o CHECKLIST.md com os quality gates. É o esqueleto do método e não muda de projeto pra projeto.
• O específico nasce vazio. MEMORY.md, HANDOFF.md e TASKS.md começam zerados e são preenchidos pelo trabalho real.
• O híbrido herda uma base. O FEEDFORWARD.md começa com os problemas conhecidos da organização inteira, sem os do Atlas. Já volto nisso.

O template pode ser um repositório template do Git ou um scaffolding com cookiecutter ou copier. A ferramenta importa pouco. O conceito é harness em camadas.

Camada da organização (compartilhada, versionada via git)
├── PROCESS.md          — o método, igual pra todos
├── CHECKLIST.md        — os quality gates, iguais pra todos
├── AGENTS.md (base)    — estrutura e comportamento padrão
└── FEEDFORWARD-org.md  — erros comuns e convenções da empresa inteira

Camada do projeto (local, cresce sozinha)
├── MEMORY.md           — nasce vazio, acumula decisões deste projeto
├── HANDOFF.md          — estado desta sessão
├── TASKS.md            — trabalho deste projeto
└── FEEDFORWARD.md      — pegadinhas só deste projeto

O nível local tem precedência sobre o global, como em qualquer ferramenta de agente. O projeto herda o método e o conhecimento da organização e constrói o que é dele por cima.

O catálogo de conhecimento compartilhado

O que separa “cada um tem seu agentezinho” de “a organização tem um sistema que aprende” é a propagação. No post 1, o conhecimento se movia no tempo, já que um problema repetido virava feedforward e a próxima execução já previnia. Agora ele precisa se mover entre projetos e entre times.

Dois níveis de FEEDFORWARD

A race condition de security group rule do post 2, que exigiu um depends_on explícito, virou o ponto de atenção FF-007 no FEEDFORWARD.md do Atlas. Mas ela é comportamento da AWS e vai atingir qualquer projeto que crie security group rules. Se ficar presa no Atlas, o time do Vega cai na mesma armadilha daqui a três meses. O steering loop falhou, não por falta de registro, mas por falta de propagação horizontal.

Por isso são dois níveis.

• O FEEDFORWARD.md do projeto guarda o que só vale ali, como um módulo legado do Atlas com variável não documentada.
• O FEEDFORWARD-org.md guarda o que vale pra empresa toda. Quirks de provider, CIDRs alocados, módulos internos aprovados, naming global e a race condition do security group.

Promoção entre camadas

A regra do post 1 ganha um degrau. Se o mesmo problema aparece em dois projetos, ele sobe de FEEDFORWARD.md pra FEEDFORWARD-org.md. A mecânica é a mesma, baseada em frequência, mas a unidade de contagem passa de “ocorrência na sessão” pra “projeto afetado”.

O resultado é que times que nunca se falaram aproveitam os erros uns dos outros. O engenheiro do Vega nunca vai saber do problema do Atlas, só vai notar que o agente já coloca o depends_on no lugar certo.

O arquivo gigante

Se tudo der certo, o catálogo cresce. Um FEEDFORWARD-org.md com seis meses de promoções pode ter centenas de entradas, o que bate de frente com o progressive disclosure do post 1. Contexto de LLM é finito, e informação relevante enterrada no meio de duas mil linhas é quase tão ruim quanto informação ausente. Conhecimento sem curadoria vira passivo. Três medidas ajudam.

• Particionar por domínio. networking.md, security.md, state.md, providers.md. O agente carrega só a partição da task atual, e quem mexe em VPC não carrega as armadilhas de IAM.
• Arquivar o obsoleto. O MEMORY.md é append-only e nunca perde entradas, mas uma entrada superseded pode ir pra um MEMORY-archive.md que o agente não carrega por padrão. O audit trail fica preservado e a memória de trabalho fica limpa.
• Revisar a cada trimestre. Entradas nunca acionadas, providers fora de uso, convenções que mudaram. O catálogo precisa de poda como código precisa de refactoring, senão vira aquele utils.js de quatro mil linhas que ninguém entende.

Governança, ou quem edita o harness

Harness compartilhado é código compartilhado, e sem dono apodrece. Uma mudança no FEEDFORWARD-org.md ou no PROCESS.md afeta todos os agentes de uma vez e chega a dezenas de projetos na próxima sessão de cada um. Não pode ser push direto na main.

• Pull request e review pra qualquer mudança no nível org. O guide dirige a geração do Terraform, então um erro nele se multiplica.
• CODEOWNERS, com revisão mais criteriosa no PROCESS.md, que tem o maior blast radius.
• Um curador do harness, que pode ser um papel rotativo. Ele não escreve o conteúdo, que nasce de quem está na linha de frente. Garante que as promoções façam sentido, que as partições continuem coerentes e que a revisão trimestral aconteça. Sem dono, a curadoria é de todos, ou seja, de ninguém.

Adoção incremental (sem forçar ninguém)

Essa é a parte que mais gente erra, por ser a menos técnica. Um harness bom morre se for empurrado pra organização inteira de uma vez.

Comece por um piloto, com um time que já sente a dor, que repete os mesmos erros e perde contexto entre sprints. Time confortável não tem motivo pra mudar e resiste com razão.

Adoção vem por valor percebido, não por mandato. E-mail do diretor gera resistência e sabotagem silenciosa. O que funciona é mostrar o agente que aplica uma pegadinha que custaria uma tarde de debug a um sênior. A tração vem do “poxa, isso me pouparia tempo”.

A autonomia do agente deve crescer com a confiança do time.

1. Sugestão. O agente propõe, o humano escreve.
2. Aprovação em tudo. O agente escreve e roda os sensors, mas espera aprovação a cada passo relevante.
3. Seguro sozinho, perigoso com aprovação. Operações não-destrutivas rodam sem parar. destroy, must-replace e mudança de produção exigem aprovação humana.

O terceiro nível é o regime permanente, o mesmo do post 2. Nem o nível mais alto dá autonomia total, porque humanos direcionam e agentes executam. Um agente que decide sozinho o que destruir, mais cedo ou mais tarde, destrói a coisa errada com total convicção.

Nem todo caso compensa. Em projeto efêmero ou one-off, montar o harness custa mais do que rende. O agente rende onde há repetição, continuidade e conhecimento que precisa sobreviver às pessoas.

Pra medir, olhe o tempo de code review, a repetição de erros já documentados e o tempo de onboarding. Se nada melhora, o problema é o harness.

Concorrência com mais de uma pessoa

Quando o time inteiro usa, aparecem problemas que um operador só não tinha.

• State locking. Fica a cargo do Terraform. Se o state está travado, o agente espera ou escala, nunca força.
• HANDOFF.md. Foi pensado pra uma sessão. Com duas pessoas em frentes diferentes, vira ponto de conflito. Escope o handoff por branch ou feature, pra cada linha de trabalho ter seu estado retomável.
• MEMORY.md. O append-only resolve o merge, porque basta manter as duas adições. Vale como regra explícita no AGENTS.md, que manda adicionar no fim e nunca reescrever entradas existentes.
• Correlação de sessões. Ferramentas de agente costumam expor um identificador de sessão em variável de ambiente. Ele liga um apply à sessão que o originou, o que ajuda a reconstruir quem fez o quê depois que algo deu errado.

Evolução do harness

O harness muda com providers, módulos internos e modelos. Versione o template da organização com tags, pra que um projeto saiba que herdou a v2.3 e decida quando subir pra v3.0, lendo o que mudou. Sem isso, atualizar vira copia-e-cola arriscado.

O steering loop agora roda em três níveis. O agente aprende dentro do projeto (post 1), o time aprende entre projetos (este post) e a organização aprende entre times, com o catálogo central como memória coletiva. É o mesmo loop, só que fractal. A cada nível, feedback vira feedforward.

Fechando a série

Os três posts buscam responder três perguntas. O post 1 explicou o que é, com a anatomia do harness. O post 2 mostrou como funciona, num projeto do intake ao close. Este mostrou como escala, de uma pessoa pra organização.

A tecnologia é a parte fácil. O modelo se troca num flag e os oito arquivos se criam numa tarde. O que separa quem usa IA de verdade de quem só instalou uma ferramenta é a disciplina de manter o conhecimento versionado, podado e compartilhado. Humanos direcionam, agentes executam. Você continua responsável pela infraestrutura e passa a ser responsável também pelo sistema que decide como ela é construída, que é o trabalho de projetar a automação.

Com esse post encerro a série. Se foi útil para você, compartilhe para mais pessoas.

Abraços!

Vida longa e próspera a todos!!

Referências

• Parte 1 - A anatomia de um AI Agent para projetos de IaC
• Parte 2 - Na prática, fazendo um projeto Terraform com um AI Agent do início ao fim
• Harness engineering: leveraging Codex in an agent-first world — OpenAI, Fev 2026
• Harness design for long-running application development — Anthropic, Mar 2026
• Harness engineering for coding agent users — Martin Fowler / Birgitta Böckeler, Abr 2026
• Spec Driven chegou no limite — Harness Engineering é o próximo passo — Aprendi muito com esse vídeo ⭐⭐⭐⭐⭐

Entre em contato:

NewsLetter - https://engineeringmanager.com.br/
Linkdin - linkedin.com/in/leonardoml/
Twitter: @infraascode_br

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- --- As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.