O Livro de Custos MCP: FinOps para 47 Agentes de IA Sem um Esquema de Tags

O 47º agente é quando as finanças aparecem. Abaixo de 30 agentes em produção, a fatura da Anthropic é um item de linha tolerável em algum lugar abaixo de $25.000 por mês, e ninguém pergunta quem está gastando o quê. Acima de 30, o item de linha ultrapassa $25 mil. Aos 47, a frota mediana que vejo nos clientes da ZopDev está em $80.000 por mês, e as finanças entram na próxima revisão orçamentária com uma única pergunta: qual agente.

Ninguém pode respondê-la. O painel de custos categoriza os gastos por conta da AWS, por equipe, por serviço, por tag. Nenhuma dessas categorias contém agentes, porque os agentes não consomem recursos marcados com sua identidade. Eles consomem tokens, cobrados em uma única conta da Anthropic ou OpenAI, com a fatura por chamada opaca para o sistema de custos em nuvem. As tags de recursos capturam a infraestrutura. Elas perdem completamente a fatura do LLM.

A solução é um livro de custos: uma linha de cinco campos por chamada LLM que o tempo de execução do agente carimba na saída, emparelhada com o log de auditoria de chamadas da ferramenta MCP existente. Com o livro em vigor, qualquer questão de alocação (por agente, por equipe, por recurso, por cliente) se torna uma única consulta SQL. Sem ele, a frota de agentes é um único item de linha que o diretor financeiro não pode desagregar.

Este post é o esquema, o modelo de atribuição de dois eixos e o padrão de loop fechado que o livro compõe. Ele se baseia em AI FinOps agentic e no LLM FinOps por orçamento de tokens por recurso sem re-arquitetar nenhum deles.

O 47º agente e a revisão financeira de pânico

A maioria das frotas de agentes segue a mesma curva de crescimento. Os primeiros dez agentes são projetos piloto que usam as chaves de API de engenheiros individuais; ninguém os rastreia centralmente. Os agentes onze a trinta recebem um orçamento compartilhado e alguma supervisão central solta. O total é de $5 mil a $25 mil por mês e o CFO não se incomoda.

Cruzando 30 agentes é a inflexão. O item de linha agora é um dos 15 principais motores de custo em nuvem, as finanças pedem a divisão, e a engenharia não tem uma. A adaptação leva seis semanas de trabalho arqueológico entre faturas da Anthropic, spans do OpenTelemetry e threads do Slack. Equipes que instrumentaram a atribuição por agente antes de cruzar 30 pulam o mês de pânico completamente.

Por que as tags não funcionam para agentes

A alocação de custos em nuvem é construída em torno do Relatório de Custos e Uso da AWS. Os recursos têm tags. As tags são puxadas para o CUR. O CUR alimenta o painel. O painel categoriza por tag. Isso funciona porque os recursos em nuvem têm um mapeamento um-para-um entre identidade e consumo.

Os agentes quebram esse mapeamento de três maneiras.

A cardinalidade está errada. Uma única conta da AWS hospedando 47 agentes tem centenas de recursos em nuvem, cada um marcado uma vez. Os agentes compartilham infraestrutura (o mesmo Lambda, o mesmo Postgres, os mesmos servidores MCP), então as tags de recursos não podem identificar qual agente acionou uma determinada consulta. A tag de infraestrutura diz "runtime-llm-compartilhado"; o sistema de custos não sabe mais nada.

A fonte da verdade está errada. O gasto com tokens vive na Anthropic, não na AWS. A fatura da Anthropic chega uma vez por mês, agregada ao nível da conta. O CUR não tem visão disso. Mesmo que cada agente usasse uma chave de API separada (um pesadelo de configuração que nenhuma frota real executa), as chaves não fluiriam para o painel de custos em nuvem sem uma integração personalizada.

A chave de agregação está errada. As tags são estáticas; os agentes são dinâmicos. Um único agente hoje pode ser o classificador de fraudes, amanhã pode ser repropósito como revisor de chargeback. O agent_id é o grão certo, e o esquema de tags não pode manter identidades dinâmicas sem expansão.

A solução não é melhores tags. A solução é um livro paralelo que fica ao lado do CUR, de propriedade do tempo de execução do agente, com seu próprio esquema e regras de agregação. O painel os junta no momento da consulta.

O esquema do livro de custos de 5 campos

O esquema mínimo viável é cinco campos por chamada LLM:

O tempo de execução do agente escreve uma linha por chamada LLM. O esquema é pequeno o suficiente para viver no Postgres sem particionamento até bem além de 100 milhões de linhas. Com esses cinco campos, cada alocação se torna uma consulta SQL, não um relatório personalizado.

O custo é calculado no momento da consulta, não no momento da inserção. Os preços da Anthropic mudam; o livro armazena tokens, a consulta se junta à tabela de preços. Isso mantém a linha pequena e permite que você reponha o recálculo de custos em mudanças de preço sem reescrever a história.

Dois eixos: custo LLM vs custo colateral MCP

Uma invocação de agente não é apenas uma chamada LLM. É uma conclusão LLM mais N chamadas de ferramentas MCP. O custo LLM está em tokens. O custo colateral MCP é onde a ferramenta tocou: um GET S3 contra a fatura da nuvem, uma consulta RDS contra a fatura do banco de dados, uma chamada de incorporação Bedrock contra a fatura de outro provedor de LLM.

O livro precisa de ambos os eixos.

Os dois eixos não compartilham uma linha. A chamada LLM escreve no livro de custos; a chamada da ferramenta MCP escreve no log de auditoria existente; a chave de junção é o request_id que o tempo de execução do agente carimba em cada chamada de saída. Uma única invocação de agente pr