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. A OpenAI apresentou o Pando, backend compatível com Git construído para trabalho em escala de agentes. 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.