O que seu agente decide quando você não sabe

Fala, pessoal. Jonata aqui.

Essa semana eu voltei para uma frase que parece filosofia de parede, mas vira concreto armado quando você trabalha com agentes:

O mapa é o que eu entrego para o agente: prompt, skill, contexto, plano, exemplos, regra de pronto. O território é onde o trabalho acontece de verdade: cliente, código, deploy, edge case, timing, credencial, dado estranho, interface ruim, decisão ambígua.

Entre os dois mora o problema.

Quando o agente encontra algo que o mapa não cobriu, ele não para automaticamente. Ele decide.

Às vezes decide bem. Às vezes decide como um estagiário brilhante numa sala sem ninguém para perguntar. E o pior: muitas decisões parecem corretas porque vêm embaladas em texto organizado.

O artigo que me provocou essa semana chama isso de unknowns: os desconhecidos que aparecem antes, durante e depois da implementação. A tese é simples e meio desconfortável. Quanto melhor o modelo fica, mais a qualidade do trabalho depende da nossa capacidade de descobrir esses unknowns.

Prompt ajuda.

Julgamento decide.

O problema: você só escreve o que sabe escrever

Quando eu peço algo para um agente, existem quatro camadas no trabalho.

A primeira é fácil: os known knowns. Aquilo que está no prompt. “Crie o draft”, “use este arquivo”, “não publique”, “rode os testes”, “salve no Inbox”.

A segunda são os known unknowns. Eu sei que falta decidir. Exemplo: “a thumb ainda precisa de aprovação” ou “o cliente precisa validar esse gate”.

A terceira é onde começa a bagunça boa: os unknown knowns. Coisas que eu reconheceria se visse, mas não lembraria de escrever. Tom de voz. Um padrão antigo do projeto. Uma restrição comercial. Um jeito Olympus de não exagerar promessa pública.

A quarta é a perigosa: unknown unknowns. O buraco que você não sabia que existia.

Na Olympus, isso aparece toda semana. Um agente acha que terminou uma revisão, mas no meio do caminho encontra três classificadores diferentes para o mesmo erro de credencial.

Outro percebe que uma correção está no nível errado: parece resolver o caso de hoje, mas vira bandaid em cima da infraestrutura compartilhada. Um terceiro entrega artifact, mas o risco real é se aquilo persistiu onde precisava.

Nenhuma dessas coisas cabe perfeitamente no pedido inicial.

Elas aparecem quando o território responde.

E aí você descobre a pergunta que importa: quando o agente encontra um desconhecido, ele tem permissão para escolher ou precisa voltar com evidência?

O fundador vira cartógrafo de ambiguidade

O erro mais comum é tentar resolver unknowns escrevendo um prompt maior.

Funciona até certo ponto. Depois vira ansiedade em forma de texto. Você coloca mais regra, mais exceção, mais “faça isso, não faça aquilo”, e o agente começa a seguir instrução velha mesmo quando o território pede uma curva.

O oposto também falha. Se você é vago demais, o agente preenche os buracos com defaults de internet: arquitetura padrão, copy padrão, checklist padrão, design padrão, decisão padrão.

Só que empresa real não roda em defaults.

O trabalho do founder com IA está ficando menos parecido com escrever comandos e mais parecido com desenhar um mapa de ambiguidade. Não um mapa perfeito. Um mapa honesto.

Antes de delegar, eu deveria saber responder:

• O que já está decidido?

• O que eu ainda não decidi?

• O que eu só vou conseguir julgar vendo?

• O que pode quebrar porque nem sei que existe?

Essa última pergunta é a mais valiosa. Ela transforma o agente de executor obediente em parceiro de reconhecimento.

Esse é o blindspot pass do artigo. Você chega com humildade operacional: “estou entrando numa parte do código que não conheço”, “não sei avaliar color grading”, “não tenho repertório de UI para essa tela”, “não sei quais perguntas mudariam a arquitetura”.

Parece admitir fraqueza.

