agentes

A conta que o agente não mostra

O preço por token de IA caiu 67% em um ano. A fatura das organizações com IA em produção subiu de qualquer jeito. 73% das empresas já ultrapassaram as projeções de custo. O problema não está no preço unitário. Está no que acontece com ele quando o agente sai do piloto.

Alexandre Izefler
agentesgovernançaai-native

A conta que o agente não mostra

O preço por token de IA caiu 67% ao longo de 2025. E 73% das organizações ultrapassaram as projeções de custo com IA em produção no mesmo período.

Não é incoerência. É uma confusão entre preço unitário e estrutura de custo.

O que a tabela de preços não conta

A tabela de preços mostra o custo por milhão de tokens. O que ela não conta é como um loop de agente consome esses tokens.

Num chat convencional, cada pergunta é praticamente uma interação isolada. Você envia um contexto, recebe uma resposta, o ciclo fecha. Num agente, cada passo da cadeia reenvia o contexto acumulado. O prompt do sistema, as chamadas de ferramenta anteriores, as respostas intermediárias, o histórico crescente desde o início. O passo 10 inclui tudo que aconteceu nos passos 1 a 9. O passo 50 inclui tudo dos passos 1 a 49.

Ravi Kanani, do LeanOps Technologies, documentou essa curva em maio de 2026. Um loop de 5 passos custa 3,2 vezes mais que uma interação equivalente em chat. Com 50 passos, o multiplicador é 30 vezes. Com 200, passa de 100.

O preço unitário é verdadeiro. A estrutura de custo é outra.

O que muda do piloto para o sexto mês

Pilotos costumam ser comportados. O prompt é pré-definido. A tarefa tem limite claro. Alguém está de olho nos loops. O gasto fica dentro do esperado e parece previsível.

Produção é diferente. Agentes operam com mais autonomia. Estendem o contexto enquanto trabalham. Revisam o resultado quando não converge. Voltam ao início quando a especificação deixa margem pra isso.

The Source Code documentou o caso da Uber. A empresa foi de 32% para 84% de adoção de IA entre cerca de 5 mil engenheiros em três meses, de dezembro de 2025 a março de 2026. O orçamento anual de IA foi consumido em quatro meses. O custo médio por engenheiro ficou entre 150 e 250 dólares mensais; usuários intensivos chegaram a 2 mil. Numa demo de duas horas, o CEO gastou 1.200 dólares em tokens.

A Uber não foi descuidada. É uma das empresas mais deliberadas em adoção de tecnologia que existem. O que aconteceu foi que a estrutura de custo de um agente em produção real não se parece com a do piloto controlado.

O que a Coinbase construiu antes do problema aparecer

A Coinbase enfrentou escala semelhante. A diferença foi o momento da intervenção.

Enquanto a Uber aplicou controles depois que o orçamento já havia sido consumido, a Coinbase construiu infraestrutura preventiva antes de a escala chegar. Levou a taxa de cache de prompts de 5% para 60%. Resultado: a conta caiu em torno de 50% enquanto o consumo de tokens continuava crescendo.

Na minha leitura, essa distinção é o ponto mais importante do que diferencia uma adoção que escalou bem de uma que não escalou. A diferença não está na maturidade financeira de cada empresa. Está em quando a governança foi inserida. Uma como decisão arquitetural feita antes de o agente ir a produção. A outra como controle de gastos aplicado depois que a arquitetura já estava consolidada.

E esses dois momentos produzem resultados muito diferentes.

O imposto que a spec evita

O paper SDAD, de Nguyen e Nguyen (arXiv 2608.20341), formaliza uma relação que já era empiricamente observável. O que eles chamam de "Ambiguity Tax" é o custo extra de loops adicionais, tentativas de replanejamento e contexto reacumulado que um agente incorre quando a especificação não é precisa o suficiente para constrainá-lo.

A lógica não é difícil de seguir. Um agente com spec ambígua tem mais caminhos plausíveis disponíveis. Ele os percorre. Cada percurso adicional reenvia o contexto completo. O custo sobe não porque o modelo falhou, mas porque a entrada não era específica o suficiente para que a primeira tentativa fosse a última.

"Saber quando não chamar o modelo se torna tão importante quanto saber como solicitá-lo." Essa frase do Source Code não é metáfora. É a principal alavanca de custo disponível. A otimização mais eficiente de todas não é de cache, não é de roteamento por camada de modelo. É não fazer a chamada que não precisava ser feita.

Spec precisa era sempre relevante por razões de qualidade e de correção. Agora é também uma linha de orçamento.

No paradigma 70/30, os 30% reservados para humanos concentram especificação, design e validação. A leitura mais comum desse modelo é sobre valor. É aí que fica o julgamento, a intenção, o que nenhum agente recupera sozinho. Mas há uma leitura fiscal que começa a ter igual peso. Os 30% de especificação clara reduzem os loops. Os loops são o multiplicador de custo. Spec precisa é, literalmente, o que mantém os 70% de execução agêntica dentro do orçamento.

FinOps descreve o problema depois que ele existe. A spec resolve antes que o primeiro token dispare.

Referências