Você não gerencia um funcionário digitando instruções uma mensagem de cada vez. Você dá a ele um contrato, um período de experiência e uma forma de medir se ele ainda vale o salário. O Fable 5 merece o mesmo tratamento.
Aqui está o problema. O Fable 5 pode funcionar por horas sem você, criar seus próprios subagentes e terminar uma semana de backlog da noite para o dia. Também custa dinheiro real por token, entrega além do esperado no momento em que você deixa o escopo aberto e defende uma resposta errada melhor do que a maioria dos humanos defende uma certa.
Sem gerenciamento, é uma maneira cara de produzir besteiras com confiança. Colocado em um contrato, é a coisa mais próxima de uma contratação em tempo integral que você pode executar por alguns dólares por dia.
Este é esse contrato. Não a teoria dele. Os arquivos reais, na ordem em que você os escreve, construídos em torno de uma implantação real: os bots de monitoramento que já executo em um VPS em Paris via pm2. Fluxos de autenticação e tabelas de faturamento não são minha superfície de ataque. Chaves RPC, endereços de carteira e transações de blockchain ao vivo são. O sistema abaixo é construído para isso, não para um repositório SaaS genérico.
Cinco seções. Cada uma entrega um arquivo. Tempo total de configuração: menos de duas horas.
A Configuração
1claude CLI (Claude Code) com acesso ao Fable 5 # créditos de uso, com limite2llm CLI + chave OpenRouter # para os modelos baratos3jq, git, pm2, cron4um VPS com os bots já em execução
O que você obtém ao final:
1agent-contract/2 CONTRACT.md # Seção 1: os termos de emprego3 ops/4 shift.sh # Seção 3: o turno diário5 dispatcher.md # prompt de roteamento, apenas Fable6 intake.md # leitor barato, lê logs primeiro7 worker.md # modelo barato, faz a digitação8 reviewer.md # Fable novo, verifica o trabalho9 boundaries.md # Seção 2: o que ele pode e não pode tocar10 guardrails/signoff.sh # Seção 2: o sim/não determinístico11 personnel/12 trust.tsv # Seção 4: quem ganhou autonomia13 standing-checks/ # Seção 4: coisas que devem permanecer verdadeiras14 incidents/15 log.tsv # Seção 5: o que quebrou e quando16 runbook.md # Seção 5: o que fazer a respeito17 Makefile
Uma regra citável antes de começarmos, porque define o tom para tudo depois dela:
Um agente que corrige a própria lição de casa é um agente que se dá um aumento.
Nada neste sistema verifica o próprio trabalho. Nem uma vez.
Seção 1: O Contrato (CONTRACT.md)
Um contrato de funcionário não é uma lista de sugestões. São números, limites rígidos e cláusulas que são aplicadas independentemente de o funcionário concordar ou não com elas. Escreva este arquivo da mesma forma. Sem "por favor" ou "tente". Um modelo otimiza em torno de linguagem suave da mesma forma que um estagiário otimiza em torno de um gerente que nunca verifica.
1# CONTRACT.md23## LIMITES RÍGIDOS (sem exceções, sem perguntar duas vezes)4- Nunca toque em chaves de carteira, arquivos .env ou credenciais RPC sem aprovação.5- Nunca envie uma alteração para um processo de bot ao vivo (pm2 restart) sem uma aprovação aprovada.6- Nunca exceda 150 linhas alteradas em um único commit sem perguntar primeiro.7- Nunca afirme que uma tarefa está concluída com base em sua própria leitura da saída.8 Concluído significa que o script de aprovação retornou 0. Nada mais conta.9- Nunca invente um endpoint de API, um endereço de contrato ou um valor de configuração.10 Se não estiver no repositório, pare e pergunte.11- Nunca adicione uma nova dependência. Escreva em ops/shift-log.md e pare por aí.12- Nunca edite ou exclua um teste, limite de alerta ou condição de monitor para fazer13 algo passar. Isso não é uma correção. É fraude.14- Nunca execute com esforço acima de "alto" dentro de um turno. "xhigh" é para revisões15 únicas que você dispara manualmente, nunca para o loop automatizado.16- Nunca narre ou explique seu raciocínio interno em uma resposta. Parece17 útil. No Fable 5, pode acionar um classificador de recusa.1819## ROTEAMENTO DE TRABALHO (quem faz o quê, o contratado mais barato e capaz vence)20| modelo | custo por tarefa | ambição | julgamento | bom senso |21|------------------|---------------|----------|----------|-------|22| claude-fable-5 | alto | baixo | 10 | 10 |23| claude-opus-4-8 | médio | médio | 8 | 9 |24| claude-sonnet-5 | baixo | alto | 7 | 7 |25| trabalhador OSS barato | mais baixo | mais alto | 5 | 4 |26271. Decidir o que fazer a seguir, revisar um diff, desempatar -> Fable 5,28 somente leitura, esforço alto.292. Ler logs brutos, dumps ou qualquer coisa acima de 50k tokens -> o trabalhador barato.30 Nunca Fable. Isso é pagar a taxa de um diretor para ler uma planilha.313. Qualquer coisa com a qual um usuário ou uma blockchain interaja diretamente -> precisa de uma pontuação de bom senso32 de 8 ou superior antes de ser enviado.334. Todo o resto -> sonnet-5, esforço médio, suba um nível em caso de erro.3435## DEFINIÇÕES36- "julgamento" = pode lidar com a coisa mais difícil na mesa sem supervisão37- "concluído" = o script de aprovação saiu com 0, ponto final38- "pequeno" = abaixo de 50 linhas alteradas39- "limpeza" = o comportamento é idêntico bit a bit, aprovação verde antes e depois4041## A ÚNICA DEFINIÇÃO DE CONCLUÍDO QUE IMPORTA42- Toda tarefa recebe um ponto de chegada verificável por máquina antes do início do trabalho.43- Um revisor que não viu nem o plano nem o rascunho o verifica.44- guardrails/signoff.sh tem o voto final. Não o revisor. O script.45- Se o trabalhador e o revisor discordarem duas vezes seguidas, vai para um humano.46 Sem terceira opinião, sem modelo de desempate.
Substitua pelos seus próprios números. Qualquer coisa que você deixaria passar 80% das vezes e ainda chamaria de "concluído" precisa de um número ou de um "nunca" anexado a ela, ou corte-a.
Seção 2: Limites e a Aprovação
Um contrato de funcionário não significa nada sem uma verificação de antecedentes sobre o que eles podem tocar, e um gerente que aprova antes que qualquer coisa seja enviada. Dois arquivos.
ops/boundaries.md:
1## trabalha sozinho2rascunhar correções em um branch; atualizar shift-log.md; reiniciar uma instância3de teste *não produtiva*; sinalizar feeds de dados obsoletos45## precisa da minha assinatura6qualquer coisa em wallets/, .env*, config/rpc.json; qualquer diff acima de 300 linhas;7qualquer alteração em um processo pm2 ao vivo; qualquer coisa que envie uma transação89## me acorda imediatamente10o revisor falha na mesma correção duas vezes; o roteador serviu um modelo diferente11do solicitado; o gasto diário ultrapassou o limite; uma verificação permanente fica vermelha;12qualquer coisa que peça uma chave privada
ops/guardrails/signoff.sh (edite os comandos para corresponder aos seus bots):
1#!/usr/bin/env bash2set -e3npm run typecheck --if-present4npm test --if-present5pm2 describe "$BOT_NAME" | grep -q "status.*online" || exit 1
Execute-o manualmente uma vez antes de qualquer outra coisa neste sistema entrar em operação. Se não passar limpo na sua configuração atual, essa é a primeira tarefa real. Tudo abaixo depende que este script diga a verdade.
Seção 3: O Turno
Aqui está a matemática que faz ou quebra isso. Uma sessão completa com o Fable 5 fazendo a digitação custa dinheiro real rapidamente, quatro dígitos se você deixar escrever por horas. O Fable 5 tomando as decisões enquanto um modelo barato faz a digitação é uma conta totalmente diferente, aproximadamente 15-20% dos tokens por 100% das decisões de julgamento.
Então, o turno tem quatro contratados, não um:
- Um modelo quase gratuito lê os logs da noite e a saída do pm2. Diz "quieto" ou "acionável". Só isso.
- Fable 5, somente leitura, decide a única coisa de maior valor a fazer e escreve uma ordem de serviço. Não toca no código.
- Um modelo de trabalhador barato executa a ordem de serviço em um branch isolado.
- Uma instância nova do Fable 5, vendo apenas a especificação e o diff, vota aprovação ou reprovação.
O script determinístico na Seção 2 dá o voto de desempate. Todas as vezes.
ops/shift.sh:
1#!/usr/bin/env bash2set -euo pipefail3cd "$(dirname "$0")"4DAILY_BUDGET="${DAILY_BUDGET_USD:-5}"5INTAKE_MODEL="${INTAKE_MODEL:-openrouter/deepseek/deepseek-v4-flash}"6WORKER_MODEL="${WORKER_MODEL:-openrouter/moonshotai/kimi-k2.6}"78# 1. LEITURA, centavos9pm2 logs --lines 100 --nostream | llm -m "$INTAKE_MODEL" -s "$(cat intake.md)" \10 >> shift-log.md11grep -q "status: actionable" shift-log.md || { echo "turno silencioso"; exit 0; }1213# 2. DESPACHO, Fable, xhigh, somente leitura, decide e para14claude -p "$(cat dispatcher.md)15LOG: $(cat shift-log.md)16TRUST: $(cat personnel/trust.tsv)17BOUNDARIES: $(cat boundaries.md)" \18 --model claude-fable-5 --effort xhigh --allowedTools "Read" \19 --output-format json > /tmp/order.json2021SERVED=$(jq -r '.modelUsage | keys[0] // "claude-fable-5"' /tmp/order.json)22[[ "$SERVED" != *fable* ]] && { echo "redirecionado, descartar esta execução" >> shift-log.md; exit 2; }2324jq -r '.result' /tmp/order.json > work-order.json25ACTION=$(jq -r .action work-order.json)26[[ "$ACTION" == "stop" ]] && exit 027[[ "$ACTION" == "queue" ]] && { echo "enfileirado para assinatura" >> shift-log.md; exit 0; }2829# 3. EXECUÇÃO, trabalhador barato, branch isolado30BR="shift-$(date +%s)"31git worktree add "../$BR" -b "$BR" >/dev/null32( cd "../$BR" && llm -m "$WORKER_MODEL" -s "$(cat "$OLDPWD/worker.md")" \33 "$(cat "$OLDPWD/work-order.json")" > shift-notes.md )3435# 4. REVISÃO, Fable novo, apenas especificação e diff, nada mais36VERDICT=$(claude -p "$(cat reviewer.md)37SPEC: $(jq -r .spec work-order.json)38DIFF: $(cd "../$BR" && git diff)" \39 --model claude-fable-5 --effort high --allowedTools "" \40 --output-format json | jq -r .result)4142# 5. O ÚNICO VOTO QUE ENVIA QUALQUER COISA43if [[ "$VERDICT" == PASS* ]] && ( cd "../$BR" && "$OLDPWD/guardrails/signoff.sh" ); then44 echo "APROVADO, enviado ou enfileirado conforme nível de confiança" >> shift-log.md45else46 echo "FALHOU: $BR retido para revisão" >> shift-log.md47fi
Uma decisão tomada pelo Fable e uma linha de código digitada pelo Fable são duas etiquetas de preço diferentes. Pague apenas a mais alta pela decisão.
Seção 4: O Arquivo Pessoal
Confiança não é uma configuração de toda a empresa. É conquistada por tarefa, da mesma forma que você não entregaria as chaves de produção a um novo contratado no primeiro dia, por mais bom que fosse o portfólio dele.
personnel/trust.tsv rastreia cada trabalho recorrente pelo nome: execuções, aprovações, nível atual.
- watch: menos de 10 execuções, ou taxa de aprovação abaixo de 90%. Apenas rascunhos, sem exceções.
- probation: 10-19 execuções com 90%+ de aprovação. Enfileirado para sua assinatura, todas as vezes.
- cleared: 20+ execuções com 95%+ de aprovação. Enviado sem você.
Um erro em uma tarefa liberada não recebe um aviso. Cai direto de volta para probation e imprime em stderr, que seu cron envia para você por e-mail. A rebaixamento automático é o único tipo que realmente se sustenta.
A segunda metade do arquivo pessoal é personnel/standing-checks/. Cada trabalho concluído se forma aqui como um comando que deve continuar retornando verdadeiro, para sempre, verificado uma vez por dia:
1# personnel/standing-checks/bankr-claim-monitor.md2predicate: pm2 describe bankr-claim-monitor | grep -q "status.*online" && \3 sqlite3 claims.db "select count(*) from claims where ts > strftime('%s','now','-1 day')" | grep -qv "^0$"4last-verified: 2026-07-085on-violation: me acorde, não reinicie automaticamente às cegas
Uma tarefa que você verificou apenas uma vez não está concluída. É uma suposição com um carimbo de data/hora.
Execute a verificação diariamente via cron. Um predicado com falha significa que algo que costumava ser verdadeiro deixou de ser verdadeiro, silenciosamente, e ninguém teria notado sem este arquivo.
Seção 5: O Relatório de Incidentes
Esta é a seção que os manuais originais pulam, e é a que realmente importa quando o sistema está ativo em uma infraestrutura que movimenta dinheiro real. Todo sistema agêntico eventualmente faz algo que você não queria. A questão é se você descobre por um log limpo ou por uma carteira vazia.
ops/incidents/runbook.md:
1| sinal | significado | faça isto2|----------------------------------|---------------------------------------|--------3| exit 2 (redirecionado) | um modelo diferente atendeu à solicitação | descarte a saída, nunca construa em cima dela, tente novamente amanhã4| stop_reason: refusal | classificador de segurança recusou, HTTP 200 | não é um erro, verifique o log; se uma tarefa recusar repetidamente, a tarefa provavelmente está tocando em algo que não deveria5| aprovação falha duas vezes, mesma correção | trabalhador e revisor não conseguem convergir | leve para uma revisão humana, não tente novamente uma terceira vez automaticamente6| verificação permanente fica vermelha | algo concluído deixou de ser verdadeiro | verifique a data da última verificação, veja o que foi enviado desde então, não reverta automaticamente7| gasto diário ultrapassa o limite | orçamento estourado | pare o turno, leia shift-log.md, descubra qual estágio inchou8| uma tarefa toca wallets/.env/rpc | tentativa de violação de limite | parada forçada, isso nunca deve disparar se boundaries.md for respeitado, trate qualquer ocorrência como um bug no próprio sistema
Registre cada um destes em incidents/log.tsv com um carimbo de data/hora, independentemente de você ter agido ou não. O objetivo não é zero incidentes. É zero incidentes sobre os quais você fica sabendo tarde demais.
Uma vez por semana, faça uma passagem de compostagem: leia o registro de incidentes, os rebaixamentos do arquivo de confiança e qualquer coisa que tenha permanecido enfileirada e não assinada por mais de 3 dias. Retire no máximo três propostas: um novo limite rígido para CONTRACT.md, uma correção em uma descrição de trabalho ou uma verificação permanente que estava faltando. Você aprova as três manualmente. O sistema pode propor sua própria próxima regra. Ele nunca consegue escrever uma.
Cronograma de Experiência
Três pontos de verificação, não trinta dias de babá:
Ponto de verificação 1. Execute o turno manualmente diariamente por uma semana. Leia cada linha. Forme-se quando três turnos consecutivos rotearem exatamente como você teria feito.
Ponto de verificação 2. O cron assume o turno. Você revisa a fila com um café em vez de executá-la você mesmo. Forme-se quando dois trabalhos recorrentes ultrapassarem 20 execuções registradas.
Ponto de verificação 3. Seu trabalho com melhor desempenho é enviado sem supervisão. Forme-se quando ele funcionar por uma semana inteira com zero intervenções suas.
As Regras, Comprimidas
- Um contrato é um número ou um nunca. Qualquer coisa mais suave é otimizada em torno.
- O despachante decide. O trabalhador digita. Nenhum deles verifica o próprio trabalho.
- O julgamento do Fable vale o preço. A digitação do Fable geralmente não vale.
- Confiança é por trabalho, não por toda a empresa, e o rebaixamento é automático e barulhento.
- Uma tarefa concluída que não é verificada novamente não está concluída, é um palpite com uma data.
- Limites vivem em um arquivo que você pode ler em dez segundos, não na sua memória.
- O registro de incidentes existe para que você encontre problemas a partir de um relatório, não de um saldo.
- Nunca construa em cima da saída de um modelo que você não pediu.
- Uma vez por semana, o sistema pode propor uma nova regra. Você ainda é quem a assina.
O modelo nunca foi a parte difícil. Construir algo em torno dele que permaneça honesto quando ninguém está olhando, esse é o verdadeiro trabalho. Isto é o que isso parece para uma frota de bots em vez de uma base de código.
Comece com guardrails/signoff.sh. Execute um turno manualmente. Escreva uma verificação permanente para o último bot que você enviou. Na primeira vez que ele pegar algo que você tinha certeza que estava bem, o resto disso deixa de ser opcional.
Siga @GipArcAI para mais dessas análises, e me encontre no X em https://x.com/gippp69.
