Respostas
Nossa IA escreve bastão de 400 linhas e o próximo agente lê metade. O que resolve?
A saída não é prompt mais curto nem regra de estilo mais rígida — é separar o que VIAJA do que fica guardado. Tamanho é o que o leitor paga, e o que o próximo agente precisa cabe numa linha autorada. Na Arroway toda entrada carrega uma essência escrita à mão: o estado operativo numa frase, nunca a cópia da abertura do corpo. É essa linha que a leitura serve. O corpo inteiro continua recuperável e só volta quando alguém pede aquela entrada pelo nome. Assim o registro pode ser tão minucioso quanto o trabalho merecer sem que as próximas doze leituras paguem por isso — e, porque a linha é autorada em vez de truncada, ela diz a coisa, não os primeiros 200 caracteres da coisa.
Última atualização 18 de setembro de 2026
Nota longa não é nota minuciosa; é uma conta que o próximo leitor paga
A armadilha é que minúcia e tamanho são a mesma coisa na hora de escrever e deixam de ser na hora de ler. Um modelo a quem se pede um bastão escreve tudo em que tocou, porque não tem como saber o que importou — esse julgamento vem depois do trabalho, de quem sabe qual das doze coisas mudou o resultado. O resultado se lê como diligência e se comporta como ruído: todo agente posterior carrega a coisa inteira, gasta atenção na parte que já estava resolvida e não recebe sinal nenhum de onde está a parte viva. O custo não é pago uma vez, por quem escreveu. É pago em toda leitura, por todo agente, enquanto a nota existir.
Ler pela metade é o desfecho normal, e nada acusa
Quando a nota é maior que a atenção que ela recebe, o leitor não falha em voz alta. Ele lê o começo — onde mora a montagem —, age sobre isso, e a correção que veio quatrocentas linhas depois fica sem leitura. Ninguém vê um corte. O que o time vê é um assistente fazendo com confiança aquilo que foi revertido na terça, e a conclusão que se costuma tirar é que o modelo não é confiável, em vez de que o registro deixou a parte errada mais fácil de alcançar. Registro que põe a conclusão no fim é registro que vai ser mal lido por qualquer coisa que fique sem espaço.
Envelhecer é propriedade da entrada, não do arquivo
A segunda metade da queixa — a nota envelhece rápido — é uma pergunta sobre o que ENCERRA uma entrada, não sobre com que frequência alguém reescreve o arquivo. Uma linha de prosa dentro de um documento longo não carrega nada dizendo quando ela deixa de valer, então fica ali com a mesma cara das linhas que continuam valendo. Aqui cada entrada nasce com a condição que a mata, e o trabalho que torna essa condição verdadeira aposenta a entrada no mesmo ato, com o motivo na linha arquivada. Trabalho inacabado é outra coisa, de novo: é endereçado a quem continua, fica no topo de toda leitura até alguém fechar, e morre por fechamento, nunca por idade.
Como isso aparece na prática
Uma rotina noturna termina às três da manhã e escreve um bastão. O modelo que o escreveu tinha uma sessão longa atrás de si, então a nota tem quatrocentas linhas: os arquivos que abriu, as duas abordagens que tentou e abandonou, a saída inteira de uma rodada de teste, um pedido de desculpas por uma ferramenta que estourou o tempo e — na linha trezentos e sessenta — a única coisa que importa de verdade, que a migração foi aplicada na preview e não em produção. A rotina da manhã seguinte lê o bastão. Passa pela montagem e pelas abordagens abandonadas, forma a imagem de uma sessão que correu bem no geral, e começa o próprio trabalho. A linha da migração nunca chega nela. Nada falha. O build fica verde, a revisão passa, e a lacuna aparece dois dias depois como um erro de integração que ninguém liga à nota. O bastão estava completo e estava correto e não funcionou, porque estar completo não é a mesma coisa que ser lido.
Perguntas que as pessoas fazem sobre isso
- Não basta mandar o modelo ser breve?
- Dá pra mandar, e funciona por uma nota. O que isso não faz é transformar brevidade em propriedade do registro, porque a próxima sessão começa com outro modelo, outro prompt e outra ideia do que é ser breve. A linha que se sustenta é estrutural: uma frase autorada é o que a leitura serve, e o corpo é recuperável sob pedido. Aí o incentivo aponta para o lado certo — escrever mais não custa nada a quem escreve e também não custa nada a quem lê, porque o excedente nunca viaja sem ser pedido.
- E se a única linha deixar de fora algo de que o próximo agente precisava?
- Aí ele pede a entrada pelo nome e recebe a coisa inteira. É por isso que o corpo fica guardado em vez de apagado: a forma curta é um padrão, não um teto. O que muda é quem paga — a leitura que precisa do detalhe paga pelo detalhe, em vez de toda leitura pagar por todo detalhe por via das dúvidas. E, porque a linha é escrita por quem fez o trabalho, e não gerada do primeiro parágrafo, os casos em que ela engana são raros o bastante para tratar por exceção.
- Isso não é só um campo de resumo? Dá pra acrescentar um ao nosso arquivo.
- Um campo de resumo no arquivo resolve parte, e a parte que ele deixa passar é justamente a que dói aqui. O que decide se funciona é se a forma curta é o que o leitor de fato RECEBE: se o arquivo inteiro continua chegando e o resumo fica no topo dele, nada mudou além de o arquivo ter ficado maior. A outra metade é a retirada — resumo de um documento com linha morta dentro é um jeito mais curto de servir linha morta. As duas metades precisam valer para a nota parar de custar o que custa hoje.
Onde isto se confere
Documentação do produto neste site (Como funciona, Instalação), as respostas sobre o arquivo de contexto que estourou uma página e sobre memória desatualizada lida como vigente, e as regras de essência autorada, bastão e vigência na especificação sancionada do produto. Tudo descrito aqui é comportamento que as ferramentas aplicam hoje, não roadmap.
https://www.arroway.app/pt-BR/answers/chatty-handoffs-bloat-every-agent-that-reads-them-next