Eu já tinha dito que os novos artigos seriam publicados antes do novo desenho visual do site, o redesign.

Depois de uma conversa longa, cheia de artigos, imagens, versões de código, validações e mudanças de prioridade, pedi que os textos fossem preparados para avaliação antes de publicar.

Neste projeto, essa avaliação acontece sobre uma versão candidata, separada do site publicado. Tecnicamente, ela é apresentada como um Pull Request (PR): uma proposta de mudança que pode ser lida, testada e comentada antes de entrar no ar.

A IA encontrou uma associação tecnicamente razoável: os arquivos tinham sido preparados na estrutura esperada pelo redesign. Então colocou tudo na mesma avaliação do redesign.

Só havia um problema.

Eu já tinha decidido o contrário.

TL;DR

Conversas longas com IA precisam ser compactadas, resumidas ou reconstruídas para continuar cabendo no contexto disponível. Isso é útil, mas um resumo não deve virar a fonte de verdade de uma operação. Nesta sessão, a relação técnica entre os arquivos e o redesign sobreviveu; a precedência editorial — publicar os artigos antes — não. A resposta não é simplesmente fornecer mais texto. É transformar decisões importantes em estado durável: contratos em AGENTS.md, plano, lista de verificação, versão candidata, critérios de aceite e uma ordem explícita de execução. A conversa serve para pensar. O sistema precisa saber o que não pode esquecer.

“Esqueceu” é uma figura de linguagem

Não estou dizendo que a máquina se distraiu, ficou cansada ou teve uma lembrança humana que desapareceu.

Um modelo recebe um conjunto limitado de informações para produzir a próxima resposta. Esse espaço é chamado de janela de contexto: a quantidade de conteúdo que pode participar daquela execução.

Quando a conversa cresce demais, o sistema precisa administrar esse volume. Pode selecionar partes, recuperar registros ou compactar o histórico.

A documentação oficial da OpenAI sobre compactação descreve um mecanismo da Responses API que reduz o volume de texto processado — medido em unidades chamadas tokens — preservando informações consideradas relevantes para continuar fluxos longos.

A própria documentação usa a expressão loss-aware compression: uma compressão consciente de possíveis perdas, não uma promessa de reprodução literal de cada frase.

Não estou afirmando que o aplicativo usado nesta sessão executou exatamente aquela implementação técnica. A referência sustenta o mecanismo geral e uma implementação oficial possível. O erro concreto desta história é observável sem essa extrapolação: eu dei uma ordem, ela não governou a decisão posterior, e precisei corrigi-la.

Compactar não é o problema

Sem alguma forma de compactação, uma sessão como esta terminaria muito antes.

Eu trouxe direcionamento editorial, fontes, identidade visual, infraestrutura, Cloudflare, comentários, analytics, multilíngue, áudio, SEO, artigos novos e correções nos artigos antigos.

Isso não é um prompt.

É uma operação.

Seria ingênuo esperar que toda frase permanecesse com o mesmo peso para sempre dentro de uma conversa crescente.

Compactar permite continuar. O problema começa quando o sistema trata a representação compactada como se fosse o registro canônico de tudo o que foi decidido.

Um resumo é um mapa.

Mapa bom ajuda a atravessar o território. Ainda assim, ele escolhe o que mostrar.

Nesta sessão, o mapa preservou que:

• existiam três novos artigos;
• eles tinham versões em três idiomas;
• os arquivos haviam sido criados numa versão de trabalho separada — a branch — do redesign;
• o usuário queria os textos em avaliação antes da publicação.

Mas enfraqueceu uma relação mais importante:

• os posts deveriam ser publicados antes do redesign e, portanto, não podiam depender dele.

A informação não sumiu por completo. Ela perdeu precedência.

Em operação, isso já é suficiente para produzir a decisão errada.

Mais contexto não substitui governança

Existe uma tentação de resolver qualquer falha de IA despejando ainda mais contexto.

Às vezes ajuda.

