Você não gerencia um funcionário digitando instruções para ele, 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 rodar por horas sem você, criar seus próprios subagentes e terminar uma semana de trabalho acumulado durante a noite. Ele também custa dinheiro real por token, entrega além do esperado no momento em que você deixa o escopo aberto e vai defender uma resposta errada melhor do que a maioria dos humanos defende uma certa.
Sem gerenciamento, é uma forma cara de produzir bobagens cheias de confiança. Colocado sob contrato, é a coisa mais próxima de um funcionário 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 ao vivo em blockchain 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
Com o que você termina:
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 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 que vem depois:
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 trabalho 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 ativo (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 na 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. Isso é fraude.14- Nunca execute com esforço acima de "alto" dentro de um turno. "xhigh" é para revisões15 pontuais que você aciona 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 em vez disso.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 com mais 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 chain interaja diretamente -> precisa de uma pontuação de bom senso32 de 8 ou superior antes de ser enviada.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 encerrou com 0, ponto final38- "pequeno" = menos 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- Cada tarefa obtém uma linha 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 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 trabalho não significa nada sem uma verificação de antecedentes sobre o que eles podem tocar, e um gerente que aprova antes de qualquer coisa ser enviada. Dois arquivos.
ops/boundaries.md:
1## trabalha sozinho2rascunhar correções em um branch; atualizar shift-log.md; reiniciar uma instância de teste3*não produtiva*; sinalizar feeds de dados desatualizados45## precisa da minha assinatura6qualquer coisa em wallets/, .env*, config/rpc.json; qualquer diff com mais de 300 linhas;7qualquer alteração em um processo pm2 ativo; 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 pede 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 uma vez manualmente antes de qualquer outra coisa neste sistema entrar em produção. Se não passar limpo na sua configuração atual, essa é a primeira tarefa real. Tudo a jusante assume que este script diz 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 rápido, 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 para 100% das decisões de julgamento.
Então o turno tem quatro contratados, não um:
- Um modelo quase gratuito lê os logs noturnos e a saída do pm2. Diz "quieto" ou "acionável". Só isso.
- Fable 5, somente leitura, decide a única coisa de maior valor para fazer e escreve uma ordem de serviço. Ele 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 passa ou falha.
O script determinístico da Seção 2 dá o voto de desempate. Toda vez.
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. INTAKE, 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 quieto"; exit 0; }1213# 2. DISPATCH, 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 "rerouted, 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. EXECUTAR, 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. REVISAR, Fable novo, especificação e diff apenas, 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 "PASSOU, 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, não importa o quão bom fosse seu portfólio.
personnel/trust.tsv rastreia cada trabalho recorrente pelo nome: execuções, aprovações, nível atual.
- watch: menos de 10 execuções, ou menos de 90% de taxa de aprovação. Apenas rascunhos, sem exceções.
- probation: 10-19 execuções com 90%+. Enfileirado para sua assinatura, toda vez.
- cleared: 20+ execuções com 95%+. Envia sem você.
Um erro em uma tarefa "cleared" não recebe um aviso. Cai diretamente de volta para "probation" e imprime em stderr, que seu cron envia para você por e-mail. O rebaixamento automático é o único tipo que realmente se mantém.
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 playbooks originais pulam, e é a que realmente importa quando o sistema está ativo em infraestrutura que movimenta dinheiro real. Todo sistema de agente eventualmente faz algo que você não queria. A questão é se você descobre através de um log limpo ou de uma carteira vazia.
ops/incidents/runbook.md:
1| sinal | significado | faça isto2|----------------------------------|---------------------------------------|--------3| exit 2 (rerouted) | um modelo diferente atendeu à solicitação | jogue a saída fora, nunca construa sobre ela, tente novamente amanhã4| stop_reason: refusal | classificador de segurança recusou, HTTP 200 | não é um erro, verifique o log; se uma tarefa recusa 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 que foi concluído deixou de ser verdadeiro | verifique a data de última verificação, faça diff do 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 inflou8| uma tarefa toca wallets/.env/rpc | tentativa de violação de limite | parada brusca, isso nunca deve disparar se boundaries.md for respeitado, trate qualquer ocorrência como um bug no próprio sistema
Registre cada um deles 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 log 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. Extraia 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 pode escrever uma.
Cronograma de Experiência
Três marcos, não trinta dias de babá:
Marco 1. Execute o turno manualmente diariamente por uma semana. Leia cada linha. Graduado quando três turnos consecutivos rotearem exatamente como você teria feito.
Marco 2. O cron assume o turno. Você revisa a fila com um café em vez de executá-la você mesmo. Graduado quando dois trabalhos recorrentes ultrapassarem 20 execuções registradas.
Marco 3. Seu trabalho com melhor desempenho é enviado sem supervisão. Graduado quando ele completar uma semana inteira com zero intervenções suas.
As Regras, Comprimidas
- Um contrato é um número ou um nunca. Qualquer coisa mais suave é otimizada.
- O despachante decide. O trabalhador digita. Nenhum dos dois 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 em toda a empresa, e o rebaixamento é automático e barulhento.
- Uma tarefa concluída que não é re-verificada não está concluída, é um palpite com uma data.
- Os limites vivem em um arquivo que você pode ler em dez segundos, não na sua memória.
- O log de incidentes existe para que você encontre problemas a partir de um relatório, não de um saldo.
- Nunca construa sobre a saída de um modelo que você não solicitou.
- 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 trabalho real. É assim que isso se 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.
