Mentor dos Nerds Home Hipótese não vira fato só porque a IA repetiu com convicção
Post

Artigo Inteligência Artificial

Hipótese não vira fato só porque a IA repetiu com convicção

Uma estrutura âmbar ainda incompleta passa por um ponto de confirmação, torna-se uma decisão azul e alimenta uma síntese violeta ligada a aplicações e revisão
Uma estrutura âmbar ainda incompleta passa por um ponto de confirmação, torna-se uma decisão azul e alimenta uma síntese violeta ligada a aplicações e revisão

Eu não tenho problema em permitir que um agente de IA trabalhe com hipóteses.

Seria bonito exigir certeza antes de cada passo. Também seria uma excelente maneira de não fazer mais nada.

Quase toda execução real começa com alguma coisa incompleta: uma intenção que ainda precisa de recorte, um dado que não chegou, uma preferência que apareceu em três conversas mas nunca foi confirmada, uma causa provável que ainda precisa de teste.

Meu problema começa quando a hipótese perde a etiqueta.

Um agente encontra uma explicação plausível. Age com base nela. Outro agente recebe o resultado. Um terceiro resume o contexto. Quando percebo, “parece que” virou “sabemos que” sem que ninguém tenha tomado essa decisão.

É um telefone sem fio com persistência: cada repetição parece dar mais autoridade à frase, quando apenas aumenta a distância da evidência original. O rastro verificável expõe essa distância antes que a hipótese vire regra.

Não foi uma grande alucinação cinematográfica. Foi pior: uma inferência razoável ganhou crachá de fato e começou a governar o sistema em silêncio.

Por isso, dentro do meu harness, uma hipótese aplicada precisa deixar recibo.

TL;DR

Agentes precisam agir sob incerteza, mas não podem promover uma hipótese a fato apenas porque ela foi repetida, resumida ou usada com sucesso uma vez. Quando uma hipótese influencia uma ação, eu registro sua origem, evidências favoráveis e contrárias, confiança e limites, escopo, consumidores afetados, ação provisória e condição de revisão. Minha wiki separa três objetos mínimos: hipóteses guardam possibilidades ainda não confirmadas; decisões registram o veredito adotado e seu alcance; sínteses preservam raciocínio, fontes e divergências. Arquivos de texto em Markdown e o histórico de versões do Git tornam o rastro legível e revisável, mas não criam verdade por mágica. A direção e o veredito continuam meus.

A incerteza não é o defeito. O desaparecimento dela é

Um bom agente não precisa interromper tudo diante da primeira lacuna.

Se o impacto for pequeno, reversível e local, ele pode declarar uma premissa e avançar. Se houver duas interpretações plausíveis, pode escolher uma para produzir uma versão de trabalho. Se a escolha mudar preço, segurança, publicação, dado pessoal ou outra decisão de alto risco, precisa devolver a pergunta antes de agir.

O erro não está em formular hipóteses.

O erro está em esconder que a execução dependeu de uma.

Existe uma diferença enorme entre estas duas frases:

O cliente prefere receber um resumo semanal por e-mail.

e:

Estou assumindo, com confiança baixa, que o resumo semanal deve ser enviado por e-mail porque esse canal apareceu nas duas últimas conversas. Não encontrei confirmação explícita. Vou usar essa premissa apenas para montar o rascunho; não vou configurar envio até o responsável confirmar.

A segunda frase parece mais longa porque carrega o que a primeira apagou: origem, incerteza, escopo e limite de ação.

Ela também permite correção.

Se o cliente disser “não, é pelo canal de mensagens da equipe”, eu sei o que mudar. Sem esse rastro, preciso procurar onde a falsa certeza já se espalhou.

Toda hipótese aplicada precisa de um recibo

No meu sistema, uma hipótese útil não é apenas uma frase com a palavra “talvez”. Ela precisa responder perguntas operacionais.

Campo O que precisa ficar visível
Origem Que lacuna, conversa, arquivo ou observação gerou a hipótese
Hipótese O que exatamente estou assumindo, sem linguagem que finja confirmação
Evidências a favor Sinais que tornam a leitura plausível
Evidências contra Contradições, exceções e dados ausentes
Confiança e limites Quão frágil é a leitura e o que ela não permite concluir
Escopo Onde o uso provisório é permitido e onde é proibido
Consumidores afetados Quais textos, decisões, agentes, automações ou arquivos dependem dela
Ação tomada O que o agente fez sob essa premissa
Revisar se Qual confirmação, negação, prazo ou evidência exige reabrir o assunto