Mas contexto sem hierarquia também pode produzir uma massa maior de fatos, desejos, exemplos, correções e estados históricos competindo pela próxima ação.

O sistema precisa distinguir pelo menos:

• o que é uma ideia;
• o que é uma hipótese;
• o que foi decidido;
• o que foi substituído;
• o que está bloqueado;
• o que define a ordem de execução;
• qual arquivo ou serviço contém o estado atual.

Essa diferença não nasce automaticamente da quantidade de texto.

Ela precisa ser modelada.

Eu posso contar a mesma história dez vezes. Se o sistema não souber que uma frase é uma decisão vigente e outra é apenas contexto histórico, ele ganhou volume, não direção.

Conversa é memória de trabalho

Eu gosto de conversar com a IA pelo microfone porque consigo externalizar uma linha de raciocínio sem parar para transformar cada percepção em documento.

Essa fluidez é uma vantagem enorme.

Mas a conversa funciona melhor como memória de trabalho: um espaço transitório para elaborar, testar, corrigir e coordenar.

Ela não deveria ser o único lugar onde vive uma decisão que altera qual versão do projeto será modificada, quando algo será publicado, segurança, preço, escopo ou responsabilidade.

Quando algo se torna importante para a operação, precisa mudar de estado.

Pode virar:

• uma regra em AGENTS.md;
• um critério de aceite no processo de avaliação;
• uma tarefa ordenada num plano;
• uma decisão registrada no repositório;
• um campo estruturado num sistema;
• uma aprovação humana verificável;
• um vínculo explícito entre a versão de trabalho, o registro da alteração — o commit — e o ambiente onde ela será testada ou publicada.

É a diferença entre dizer algo durante uma reunião e atualizar o contrato que governa o trabalho depois dela.

Nesse sistema, o AGENTS.md costuma ser justamente a porta de entrada. Antes de agir, o agente lê esse arquivo para entender as regras iniciais e descobrir como navegar pelo restante do projeto. Ele pode apontar onde estão as fontes de verdade, quais ferramentas estão disponíveis, quais fluxos de trabalho devem ser seguidos, que validações são obrigatórias e em quais situações a decisão precisa voltar para uma pessoa. Não é uma memória mágica. É um contrato legível que reduz improviso e ajuda o agente a encontrar o contexto certo.

O harness começa onde o chat termina

Eu uso harness para descrever a estrutura que envolve o modelo e transforma capacidade geral em uma operação dirigida.

O modelo é uma parte.

O harness inclui instruções, ferramentas, memória, permissões, procedimentos reutilizáveis — as skills —, agentes especializados, validações, registros, pontos obrigatórios de verificação e caminhos de aprovação.

Uma decisão crítica não pode depender apenas de “a IA lembrar”.

O harness precisa oferecer uma forma de:

1. capturar a decisão;
2. identificar que ela está vigente;
3. relacioná-la ao trabalho que afeta;
4. detectar quando uma ação a contradiz;
5. devolver a divergência ao autor antes de executar.

No caso desta sessão, uma regra simples teria evitado o erro:

Os novos posts serão publicados antes do redesign. A avaliação editorial deve partir de main, a versão principal do site, e não pode depender da avaliação do novo layout.

Depois que essa regra existe num lugar durável e é relida antes da operação Git, ela deixa de competir como apenas mais uma frase no histórico.

Não adianta ter memória sem fonte de verdade

Também existe uma corrida para dar “memória infinita” aos agentes.

Memória ajuda, mas acumular registros não resolve sozinho qual deles governa o presente.

Um sistema pode recordar perfeitamente cinco versões incompatíveis de uma decisão.

Se não souber qual está vigente, ele apenas erra com excelente documentação.

Por isso eu me preocupo com fonte de verdade: o lugar reconhecido como autoridade para um tipo de estado.

No desenvolvimento de software, o controle de versão registra mudanças e permite relacionar conteúdo a commits e branches. Num processo empresarial, a fonte de verdade pode ser um ERP, CRM, contrato, banco de dados ou aprovação formal.

