# Estado rápido não é estado confiável

> Threads de mensagens e um Git para milhares de agentes mostram por que desempenho depende de mover estado sem abandonar a fonte de verdade.

- Author: Elzo Brito
- Language: pt-BR
- Published: 2026-11-03
- Canonical URL: https://elzobrito.com/blog/estado-rapido-nao-e-estado-confiavel/
- Translation: https://elzobrito.com/en/blog/fast-state-is-not-trusted-state/

---
Agentes de inteligência artificial estão deixando de ser chamadas isoladas a um modelo. Eles mantêm conversas longas, usam ferramentas, abrem várias frentes de trabalho e produzem mudanças em paralelo. Nas últimas 24 horas, duas novidades aparentemente distantes expuseram a mesma tensão: para escalar, é preciso mover e reutilizar estado; para continuar correto, é preciso saber onde está a fonte de verdade.

A Anthropic colocou em beta os [*message threads* da API Claude](https://platform.claude.com/docs/en/build-with-claude/message-threads). A OpenAI apresentou o [Pando, backend compatível com Git construído para trabalho em escala de agentes](https://openai.com/index/scaling-git-at-openai/). Um reduz o custo de reenviar conversas; o outro evita reconstruir pacotes Git para cada cliente. Nos dois casos, o ganho não vem de fingir que o estado desapareceu, mas de representar melhor suas dependências.

## A conversa fica no servidor, mas não pertence a ele

Na API de Mensagens da Anthropic, uma aplicação normalmente reenvia o histórico completo a cada turno. O servidor precisa receber, validar e tokenizar novamente esse prefixo, mesmo quando apenas a última mensagem mudou. Isso aumenta o volume da requisição e pode elevar o tempo até o primeiro token em conversas extensas.

Com *message threads*, a primeira chamada envia o histórico, as instruções de sistema e as ferramentas. As seguintes enviam apenas as novas mensagens e o identificador da resposta anterior. A API reconstrói a conversa antes de chamar o modelo. Para laços longos de agentes, é como trocar o envio repetido de um arquivo inteiro por uma sequência de alterações encadeadas.

O detalhe importante está no contrato de falha. O recurso é beta, não atende a cenários de retenção zero de dados nem a requisitos HIPAA, e o estado é efêmero: um *thread* expira cinco minutos após a última requisição e é eliminado em até uma hora depois do último uso. A continuação também pode retornar `404` por outros motivos, inclusive quando a resposta anterior não foi armazenada.

Por isso, a própria documentação afirma que a aplicação continua sendo a fonte de verdade. Ela deve guardar todas as mensagens e ser capaz de reconstruir a conversa completa. O servidor oferece uma via rápida, não um diário durável.

Essa distinção evita um erro comum em arquiteturas de agentes: confundir cache, sessão ou conveniência de transporte com memória persistente. Se o processo precisa sobreviver a uma reinicialização, produzir auditoria ou retomar depois de horas, o histórico deve existir fora do *thread*.

## O Git escala quando deixa de ordenar o que não precisa ser ordenado

O Pando enfrenta o mesmo problema em outra camada. Segundo a OpenAI, o aumento do trabalho paralelo com Codex trouxe mais ramificações, *pushes*, *merges*, *fetches* e clones. A confiabilidade da infraestrutura que servia o monorepositório chegou, em alguns momentos, a ficar abaixo de 90%.

Em vez de abandonar o protocolo Git, a equipe refez o backend. O Pando armazena os *packfiles* enviados como objetos imutáveis, registra versões das referências em um serviço de metadados e permite que atualizações de ramificações independentes avancem em paralelo. Um cliente que lê várias ramificações pode vê-las em instantes diferentes; dentro de uma mesma referência, porém, as atualizações permanecem serializáveis.

É uma troca deliberada. Uma visão global e instantânea de milhões de referências custaria coordenação demais para uma propriedade que usuários e agentes raramente precisam. O que importa é preservar a causalidade necessária para buscar uma ramificação e garantir que dois escritores concorram quando tentam mover a mesma referência, não quando trabalham em referências sem relação.

Na leitura, o Pando reutiliza *packfiles* já produzidos, servidos por caches regionais, em vez de calcular e compactar um pacote específico para cada cliente. Na escrita, valida o pacote enquanto o transmite ao armazenamento de objetos, sem desempacotá-lo em um repositório local. A OpenAI relata que essa arquitetura suporta milhares de clientes concorrentes em seu monorepositório, mas também identifica corretamente as simulações publicadas como modelos didáticos sintéticos, não como *benchmarks* de produção.

Na prática, o desenho favorece equipes e agentes que trabalham em ramificações separadas e geram muita atividade de integração contínua. A compatibilidade com Git preserva clientes e hábitos existentes; a mudança fica concentrada no serviço que coordena objetos e referências.

## A nova unidade de desempenho é o estado reutilizável

As duas novidades sugerem uma mudança de foco. Durante muito tempo, otimizar aplicações de IA significava principalmente reduzir a latência de inferência ou escolher um modelo menor. Em sistemas com agentes, o custo também está em transportar contexto, reconstruir histórico, negociar repositórios e coordenar escritores.

Há um paralelo claro:

- o *thread* referencia a resposta anterior e envia apenas o novo trecho da conversa;
- o Pando registra versões causais de uma referência e reutiliza os pacotes que produziram seu histórico;
- ambos aceleram o caminho comum sem prometer uma visão global, permanente e infalível;
- ambos exigem uma estratégia explícita de recuperação quando a via rápida deixa de estar disponível.

Isso muda decisões práticas. Uma aplicação que adota *message threads* precisa testar repetição do histórico após expiração, queda de *stream* e divergência de parâmetros fixos. Uma plataforma de desenvolvimento com muitos agentes precisa separar ramificações, definir quem pode atualizar cada referência e tratar integração como uma etapa governada, não como efeito colateral de concorrência.

O avanço mais interessante do dia não é uma memória mágica nem um Git sem conflitos. É uma lição de engenharia: sistemas rápidos não eliminam estado; eles tornam explícito qual estado pode ser reutilizado, por quanto tempo e sob quais relações causais. A confiabilidade começa quando a via rápida falha e o processo ainda sabe reconstruir a verdade.