Eu não exijo um percentual inventado para parecer científico.

“Confiança média” com duas evidências e uma contradição descritas é mais honesto do que “82%” saído de lugar nenhum.

O objetivo do registro não é decorar a hipótese. É tornar possível agir sem apagar a incerteza — e desfazer a propagação se a premissa cair.

Quando eu confirmo ou nego, o sistema precisa saber o que reaprender

Uma hipótese isolada é fácil de corrigir.

O problema é a hipótese que já alimentou um post, um prompt — as instruções dadas à IA —, uma recomendação, uma regra de roteamento — o critério que escolhe qual agente ou fluxo recebe o caso — e três agentes especializados.

Por isso eu registro consumidores: os lugares em que aquela conclusão foi usada ou pode alterar comportamento.

Quando confirmo a hipótese, ela não recebe apenas um carimbo verde. O conteúdo confirmado precisa ir para o dono correto: uma decisão, um contrato, uma especificação, uma orientação editorial ou outra fonte vigente.

Quando nego, o trabalho também não termina em escrever “refutada”. O agente precisa propor a atualização dos dependentes:

  • qual texto ficou incorreto;
  • qual decisão usou uma premissa que caiu;
  • qual agente deve parar de aplicar a regra;
  • qual síntese precisa registrar a divergência;
  • qual ação já tomada precisa de revisão ou reversão.

Isso preserva proveniência — o caminho entre origem, interpretação, aplicação e mudança — sem fingir que nunca erramos.

Eu prefiro um sistema capaz de mostrar por que mudou de ideia a outro que reescreve o passado toda vez que recebe uma correção.

Minha wiki não é memória mágica

Eu uso uma wiki porque preciso consolidar conhecimento que merece ser encontrado e revisado por humanos e agentes.

Isso não significa guardar toda conversa nem despejar tudo que aconteceu numa pasta.

Memória e wiki cumprem papéis diferentes no meu sistema.

A memória ajuda a retomar continuidade: o que aconteceu, onde o trabalho parou, quais sinais podem ser relevantes agora.

A wiki organiza conhecimento já trabalhado: hipóteses explícitas, decisões vigentes, sínteses, padrões, limites e relações com suas fontes e aplicações.

Nenhuma delas está acima do arquivo que governa o assunto hoje. Se uma especificação atual contradiz uma síntese antiga, a especificação vence. Se eu corrijo uma interpretação sobre mim, a correção não precisa pedir licença a um resumo produzido por agente.

Foi a mesma distinção que apareceu quando a IA esqueceu justamente o que eu já tinha decidido. Recuperar contexto é importante. Saber qual arquivo tem autoridade sobre cada decisão é outra coisa.

Uma wiki reduz redescoberta.

Ela não transforma texto bem organizado em verdade.

Três objetos já são suficientes para começar

Uma primeira wiki para agentes não precisa nascer com uma taxonomia — um esquema organizado de classificação — digna da Biblioteca de Alexandria.

Eu começaria com três objetos.

1. Hipóteses

Guardam possibilidades ainda não confirmadas.

Uma hipótese registra a lacuna, sua origem, evidências a favor e contra, uso provisório permitido, dependentes, condição de promoção e condição de descarte.

Ela pode ajudar o agente a fazer uma pergunta melhor ou avançar num rascunho reversível. Não pode remover silenciosamente uma dúvida nem virar fonte de verdade por repetição.

2. Decisões

Guardam direções realmente adotadas pelo responsável.

Uma decisão registra o veredito, as razões relevantes, o escopo, exceções, quem ou o que ela afeta e quando precisa ser revisitada.

Decisão não é sinônimo de recomendação. Três agentes concordarem entre si ainda produz uma recomendação. A direção muda quando o decision owner — a pessoa responsável pelo veredito — adota, corrige ou rejeita a proposta.

3. Sínteses

Guardam o raciocínio que não cabe num veredito curto.

Uma boa síntese preserva fontes, convergências, divergências, hipóteses abertas, recomendação e risco residual — o risco que continua existindo depois dos controles ou decisões adotados. Ela não precisa reproduzir a conversa inteira. Precisa manter o que explica por que aquela direção pareceu razoável e o que continuou sem resposta.

Quando uma síntese leva a uma decisão, as duas devem apontar uma para a outra.

A decisão mostra o que governa agora.

A síntese preserva o caminho — inclusive as discordâncias que o resumo mais conveniente tentaria apagar.