Na prática, é acelerar descoberta.

Unknowns aparecem em três momentos

O primeiro momento é antes da implementação.

É quando o barato é perguntar. Peça um blindspot pass. Faça um protótipo descartável. Peça quatro direções visuais para reagir. Mande o agente entrevistar você uma pergunta por vez, priorizando perguntas cuja resposta mudaria arquitetura. O objetivo é criar superfície para você reconhecer o que não sabia formular, sem terceirizar a decisão.

Se você só sabe julgar vendo, não finja que sabe especificar escrevendo.

O segundo momento é durante a implementação.

Todo plano encontra uma parede. Uma API responde diferente. Um componente antigo tem semântica própria. Um teste falha por motivo legítimo. Uma credencial está quebrada. Um edge case muda o escopo.

Aqui entra um hábito pequeno que eu quero usar mais: implementation-notes.md.

Pense nisso como caixa-preta do voo, não como relatório bonito. Cada vez que o agente desvia do plano, ele registra: o que encontrou, qual decisão conservadora tomou, o que precisa voltar para a próxima tentativa.

Isso tira o unknown da conversa e coloca no sistema.

O terceiro momento é depois da implementação.

Essa é a parte que founders pulam porque estão cansados. Você olha o diff, entende 40%, confia no resto e segue.

Só que um agente pode ter alterado 14 arquivos, encostado em fluxo antigo, criado uma regra nova, removido um fallback e mudado o comportamento de uma tela que você nem abriu. Ler diff ajuda, mas não prova entendimento.

Por isso gostei da ideia do quiz pós-implementação. O agente empacota o que fez, explica as decisões e te testa. Se você não consegue responder, talvez ainda não esteja pronto para merge, publish ou envio.

A maturidade aparece quando você sabe exatamente onde precisa voltar para decidir.

O que EU realmente penso

A cada modelo novo, a tentação é acreditar que o gargalo sumiu.

Ele não sumiu. Ele mudou de lugar.

Quando o modelo era fraco, o gargalo era output. A resposta vinha ruim, curta, torta, genérica. Você via o erro rápido.

Agora o gargalo é mais sutil. O output vem bom o suficiente para atravessar a primeira revisão. O texto flui. O código compila. O plano faz sentido. A interface parece ok.

Mas o território ainda cobra.

A pergunta deixa de ser “o agente consegue fazer?” e vira “ele sabe quais decisões ainda não deveria tomar sozinho?”.

É por isso que eu não quero usar unknowns como mais um framework bonitinho. Quero usar como atrito operacional. Antes de um trabalho importante, o agente deveria me devolver um mapa:

• decisões já fechadas;

• decisões que dependem de mim;

• critérios que eu provavelmente só vou reconhecer vendo;

• riscos que podem aparecer no território.

Isso serve para código, proposta, landing, newsletter, cliente, hiring, produto. Serve principalmente quando o trabalho parece claro demais.

Porque clareza demais no começo muitas vezes é só falta de contato com o terreno.

Sua missão para os próximos 7 dias

1. Escolha uma tarefa real que você vai delegar para IA. Não pegue uma brincadeira. Pegue algo que tenha consequência: proposta, feature, campanha, análise, relatório, newsletter, fluxo de onboarding.

2. Faça o inventário dos quatro unknowns antes do prompt final. Escreva: known knowns, known unknowns, unknown knowns e unknown unknowns prováveis. Se travar no último, peça um blindspot pass.

3. Exija rastro no meio e compreensão no fim. Durante o trabalho, peça implementation-notes.md ou equivalente. Depois, peça um resumo com quiz. Se você não entende o que mudou, ainda não é hora de publicar, mergear ou enviar.

Conteúdos recomendados

• A Field Guide to Fable: Finding Your Unknowns: thread original no X

• Know your unknowns — exemplos interativos: artifact gallery

• Anthropic — Effective context engineering for AI agents: artigo técnico

Forte abraço,

Equipe Olympus