Ideia principal

Um skill precisa analisar três fichas de clientes. Sem filtro na entrada, ele carrega quinhentas. O resultado produzido é idêntico; a despesa, não — cerca de 150 000 tokens de entrada para um material que nunca vai servir.

O custo de uma leitura não acompanha o que você tira dela, acompanha o que você colocou na janela. Um agente não "passa os olhos": tudo o que entra é pago, inclusive o que ele descarta na hora.

Daí um deslocamento do trabalho de otimização: a questão não é mais como pedir melhor, e sim como consultar a base — filtro, paginação, seleção prévia por script. A leitura condicional vai ainda mais longe: não abrir uma fonte de jeito nenhum quando uma condição prévia não está satisfeita.

Por que isso importa

Isso situa a economia do lado do acesso aos dados, e não do lado do prompt, que é onde costumamos procurá-la.

E dá um sintoma fácil de identificar num relatório de auditoria: uma etapa de leitura cujo volume não tem relação com o número de elementos realmente tratados.

Nuances e limites

Filtrar pressupõe saber de antemão o que é pertinente. Quando a pertinência é justamente o que a execução deve estabelecer, a leitura ampla não é desperdício, é o trabalho.

E uma seleção mal formulada é pior do que uma leitura completa: ela produz uma resposta plausível sobre um material truncado, sem que nada sinalize isso.

Questões em aberto

• Como medir, depois do fato, a parcela dos dados carregados que realmente pesou sobre a saída?