O formato muda. A pergunta permanece:

Quando duas lembranças discordam, quem decide qual vale?

O erro foi meu também — como projetista do sistema

Seria confortável escrever este texto dizendo apenas que a IA falhou.

Ela falhou.

Mas eu estou construindo justamente um sistema que deveria suportar uma conversa desse tamanho sem depender de eu repetir toda decisão importante.

Se a direção era crítica e continuou existindo somente como uma fala antiga, o harness ainda tinha uma lacuna.

Isso não transfere a direção para a máquina. A direção continua sendo minha.

Significa que o sistema precisa tornar minha direção executável e verificável mesmo quando o contexto muda, a conversa é compactada ou outro agente assume uma etapa.

Um bom sistema não exige que o usuário se comporte como uma máquina para compensar a memória transitória da máquina.

Ele transforma linguagem natural em contratos no momento certo.

Um protocolo simples para sessões longas

Depois desta experiência, eu reforçaria sete práticas:

1. Registrar decisões materiais. Se muda ordem, escopo, publicação ou responsabilidade, sai do chat e entra no estado durável.
2. Marcar substituições. A decisão nova precisa declarar qual orientação anterior deixou de valer.
3. Manter um estado atual curto. Versão atual, versão candidata, base, próximos passos e bloqueios precisam caber numa leitura rápida.
4. Reler contratos depois de compactação. O resumo ajuda na continuidade; os arquivos canônicos restauram a precisão.
5. Validar a topologia antes da ação. Antes de enviar para avaliação, confirmar base, dependência e ordem de publicação.
6. Devolver contradições ao autor. Se a ação provável conflita com uma decisão registrada, perguntar antes de executar.
7. Aprender com o erro. Corrigir a entrega e também o mecanismo que permitiu a divergência.

Isso vale para um blog.

Vale ainda mais quando um agente lida com orçamento, cliente, estoque, contrato, infraestrutura ou dados pessoais.

É assim que uma conversa vira operação

Na i-9.ai, o valor não está em entregar uma janela de chat com um prompt maior.

Está em transformar requisitos, decisões, exceções e responsabilidades em um sistema que continua coerente depois da reunião.

O cliente não deveria precisar reensinar à IA, toda manhã, como a empresa funciona.

Também não deveria acreditar que uma memória volumosa substitui processos, permissões e fontes de verdade.

O objetivo é construir um cérebro operacional no sentido figurado: uma estrutura capaz de receber linguagem humana, preservar direção e coordenar execução sem fingir consciência ou autonomia irrestrita.

Foi exatamente isso que esta falha mostrou.

A IA não precisa lembrar de tudo.

O sistema precisa saber o que não pode esquecer.

E a direção continua sendo do autor.

Se essa preocupação se parece com um problema que sua empresa já vive — decisões espalhadas em reuniões, mensagens e cabeças —, você pode entrar em contato.

Continue lendo

• Escrever com IA não me tornou menos autor
• Se você acha que IA é só um chatbot
• Agentes genéricos podem ser seu pior primeiro contato com IA

Para se aprofundar

• Compactação de contexto na documentação oficial da OpenAI: mecanismo para reduzir o volume de uma conversa longa e continuar o fluxo.
• Controle de versão: introdução ao registro de mudanças, versões e recuperação de estados.
• Fonte única de verdade (em inglês): contexto enciclopédico sobre manter um dado autoritativo para cada elemento de informação.

Referências e limites de uso

• OpenAI, “Model guidance — Compaction”: descreve compactação na Responses API para fluxos longos e recomenda monitorar o uso de contexto. Não documenta esta sessão específica nem prova qual detalhe será preservado em toda compactação.

A descrição do erro, da prioridade perdida e da correção do fluxo de publicação vem desta sessão. A relação entre memória de trabalho, fonte de verdade e harness é uma síntese autoral de engenharia, não um experimento controlado sobre comportamento de modelos.

A imagem de capa é uma ilustração editorial sintética sobre a diferença entre contexto compactado e decisão preservada.