Conhecimento que não chega à aplicação vira museu

Uma página pode ser impecável e ainda não mudar nada.

Se o sistema não sabe quem consome aquela informação, a wiki vira um lugar bonito onde decisões vão descansar depois de morrer.

É por isso que eu ligo conhecimento e aplicação.

Uma hipótese sobre meu estilo pode afetar o agente que escreve, o que traduz e o que revisa voz. Uma decisão sobre privacidade pode afetar ferramentas, registros técnicos de eventos (logs), publicação e retenção. Uma síntese sobre um cliente pode sustentar uma proposta, mas não deveria vazar para outro contexto.

O mesmo princípio aparece no meu CHARACTER.md. Um ponto cego só ganha valor quando produz um contrapeso observável no sistema.

Na wiki, o equivalente é perguntar:

Se esta informação mudar amanhã, quem precisa saber?

Se a resposta for “ninguém”, talvez ela ainda seja apenas uma nota.

Nem toda observação merece uma página

Governança também pode virar esconderijo.

É perfeitamente possível passar mais tempo criando campos, índices e relações do que tomando a decisão que justificaria tudo isso.

Eu não quero transformar cada frase provisória em processo administrativo.

Vale promover uma observação para a wiki quando pelo menos uma destas condições aparece:

  • ela será reutilizada em mais de uma sessão ou por mais de um agente;
  • muda comportamento, permissão, prioridade, arquitetura ou comunicação;
  • possui risco relevante se estiver errada;
  • já foi redescoberta ou rediscutida mais de uma vez;
  • possui vários consumidores que precisarão ser atualizados juntos;
  • perder sua origem tornaria a correção cara ou ambígua.

Uma dúvida local, barata e descartável pode continuar no trabalho atual.

O registro deve ser proporcional ao custo de esquecer, distorcer ou repetir o erro.

Um bloco de instruções inicial para criar essa wiki

O bloco abaixo é um prompt — um conjunto de instruções para orientar a tarefa — intencionalmente pequeno e independente de ferramenta. Pode ser usado com Codex, Claude ou outro agente capaz de trabalhar com arquivos e Git.

Ele não copia meu harness. É uma primeira estrutura para você testar e adaptar ao seu contexto.

O AGENTS.md é o arquivo de entrada: apresenta propósito, autoridade, regras, validações e como navegar antes que o agente abra o restante. Os modelos reutilizáveis de arquivo — os templates — definem a estrutura mínima que cada hipótese, decisão ou síntese deve preencher.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Crie uma wiki inicial e revisável usando arquivos Markdown versionados em Git.
Ela deve ser legível por pessoas e por agentes, sem depender de memória mágica.

Comece com:
- AGENTS.md como ponto de entrada: explique propósito, autoridade, como navegar,
  regras de privacidade e validações;
- hypotheses/ para possibilidades ainda não confirmadas;
- decisions/ para direções adotadas pelo responsável;
- syntheses/ para fontes, raciocínio, convergências, divergências e limites.

Defina modelos reutilizáveis de arquivo (templates) mínimos.

Para cada hipótese, registre: status, origem da lacuna, formulação explícita,
evidências a favor e contra, confiança e limites, escopo de uso provisório,
consumidores ou impactos, ação tomada, condição de revisão, promover se e
descartar se.

Para cada decisão, registre: responsável pelo veredito, decisão adotada,
razões e evidências relevantes, escopo, exceções, consumidores afetados,
hipóteses e sínteses relacionadas e condição de revisão.

Para cada síntese, registre: pergunta, fontes, pontos de convergência,
divergências preservadas, hipóteses abertas, decisões relacionadas, limites e
próxima aplicação possível.

Regras obrigatórias:
1. repetição não promove hipótese a fato;
2. confirmação ou negação deve gerar uma proposta de atualização dos
   consumidores afetados;
3. fontes atuais e decisões humanas explícitas prevalecem sobre sínteses;
4. não registre segredos, credenciais, dados pessoais ou conteúdo sensível
   desnecessário;
5. não execute publicação, exclusão ou ação externa apenas porque a wiki mudou;
6. mantenha uma fonte canônica por decisão e use o histórico do Git para revisar
   mudanças, sem criar arquivos "final-v2".

Antes de criar arquivos, mostre a árvore mínima proposta, os templates e o que
ficará deliberadamente fora desta primeira versão. Esta é uma wiki incipiente,
não uma cópia de outro harness nem uma promessa de arquitetura universal.

