Entenda por que o agente não muda as próprias regras
Um agente que reescreve as próprias regras pode, sem querer, afrouxar justamente a regra que o segurava. Uma linha "pode pagar boletos pequenos" e a política do módulo 4.1 deixa de valer.
Por isso o AGENTS.md do kit diz, com todas as letras: "Você não muda estas regras. Para propor uma mudança, acrescente uma linha na tabela 'Aprendizado' da runtime/POLITICA.md. Quem aprova é o humano."
🆕 Novo aqui? Os quatro arquivos do aprendizado
- Tabela Aprendizado — no fim da
runtime/POLITICA.md. Onde o agente escreve as propostas. - Lessons — seção
## LessonsdoAGENTS.md. Só regras que você aprovou, uma por linha. - FALHAS.md —
runtime/FALHAS.md. Uma linha por coisa que quebrou. - LIMITES.md —
runtime/LIMITES.md. Uma linha por coisa que o ambiente não deixou fazer.
Como ler o desenho: o caminho azul de baixo passa sempre pela caixa âmbar, que é você. O arco vermelho de cima é o agente escrevendo direto nas Lessons, sem passar por você. É esse atalho que o AGENTS.md proíbe.
✓ O agente pode
- ✓ Acrescentar linha na tabela Aprendizado
- ✓ Anotar falha no
FALHAS.md - ✓ Anotar bloqueio no
LIMITES.md - ✓ Propor a lição quando você o corrige
✗ O agente não pode
- ✗ Marcar a própria proposta como aprovada
- ✗ Escrever nas Lessons sem o seu sim
- ✗ Subir o teto de uma ação na POLITICA
- ✗ Apagar linha de falha que o incomoda
o agente
você
vira Lesson
só mudam com seu sim
Preencha a tabela Aprendizado
A tabela fica no fim da runtime/POLITICA.md, sob o título "Aprendizado (propõe → aprova → incorpora)". No kit ela vem vazia: só o cabeçalho, esperando a primeira proposta.
Cada linha tem quatro colunas. A segunda pede evidência: não vale "achei melhor", vale "aconteceu isto, neste dia, com este resultado".
O agente **não muda as próprias regras**. Ele acrescenta uma linha aqui; você decide. | data | o que aconteceu (com evidência) | proposta (1 linha) | status: proposto / aprovado / recusado | |---|---|---|---|
| data | o que aconteceu (com evidência) | proposta (1 linha) | status |
|---|---|---|---|
| exemplo | Clara pediu "horários livres de amanhã" e o agente respondeu com a data de hoje; a resposta tinha horários já marcados | Antes de consultar a agenda, repetir a data em AAAA-MM-DD e esperar confirmação | proposto |
| exemplo | No relatório da distribuidora, o agente escreveu "posso emitir o boleto?" em vez de deixar o boleto pronto para a Sônia | Em pagamento, entregar o texto pronto e a lista do que conferir; nunca oferecer executar | proposto |
O que olhar na tabela: as duas linhas são exemplos de como ficaria, escritos para este curso, não vêm no kit. Repare que a proposta cabe em uma linha e diz o que fazer, não o que sentir.
proposto
O agente escreveu. Ninguém decidiu ainda. Nada muda no comportamento.
aprovado
Você trocou o status. A proposta vai para as Lessons (tópico 3) e passa a valer.
recusado
Fica na tabela. Assim o agente não propõe a mesma coisa de novo na semana seguinte.
💡 Não apague o recusado
A linha recusada é memória. Ela mostra ao agente, e a você daqui a três meses, que a ideia já foi pensada e por que não entrou.
quando aconteceu
o fato, não a opinião
uma linha
proposto / aprovado / recusado
Promova o aprovado para as Lessons
A POLITICA.md fecha a seção assim: "Aprovado → vira regra no CLAUDE.md/AGENTS.md". No kit, o lugar é a seção ## Lessons do AGENTS.md.
Por que no AGENTS.md e não no CLAUDE.md? Porque o CLAUDE.md do kit começa puxando o AGENTS.md. Uma regra escrita num lugar só vale para o Claude e para o Codex.
## Lessons Regras aprovadas pelo humano, uma por linha:
@AGENTS.md ## Self-learning Quando o humano corrigir você, ou você notar um erro seu: proponha a lição como uma linha na tabela "Aprendizado" de `runtime/POLITICA.md`. Depois de aprovada, ela entra em `## Lessons` do `AGENTS.md`.
🆕 Novo aqui? O que faz o @AGENTS.md
No CLAUDE.md, uma linha com @ e o nome de um arquivo pede ao Claude Code que leia aquele arquivo junto. O Codex lê o AGENTS.md direto. Resultado: os dois agentes leem as mesmas Lessons.
Como ler o desenho: tudo passa pela caixa âmbar. Você escreve a regra uma vez no AGENTS.md, e as duas setas azuis levam a mesma regra aos dois agentes. Não existe uma versão "só do Claude" para ficar desatualizada.
Exemplo de como ficaria (não vem no kit)
Se a Clara aprovar a primeira proposta do tópico 2, o fim do AGENTS.md fica assim:
## Lessons Regras aprovadas pelo humano, uma por linha: - Antes de consultar a agenda, repetir a data em AAAA-MM-DD e esperar confirmação.
💡 Quem escreve a linha nas Lessons
Pode ser você, à mão, ou o agente, depois do seu pedido explícito ("aprovo a linha X, copie para as Lessons"). O que conta é a ordem: primeiro o seu sim, depois a cópia.
uma regra por linha
Claude lê junto
mesmas regras
corrigido → propõe
Anote cada falha em uma linha
Quando algo quebra e você conserta, a tentação é seguir em frente. O runtime/FALHAS.md pede trinta segundos antes: uma linha com a data, o que quebrou, a menor correção e se o problema era de prompt ou de infra.
O kit já traz uma linha real, de quando ele mesmo foi testado. É o melhor exemplo do formato:
| data | o que quebrou | menor correção | prompt \| infra | |---|---|---|---| | 2026-10-05 | `doctor.mjs` dizia "codex sem login" com o Codex logado | ler stdout **e** stderr (`codex login status` responde no stderr) | infra |
🆕 Novo aqui? stdout e stderr
Todo comando de terminal tem duas saídas de texto: a normal (stdout) e a de avisos e erros (stderr). Na tela as duas aparecem juntas, mas um programa que lê só uma delas perde a outra. Foi o que aconteceu com o doctor.mjs.
prompt
- ✓ O pedido induziu o erro
- ✓ O modelo entendeu outra coisa
- ✓ Faltou dizer um limite no pedido
- ✓ Correção típica: uma frase a mais na instrução
infra
- ✓ Máquina, rede, login, versão de programa
- ✓ Script que lê o lugar errado
- ✓ Serviço fora do ar ou lento
- ✓ Correção típica: uma proteção (limite de tempo, nova tentativa, checagem)
💡 Por que uma linha só
Depois de umas dez linhas o padrão aparece sozinho: "metade é infra de login", "toda falha de prompt é data". Texto longo esconde o padrão. Se precisar de detalhe, escreva noutro arquivo e ponha o link na linha.
quando quebrou
o sintoma visto
a proteção que faltava
ou os dois
Anote o que o ambiente barrou
Nem todo problema é falha. Às vezes nada quebrou: o ambiente simplesmente não deixou. O sandbox bloqueou a rede, a ferramenta não tem o recurso, o site pede login. Isso vai para o runtime/LIMITES.md.
No kit ele vem só com o cabeçalho. A última coluna, status, diz se o limite continua aberto ou se você aceitou conviver com ele.
| data | o que tentei | o que barrou | contorno | status | |---|---|---|---|---|
| Situação | Vai para | Por quê |
|---|---|---|
O doctor.mjs lia só uma saída e errava | FALHAS.md | era defeito, e foi corrigido |
| O sandbox do Codex bloqueia a rede, até a local | LIMITES.md | é regra do ambiente; a receita R1 manda anotar |
| Você usou engenharia reversa num teste | LIMITES.md | a POLITICA manda: laboratório anotado |
| Você corrigiu o agente e ele aprendeu | tabela Aprendizado | é mudança de regra, precisa do seu sim |
O que olhar na tabela: a pergunta que separa é "quebrou ou não deixaram?". Quebrou e consertou, FALHAS. Não deixaram, LIMITES. Mudou o jeito de trabalhar, Aprendizado.
O exemplo que o próprio kit dá
A receita R1 avisa: o sandbox do Codex bloqueia rede. Se um teste precisar subir um servidor, acrescente na ponte o ajuste abaixo e anote em LIMITES.md:
-c sandbox_workspace_write.network_access=true
A linha registraria: o que você tentou (subir o servidor de teste), o que barrou (sandbox sem rede), o contorno (esse ajuste) e o status.
⚠️ Contorno não é licença
Abrir a rede do sandbox é afrouxar uma cerca. Por isso ele vai para um arquivo que você revisa. Um contorno sem anotação vira, em três meses, uma porta aberta que ninguém lembra de ter aberto.
regra do ambiente
o que você fez
aberto ou aceito
também se anota
Faça a revisão da semana com o agente
Os três arquivos só ajudam se alguém os lê. Uma vez por semana, peça ao agente para ler tudo e transformar o que se repete em propostas. Ele faz a parte chata. Você faz a parte que importa: decidir.
São dois pedidos. O primeiro só gera propostas. O segundo, que você escreve depois de ler, aprova o que você quiser.
Abra claude (ou codex) na pasta do projeto e cole:
Leia runtime/FALHAS.md, runtime/LIMITES.md e a tabela Aprendizado de runtime/POLITICA.md. Procure o que se repete ou ainda está aberto. Para cada caso, acrescente uma linha na tabela Aprendizado com data, evidência, proposta em uma linha e status proposto. Não marque nada como aprovado e não altere o AGENTS.md nem o CLAUDE.md. No fim, liste as linhas que você acrescentou.
proposto. A seção ## Lessons do AGENTS.md continua igual.Na tabela Aprendizado de runtime/POLITICA.md, mude para aprovado a linha <data e proposta> e para recusado a linha <data e proposta>. Copie só a proposta aprovada, em uma linha, para ## Lessons do AGENTS.md.
O agente lê e propõe
Primeiro pedido. Ele cruza FALHAS, LIMITES e as propostas antigas.
Você lê cada linha
Pergunta-chave: esta regra afrouxa algum teto da POLITICA? Se afrouxa, recuse.
Você aprova ou recusa
Segundo pedido, com as suas palavras. Só o aprovado vai para as Lessons.
Git guarda a mudança
Como tudo é arquivo de texto, cada regra nova fica no histórico, com data. Dá para ver quando e por que entrou.
Teste rápido (opcional): na revisão, o agente propôs "pode enviar lembrete aos pacientes sem perguntar". O que a Clara faz?
um horário fixo
só propostas
a sua decisão
histórico das regras
🎓 Resumo do módulo
Próximo módulo:
4.3 — Guarda e painel