AWS: uma única ferramenta cortou 95% dos tokens por script, e habilidades sob demanda reduziram o prompt em 97%

Imagine que você peça a um agente de IA: «Analise os dados de vendas e faça um relatório em DOCX». O agente carrega os dados, calcula por categoria, desenha cinco gráficos, verifica as estatísticas e escreve o documento. Tudo isso leva cerca de 15 minutos e mais de 150 mil tokens, enquanto a janela de contexto (a memória de trabalho do modelo) do Claude Sonnet 4.

5 no Amazon Bedrock é de 200 mil. Se cada script escrito e cada resultado ficam acumulados nessa memória, ela se esgota rápido: o agente falha no meio da tarefa, perde precisão ou queima o orçamento, já que os tokens são cobrados. A equipe da AWS mostrou, no projeto aberto Deep Insight, como evitar isso.

Os dois números principais: usar uma ferramenta no lugar de duas reduz em cerca de 95% os tokens que cada script adiciona, e o carregamento de habilidades sob demanda diminui o prompt de sistema em cerca de 97%. Para quem desenvolve agentes, é um caminho direto para torná-los mais baratos e confiáveis.

Por que um contexto sobrecarregado é um problema

O problema não é só que a janela pode acabar. A Anthropic descreve o efeito context rot: quanto mais tokens no contexto, pior o modelo se lembra da informação necessária. Dados desatualizados atrapalham, e qualquer erro obriga a reiniciar todo o pipeline. Por isso, a AWS reuniu técnicas dos artigos de engenharia da Anthropic e dos recursos do Strands Agents SDK em quatro camadas de «engenharia de contexto». Esta é a segunda parte de uma série; o Deep Insight é uma solução multiagente para análise de dados, construída com o Strands Agents SDK e o Amazon Bedrock AgentCore, e todos os exemplos usam esse projeto.

Camadas 1 e 2: separar os agentes e limitar as respostas

A primeira camada é a arquitetura. Cada agente especializado tem sua própria janela, e o coordenador recebe apenas um resumo condensado. No Deep Insight, a hierarquia é esta: Coordinator, Planner, Plan Reviewer, Supervisor e os agentes de trabalho Coder, Validator, Reporter, Tracker e Auditor. O estado compartilhado é um dicionário shared_state com apenas quatro campos: a última mensagem do agente anterior, as anotações condensadas clues, o checklist do plano e um diário resumido. Graças a isso, até o Coder, o agente mais «guloso», fica dentro de 25 mil tokens.

A segunda camada são os prompts. O isolamento não basta: se um agente responde de forma longa, o contexto do Supervisor incha do mesmo jeito. Por isso, os prompts definem orçamentos de resposta: Coder, de 1000 a 1500 tokens; Validator, 800; Reporter, 1000. O formato é o mesmo para todos: status, tarefas concluídas, principais conclusões com números e lista de arquivos. Há também uma regra pouco óbvia: cada script é autossuficiente, ou seja, contém seus próprios imports e carrega os dados do cache por conta própria. As variáveis não se mantêm entre execuções, mas, em compensação, o código antigo pode ser descartado do contexto sem risco.

Camada 3: só referências no contexto, os dados ficam em arquivos

Aqui está a economia mais expressiva. Normalmente, o agente tem duas ferramentas: «gravar arquivo» e «executar». Assim, cada script de 100 linhas entra inteiro no histórico da conversa, e, depois de algumas análises, já há mais de mil linhas de código ali. No Deep Insight, uma única ferramenta, write_and_execute_tool, faz os dois passos e devolve um resumo curto: «105 linhas gravadas, execução bem-sucedida, análise das cinco categorias concluída». O código permanece no disco, e o contexto recebe cerca de três linhas. Pela estimativa da AWS para esse exemplo, a economia é de cerca de 95% dos tokens por script.

Outras técnicas do mesmo tipo também funcionam:

• O módulo comum coder_analysis_utils.py é criado uma única vez, e suas funções são importadas com duas linhas, em vez das 20 a 30 linhas que o agente escreveria do zero a cada vez.
• O arquivo all_results.txt funciona como bloco de notas: o Coder acrescenta ali os detalhes, e o Supervisor recebe uma mensagem de cerca de 30 tokens.
• Arquivos substituem a passagem de dados entre agentes: calculation_metadata.json vai do Coder ao Validator, citations.json, do Validator ao Reporter, e audit_findings.json, do Auditor ao Reporter.
• As habilidades (Skills) são carregadas sob demanda. No prompt de sistema fica um catálogo de cerca de 500 tokens, e o agente só abre o guia completo SKILL.md (cerca de 3 mil tokens) quando precisa dele. Se todos os guias fossem inseridos de uma vez, seriam mais de 20 mil tokens a cada chamada. Daí vem a economia de cerca de 97%, e uma nova habilidade pode ser adicionada sem novo deploy.

Ressalvas e o que fazer na prática

Os números vêm da implementação de referência da própria AWS e de um único exemplo ilustrativo, com um script de 105 linhas, e não de um benchmark independente. Na sua tarefa, o efeito será diferente: quanto mais longos os scripts e quanto mais etapas, mais visível ele é. A quarta camada é a verificação por agentes independentes (Validator, Auditor) e limitadores de proteção contra estouro de contexto. No projeto, ela é a última linha de defesa, caso as três primeiras camadas deixem algo passar.

Na prática, a ordem é esta: separe os contextos entre os papéis, defina orçamentos de resposta nos prompts e leve o que é pesado (código, tabelas, resultados) para arquivos, passando apenas referências. O primeiro passo mais barato é unir «gravar» e «executar» em uma única ferramenta. O padrão agents-as-tools do Strands Agents SDK oferece isolamento no nível do framework, por isso não será preciso reescrever a orquestração do zero.