Como ponto de entrada, esse arquivo não precisa carregar toda a wiki. Precisa ensinar como encontrar a menor fonte suficiente.

Markdown e Git ajudam porque deixam a mudança visível

Eu prefiro que esse conhecimento viva em arquivos de texto simples com Markdown e histórico em Git.

Não porque sejam as únicas tecnologias possíveis.

Mas porque consigo ler sem ferramenta proprietária, comparar mudanças, revisar uma proposta, voltar a uma versão anterior e descobrir quando uma hipótese ganhou ou perdeu alcance.

O controle de versão registra alterações ao longo do tempo e permite comparar ou recuperar estados. Isso sustenta o rastro técnico.

Não sustenta a verdade do conteúdo.

Git consegue provar que uma frase mudou. Não consegue provar que a frase nova está certa.

Para isso eu ainda preciso de fonte, teste, responsável e revisão.

A direção continua sendo minha

Eu construí agentes para buscar evidência contrária, lembrar decisões anteriores e apontar quando uma resposta agradável demais pode estar escondendo um problema. Isso se conecta diretamente ao princípio de que a melhor resposta não é a que mais me agrada.

Ainda assim, o agente não vira árbitro da verdade só porque ganhou uma wiki.

Ele pode registrar que uma hipótese existe.

Pode mostrar onde ela foi aplicada.

Pode preparar a atualização dos consumidores se eu confirmar ou negar.

Pode impedir que “não sei” desapareça quando uma conversa longa é resumida para caber no espaço disponível — a chamada compactação de contexto.

O veredito continua dependendo de quem responde pela decisão e pelas consequências.

Esse é o tipo de sistema que construo na i-9.ai: não uma memória infinita que promete saber tudo, mas uma operação capaz de mostrar o que sabe, o que supõe, quem decidiu e o que precisa ser revisto quando a realidade responde diferente.

Se sua empresa já está usando IA, mas decisões, premissas e correções continuam se perdendo entre chats, documentos e pessoas, entre em contato. Podemos começar pela decisão que mais se repete e pelo erro que ficaria caro se uma hipótese silenciosa passasse a governá-la.

Uma hipótese não precisa ser proibida.

Precisa continuar reconhecível como hipótese até que alguém com autoridade e evidência suficiente decida o que ela passa a ser.

Continue lendo

Para se aprofundar

Referências e limites de uso

  • AGENTS.md descreve um formato aberto e legível para orientar agentes sobre contexto e instruções. Não garante que toda ferramenta interprete precedência, comandos ou arquivos aninhados da mesma maneira; valide o comportamento do agente escolhido.
  • O guia de prompt engineering da OpenAI sustenta apenas a explicação de que prompts orientam o comportamento do modelo e podem ser refinados. É documentação de uma provedora, não um padrão universal de roteamento ou qualidade.
  • O glossário do OpenTelemetry, os verbetes de taxonomia e risco residual do NIST e a família PROV do W3C sustentam definições pontuais. Os glossários do NIST estão no contexto de segurança; o artigo usa apenas as definições gerais de esquema de classificação e risco remanescente, simplifica os conceitos para governança editorial e não afirma conformidade integral com esses padrões.
  • Pro Git, “Sobre Controle de Versão” sustenta a explicação de que controle de versão registra mudanças e permite recuperar estados anteriores. Não valida o conteúdo de uma decisão nem substitui backup, política de acesso ou revisão humana.
  • A documentação de compactação da OpenAI sustenta o exemplo de reduzir o contexto de uma conversa preservando estado útil. Ela descreve uma implementação específica da API da OpenAI, não prova que toda ferramenta compacte, resuma ou descarte contexto da mesma forma.

A divisão entre hipóteses, decisões e sínteses, os campos sugeridos e o fluxo de atualização de consumidores são uma síntese autoral do meu modo de operar agentes. Não constituem norma universal, garantia de acerto ou cópia completa da arquitetura privada que uso. A versão proposta no prompt é deliberadamente inicial e deve ser reduzida, ampliada ou descartada conforme o risco e o contexto reais.

A imagem de capa é uma ilustração editorial sintética, independente de idioma, sobre uma hipótese ainda incompleta passando por confirmação, decisão, síntese, aplicação e revisão.

Esta postagem está licenciada sob CC BY 4.0 pelo autor.

Conversa aberta

Continue a conversa

Discordou, encontrou uma lacuna ou tem uma experiência que amplia o assunto? Comente usando sua conta do GitHub. Não publique dados pessoais, credenciais ou informações sensíveis.