🎚️ Controle a profundidade + defina limites

O guia prático de uso do Fable 5 como agente de trabalho resume isso numa régua de quatro degraus. Cada degrau não é uma configuração técnica — é uma instrução que você mesmo escreve no prompt, dizendo ao agente o quanto vale a pena ele deliberar antes de te entregar a resposta.

A régua funciona melhor quando você pergunta antes de escrever o prompt: "se essa resposta sair errada, o que eu perco?" Quanto maior a resposta a essa pergunta, mais alto o degrau que você deveria pedir.

Fonte: guia prático do usuário sobre uso do Fable 5 como agente de trabalho — prompt testado na prática, não citação oficial da Anthropic.

A escada dos 4 níveis: cada degrau sobe em tempo de raciocínio (linha ciano tracejada) — máxima ganha destaque porque é o degrau que você deveria reservar pra quando o erro realmente custa caro.

Em vez de confiar que o agente vai adivinhar o nível certo sozinho, você diz explicitamente onde concentrar o raciocínio pesado — e onde não vale a pena. Isso evita o sintoma mais comum de deixar tudo em "alta o tempo todo": soluções mais complicadas do que a tarefa pedia.

O prompt abaixo faz exatamente isso — separa a parte que merece profundidade (a decisão estratégica) da parte que não merece (a implementação em si, que deve ficar simples).

Use análise profunda apenas na parte estratégica. Não complique a
solução. Não crie abstrações desnecessárias. Entregue a solução mais
simples que resolve bem o problema.

<isto você troca — cole junto o pedido real da tarefa>

Um modelo forte não é cauteloso por padrão — ele é capaz por padrão. Isso significa que, diante de um pedido ambíguo, o Fable 5 tende a preencher a lacuna sozinho: se você pediu pra "resolver o problema", ele pode decidir sozinho o que conta como resolver, e agir.

Isso é ótimo quando você quer que ele continue até o fim de uma tarefa clara. É perigoso quando a tarefa tem ambiguidade sobre o que ele pode tocar — arquivos, serviços, configuração, dados de produção.

A forma mais confiável de travar a fronteira do tópico anterior é colocar o agente num modo só-diagnóstico explícito: ele pode olhar, medir e concluir — mas não pode alterar nada até você aprovar.

Primeiro apenas avalie. Não altere arquivos, não reinicie serviços,
não crie branch, não edite configuração e não rode comandos
destrutivos.

Entregue um diagnóstico com evidências. Depois diga exatamente quais
mudanças recomenda e por quê.

<isto você troca — descreva o sistema ou problema a investigar>

O portão separa os dois caminhos: diagnóstico (ciano) é sempre permitido; execução real (vermelho) fica travada até você aprovar explicitamente as mudanças recomendadas.

As duas dicas deste módulo não competem entre si — elas se somam. O exemplo mais claro é uma auditoria de segurança: você quer profundidade alta (é uma decisão que custa caro se sair errada) e quer o agente travado em modo só-diagnóstico (porque não é a hora de mexer em nada ainda).

Na prática, isso vira um fluxo de 5 passos que você repete pra qualquer tarefa sensível — não só auditoria de segurança.

Faça uma auditoria de segurança completa <isto você troca — do
sistema/projeto>. Use análise profunda — é uma decisão que custa
caro se sair errada.

Mas, nesta rodada, apenas avalie: não altere arquivos, não reinicie
serviços, não edite configuração e não rode comandos destrutivos.

Entregue um diagnóstico com evidências, ranqueado por risco. Depois
diga exatamente quais mudanças recomenda e por quê — vou aprovar
cada uma antes de você agir.

Antes de fechar o módulo, um checklist rápido pra revisar os prompts que você acabou de aprender — profundidade calibrada (Dica 3) e limites explícitos antes de agir (Dica 4).