AWS Strands Agents: 3 lições para cortar 96% dos tokens dos seus agentes de IA

Cada token desperdiçado é dinheiro queimado — e sua arquitetura de agentes pode estar torrando 96% do orçamento sem você perceber.

O experimento: da ingenuidade à otimização radical

A demonstração partiu de um cenário cotidiano: um usuário pergunta “qual foi minha última fatura?” e o agente precisa consultar uma API contábil simples. A cada iteração, o design das ferramentas foi refinado, e o consumo de tokens despencou.

De 52.000 tokens para apenas 1.000. Nenhum modelo milagroso. Só arquitetura.

O framework Strands Agents (open source, 14 milhões de downloads) foi o laboratório. Mas as lições valem para LangChain, AutoGen, CrewAI ou sua implementação caseira.

Lição #1: Ferramentas baseadas em intenções > ferramentas baseadas em dados

O erro mais comum — e mais caro — é expor endpoints de API como se fossem funções nativas do LLM. O modelo gasta raciocínio precioso para orquestrar passos, interpretar respostas intermediárias e adivinhar a lógica de negócio. Isso queima tokens e multiplica pontos de falha.

Antes (ingênuo, baseado em dados)

• GET /invoices
• POST /invoices/filter
• GET /customers/{id}
• GET /customers/{id}/invoices

Depois (orientado a intenções)

• obter_ultima_fatura()
• consultar_status_pagamento()
• listar_faturas_pendentes()

O LLM não precisa mais entender como a API funciona. Ele invoca a intenção correta e recebe o resultado de negócio. Toda a complexidade fica na sua camada de código — determinística, testável e barata.

52.000 tokens caíram para 2.000. Uma redução de 96% que não depende de um modelo mais caro, mas exclusivamente de design inteligente.

Lição #2: Agentes de escopo estreito erram menos e gastam menos

O agente de faturas expunha apenas 3 ferramentas. Um agente genérico com 30 ou 50 ferramentas teria um prompt de sistema inchado e uma probabilidade muito maior de escolher a função errada ou executar passos desnecessários.

Agentes pequenos, especializados e com escopo limitado performam consistentemente melhor que um agente único tentando abraçar o mundo.

Como aplicar isso na prática

• Fragmente seu sistema em múltiplos agentes especialistas (faturas, clientes, pagamentos, reembolsos).
• Cada agente expõe um conjunto enxuto e coeso de ferramentas, alinhadas ao seu domínio.
• Utilize um roteador semântico — LLM leve ou busca vetorial — para direcionar a consulta ao agente correto antes de qualquer ferramenta ser chamada.

Benefício colateral: cada agente pode usar um modelo menor e mais barato, otimizado para seu domínio, ampliando a economia sem sacrificar qualidade.

Lição #3: Busca semântica no catálogo de ferramentas corta tokens pela metade

Mesmo com ferramentas orientadas a intenções, carregar todas as definições de função no contexto do LLM ainda custa caro. Cada descrição, parâmetro e exemplo consome tokens que poderiam ser usados para raciocínio.

Na arquitetura refinada do Strands Agents:

• Um MCP Server centraliza as definições completas das ferramentas.
• O Agent Core Gateway realiza uma busca semântica (embeddings + similaridade de cosseno) para recuperar apenas as N ferramentas mais relevantes.
• Somente esse subconjunto enxuto é injetado no contexto do LLM.

Resultado: 2.000 → 1.000 tokens. Mais 50% de economia, sem perda de qualidade na resposta.

O trade-off real: a busca adiciona latência (dezenas a poucas centenas de milissegundos) e exige um banco vetorial. Mas para sistemas com dezenas ou centenas de ferramentas, o ganho de custo é exponencial e a latência se paga com sobras.

O que isso significa para o mercado de agentes de IA

Para engenheiros e arquitetos

As três lições são completamente framework-agnósticas. Custo de tokens é problema de design, não de modelo. Um GPT-4o bem orquestrado pode custar menos que um Gemini 1.5 Pro mal projetado.

Para provedores de infraestrutura

MCP Servers e catálogos de ferramentas se tornarão peças centrais. Serviços de busca semântica para ferramentas emergem como nova categoria de produto — interseção entre bancos vetoriais, APIs e curadoria de conhecimento procedural.

Para empresas que adotam IA em produção

Agentes autônomos deixam de ser luxo de big tech. A redução de 96% no custo de tokens viabiliza casos de uso que antes eram proibitivamente caros: atendimento 24/7, automação de back-office, análise inteligente de dados.

Riscos e limites que você precisa considerar antes de implementar

• Complexidade de cenários reais: a demonstração usou uma API contábil simples. Em ambientes com dezenas de endpoints heterogêneos, a economia pode ser menor — mas ainda significativa.
• Design de ferramentas exige maturidade de domínio: criar funções orientadas a intenções realmente úteis demanda entender profundamente as consultas dos usuários. Uma abstração mal feita gera um agente confuso.
• Latência da busca semântica em cenários críticos: para respostas que exigem tempo real estrito (< 500ms), a etapa extra pode ser arriscada. Teste em escala antes de adotar.
• Manutenção contínua do catálogo: ferramentas desatualizadas ou com descrições imprecisas são uma fonte garantida de alucinações. O catálogo é um organismo vivo e precisa de governança ativa.

A Visão Metatron: o futuro pertence a quem dominar o design de ferramentas

O experimento da AWS não é mais um benchmark de laboratório. Ele define um novo padrão de maturidade para a engenharia de agentes de IA.

A esmagadora maioria das implementações está presa na iteração 1: expõe endpoints REST crus, queima tokens e culpa o modelo. As equipes de ponta já estão na iteração 3: ferramentas com intenção clara, escopo estreito e seleção semântica em tempo real.

O gargalo não é mais o modelo — é a arquitetura de ferramentas.

Quem dominar o design de intenções, o roteamento semântico e a curadoria de catálogos terá agentes que custam 10 vezes menos e entregam 10 vezes mais valor de negócio.

No futuro próximo, cada empresa terá seu próprio MCP Server interno — uma biblioteca viva de funções especializadas, alimentada por busca vetorial e orquestrada por agentes de escopo estreito. O custo de tokens será um detalhe operacional, não um impedimento estratégico.

Quer implementar esses padrões ainda esta semana? Comece auditando suas ferramentas atuais com uma pergunta simples: quantas vezes seu agente chama múltiplos endpoints para resolver uma única intenção do usuário? Depois, construa um catálogo semântico simples usando Qdrant, Pinecone ou até mesmo FAISS e teste a redução de tokens em um subconjunto do seu tráfego. Os resultados aparecerão — e a conta da API agradecerá.