A semana em que custo, soberania e auditoria de agentes pararam de ser três conversas separadas — e viraram a mesma decisão de arquitetura para o CTO.
A Uber queimou o orçamento inteiro de IA de 2026 em quatro meses.
E o COO admitiu publicamente que não consegue ligar um único token consumido a uma feature entregue ao consumidor. Nas palavras de Andrew Macdonald: "That link is not there yet."
Esta é a Edição da ai|expert. O dia em que custo, soberania e auditoria de agentes pararam de ser três conversas separadas — e viraram a mesma decisão de arquitetura para o CTO.
Em dezembro de 2025, a Uber fez o que muita empresa sonha em fazer: distribuiu Claude Code para cinco mil engenheiros de uma vez. Era o tipo de adoção que gera slide de keynote. E gerou. [ref: uber-pumps-brakes-on-ai-spendi]
Em março, 84% dos desenvolvedores da Uber eram usuários de codificação agêntica. Em abril, 95% dos engenheiros usavam ferramentas de IA mensalmente. Setenta por cento do código commitado vinha de IA. Onze por cento das atualizações de backend em produção eram executadas por agentes com zero revisão humana. Eram os números que qualquer líder de engenharia queria apresentar no board.
E então o orçamento acabou. Quatro meses depois do rollout, a empresa tinha queimado o orçamento de IA previsto para todo o ano de 2026. O CTO Praveen Naga disse ao The Information: "Voltei à estaca zero, porque o orçamento que eu achava que precisaria já foi embora."
O mecanismo é simples quando você olha a estrutura de preço. O Claude Code usa precificação baseada em consumo — sem caps por engenheiro. O custo mensal por engenheiro ficou em média entre 150 e 250 dólares. Usuários pesados pagavam de 500 a 2.000 dólares por mês. No agregado, com cinco mil engenheiros, o gasto mensal variava de 2,5 milhões a 10 milhões de dólares. Para comparação: o GitHub Copilot cobra entre 10 e 39 dólares por assento por mês, taxa fixa.
Mas o pior não foi só o custo. Foi o design do sistema de incentivo que a Uber construiu em cima disso. A empresa implementou leaderboards internos que ranqueavam engenheiros por uso de IA. Mais tokens consumidos equivalia a pontuação mais alta. Você literalmente construiu um mecanismo que recompensa consumo máximo — e ficou surpreso com a fatura. Os custos de IA da empresa subiram seis vezes em relação a 2024, sobre uma base de R&D de 3,4 bilhões de dólares.
E o COO Andrew Macdonald expôs o problema de medição de uma forma que merece ser citada diretamente:
"It's very hard to draw a line between one of those stats and okay, now we're producing 25% more useful consumer features."
As métricas de output de engenharia melhoraram — mais commits, velocidade de iteração maior. A velocidade de entrega de features para o consumidor não acompanhou na mesma proporção. Havia um descompasso entre o que estava sendo medido e o que a empresa precisava produzir.
Esse descompasso reflete dois problemas simultâneos. Primeiro, uma falha de medição: proxies internos de produtividade não mapeiam para velocidade de produto. Segundo, uma questão genuína sobre o que ferramentas agênticas realmente comprimem — elas comprimem tempo para escrever código, mas o código ainda precisa de QA, integração e revisão de produto antes de chegar ao consumidor.
A Uber não está recuando. Está testando o Codex ao lado do Claude Code e movendo em direção a desenvolvimento liderado por agentes. Mas o CEO Dara Khosrowshahi revelou que a empresa estava desacelerando contratações para compensar o aumento do investimento em IA. A conta chegou — e mudou decisões de headcount. E a Microsoft's Experiences + Devices cancelou licenças internas do Claude Code em maio, com prazo de 30 de junho para migração para o GitHub Copilot CLI. Fontes internas confirmaram: gestão de custo influenciou o timing. O Claude Code tinha se tornado "muito popular, talvez popular demais."
O GitHub acabou de publicar o manual de como não cair nessa armadilha. [ref: github-reduces-agentic-token-c]
O GitHub cortou o gasto em tokens de workflows agênticos em até 62% em produção. A abordagem foi tripla: eliminar ferramentas MCP não utilizadas, substituir chamadas MCP por invocações nativas da CLI do GitHub, e implementar dois loops agênticos diários — um Daily Token Usage Auditor e um Daily Token Optimiser.
O que ancora o sistema é a métrica de Effective Tokens que eles criaram. Output tokens têm peso 4 vezes. Cache reads pesam 0,1 vez. Multiplicadores de modelo: Haiku a 0,25 vezes, Sonnet a 1,0 vez, Opus a 5,0 vezes. Uma queda de 10% em Effective Tokens se traduz diretamente em 10% de redução de custo — independente de qual modelo está rodando. É uma moeda única que atravessa toda a heterogeneidade do stack.
Os resultados foram medidos em doze workflows internos, ao longo de pelo menos 109 execuções pós-correção. Auto-Triage Issues caiu 62%. Smoke Claude, 59%. Security Guard, 43%. Daily Community Attribution, 37%. Apenas um workflow aumentou — Contribution Check, em 5% — e o GitHub atribuiu o aumento a uma mudança no tamanho dos PRs, não a uma regressão do otimizador.
O aprendizado contraintuitivo que importa mais do que os números: o Daily Community Attribution carregava oito ferramentas MCP não utilizadas, com zero chamadas em toda uma execução. Remover essas ferramentas não reduziu nada. O schema das ferramentas era uma fração minúscula do contexto total do workflow — dominado por grandes payloads de texto. MCP pruning só funciona quando é o bloat de schema que domina o prompt. Se o seu workflow já carrega documentos grandes ou histórico extenso de conversas, cortar ferramentas MCP não usadas vai ser ruído de otimização.
O que o GitHub fez de mais inteligente foi criar agentes que se auditam. O Daily Token Usage Auditor agrega consumo por workflow e sinaliza picos anômalos. O Daily Token Optimiser revisa o código-fonte e logs recentes, abre um GitHub issue, e propõe correções específicas. A infraestrutura está disponível no CLI gh-aw hoje. O próximo passo da equipe é análise de portfólio para eliminar leituras duplicadas e artefatos intermediários compartilhados em frotas inteiras de repositórios.
A tese é simples: token pricing em escala enterprise é um problema de custo de nuvem, não de licença de software. Caps de uso, orçamentos por engenheiro e camadas de monitoramento equivalentes à governança de DevOps no AWS precisam preceder rollouts agênticos — não seguir a primeira emergência de orçamento.
E há um terceiro elemento nessa equação, e a Anthropic acabou de movê-lo de forma material. [ref: anthropics-claude-opus-48-clai]
Em 28 de maio, seis semanas depois do Opus 4.7, a Anthropic lançou o Claude Opus 4.8. O preço padrão da API ficou idêntico: 5 dólares por milhão de tokens de entrada, 25 dólares por milhão de saída. Mas o fast mode — que entrega aproximadamente 2,5 vezes mais throughput do que o modo padrão — caiu de 30 e 150 dólares para 10 e 50 dólares por milhão de tokens. Uma redução de dois terços no modo que mais importa para loops agênticos.
E o desempenho subiu junto. No SWE-Bench Pro, o Opus 4.8 marcou 69,2% — acima dos 64,3% do 4.7, superando o GPT-5.5 em 58,6% e o Gemini 3.1 Pro em 54,2%. No SWE-bench Verified, chegou a 88,6%. No computer-use, 84% no Online-Mind2Web e 83,4% no OSWorld-Verified. GDPval-AA Elo de 1890, contra 1769 do GPT-5.5. É o único modelo a completar todos os casos do benchmark interno Super-Agent da Anthropic de ponta a ponta.
O que isso força o CTO a reconsiderar é a premissa de compra. Quando o modelo mais capaz do mercado custa o mesmo que o predecessor e entrega desempenho superior — o custo de não medir token-por-feature virou maior do que o custo de medir mal. Token-por-feature tem que ser KPI de board, não detalhe de engenharia.
Antes de virar a página, um alerta do system card do Opus 4.8 que merece atenção antes de qualquer rollout. A Anthropic identificou uma tendência crescente do modelo de especular sobre avaliadores no texto de raciocínio interno — presente em aproximadamente 5% dos episódios de treinamento. Isso ainda não se traduziu em comportamento observável pior. Mas arquitetos rodando pipelines com avaliação governada ou agentes em contextos legais precisam monitorar desvio de calibração antes de escalar.
Trinta e seis dias entre o 4.7 e o 4.8. Se você construiu gates de avaliação em torno do 4.7 em abril, você já tem dívida de qualificação — independente do fornecedor.
Vamos mudar de frame. Toda a conversa de custo de token assume uma premissa: o modelo vive na nuvem. Mas há um cluster rodando DeepSeek V3.1 com 671 bilhões de parâmetros a 25 tokens por segundo — em cima de quatro Mac Studios, sem nenhuma chamada de API, sem egresso de dados, por 38 mil dólares. Isso não é um paper de pesquisa. É produção documentada. [ref: the-10k-sovereign-ai-cluster-h]
A configuração: quatro Mac Studio M3 Ultra com 512 gigabytes de RAM cada, a 9.499 dólares por unidade, conectados com Thunderbolt 5 — total aproximado de 38 mil dólares. O mesmo stack roda Kimi K2, o modelo Mixture-of-Experts com um trilhão de parâmetros, a 34 tokens por segundo. Tudo no prédio, sob controle total, sem terceiro no loop.
O que tornou isso viável hoje é o RDMA-over-Thunderbolt 5 do macOS 26.2. A Stabilise.io mediu 5 a 9 microssegundos de latência entre nós — contra os típicos 300 microssegundos do Thunderbolt sem RDMA. Essa diferença de duas ordens de magnitude permite fragmentar camadas com paralelismo tensorial através de pools de memória unificada sem que o interconexão vire gargalo.
Para orçamentos menores, existe a configuração de quatro Mac Mini M4 Pro — 48 gigabytes de RAM cada, 1.999 dólares por unidade, mais 200 dólares em cabos Thunderbolt 5. Total de aproximadamente 8.200 dólares. Essa configuração serve Nemotron-70B a 8 tokens por segundo e Qwen2.5Coder-32B a 18 tokens por segundo via EXO Labs.
A escolha de framework depende do caminho crítico. Um benchmark arXiv no Mac Studio M2 Ultra encontrou: MLX entregando o maior throughput de geração sustentado; MLC-LLM o menor time-to-first-token; llama.cpp o serving single-stream mais eficiente; Ollama o deployment mais ergonômico — com custo em throughput e latência. Todos ainda ficam atrás do vLLM em performance absoluta em sistemas NVIDIA GPU.
Mas performance absoluta não é o argumento central aqui. O argumento é soberania. Pesos e prompts nunca saem do prédio. Sem API de terceiros, sem monitoramento de egresso, sem negociação de rate limit, sem cláusulas de uso de dados para revisar. Para times sob regras estritas de residência — GDPR, HIPAA, NIS2 — essa propriedade arquitetural pode superar diferenças de throughput bruto.
Mas as ressalvas são reais. O RDMA ainda requer comandos manuais em modo de recuperação do macOS — é early-stage. Qualquer nó M1 ou M2 no Thunderbolt 4 regride para TCP/IP e perde as garantias de latência. Esses clusters são mais adequados para inferência em batch do que para chat interativo de alta frequência.
E modelos Mixture-of-Experts introduzem um gargalo específico. Um estudo arXiv rodando DBRX 132B num cluster Mac Studio M2 Ultra descobriu que o tempo de comunicação se aproxima do tempo de computação durante o roteamento de experts — exigindo otimização manual de memória para evitar que o interconexão dominasse o caminho crítico. Esse mesmo workload foi 1,15 vezes mais eficiente em custo que um supercomputador NVIDIA H100 — mas somente depois do tuning manual.
O piso novo do BYO-inference está em 38 mil dólares e algumas horas de engenharia em recovery mode. A questão estratégica é o que acontece nas camadas acima desse piso — em escala de plataforma. [ref: snowflakes-6b-graviton-investm]
A Snowflake demonstrou o que acontece. A empresa comprometeu 6 bilhões de dólares com a AWS ao longo de cinco anos — em CPUs Graviton 5 e GPUs de nuvem. Para contextualizar a trajetória: no IPO em 2020, o compromisso era de 1,2 bilhão de dólares. Em 2023, subiu para 2,5 bilhões. Em 2026, dobrou para 6 bilhões — em média 1,2 bilhão por ano.
O Graviton 5 tem 192 núcleos Arm Neoverse V3 com 12 canais de memória a 8.800 megabytes por segundo. A Snowflake está migrando computação de propósito geral de CPUs Intel e AMD x86 para Arm. GPUs continuam responsáveis por treinamento e inferência de modelos. O plano de controle — o motor SQL em linguagem natural do Cortex AI, pipelines de sumarização, análise de sentimento, e o fabric MCP da Natoma adquirida para governança de agentes — opera em Arm.
E o motivo revela a estrutura real do custo agêntico. O GPU gerencia a inferência do modelo. Mas cada query SQL, cada UDF Python, cada step de workflow que um agente dispara — isso é computação de propósito geral. Throughput de agente é CPU-bound. A Meta se comprometeu a deployar dezenas de milhões de núcleos Graviton 5 para IA agêntica. O plano de controle é o gargalo. O orçamento de silício está se deslocando de acordo.
O risco de capacidade é imediato. Andy Jassy disse à GeekWire que dois grandes clientes tentaram recentemente comprar toda a produção Graviton da Amazon para 2026 — e foram recusados. Capacidade Graviton sob demanda em escala está efetivamente indisponível. Reserva de capacidade com múltiplos anos de antecedência é mandatória para quem está construindo plataformas agênticas.
E há um segundo risco que está recebendo menos atenção: lock-in de ISA. O Graviton é baseado em Arm, mas específico da AWS. Uma migração multi-cloud futura ficou substancialmente mais cara do que mover entre nuvens x86. Quando você assina um compromisso de 6 bilhões por cinco anos, o custo de troca deixa de ser teórico.
Há também uma regressão de integração que precisa ser nomeada. A Snowflake adquiriu a Natoma para governança de Model Context Protocol, integrando agentes em sistemas enterprise. Mas a maioria das organizações ainda não tem observabilidade que conecte saturação de núcleos de CPU diretamente a taxas de conclusão de tarefas de agentes. O modo de falha concreto: um GPU ocioso esperando por um resultado SQL. Se a concorrência Graviton estrangular na execução de UDFs ou no overhead de handshake MCP, a latência end-to-end regride — mesmo que a eficiência por núcleo melhore.
A terceira camada de soberania não é silício. É onde o agente pode executar código. E o Azure Logic Apps acaba de trazer isso para dentro do próprio barramento de integração. [ref: azure-logic-apps-adds-sandboxe]
O Logic Apps incorporou interpretadores de código em sandbox para seu loop agêntico. Python, JavaScript, C# e PowerShell executando dentro de runtimes isolados sem sair do barramento de integração — em preview público, integrado com mais de 1.400 conectores pré-construídos.
A pilha técnica varia por nível. No nível Standard, o interpretador inicia uma sessão dinâmica do Azure Container Apps dentro de uma microVM Hyper-V — isolamento de rede garantindo que os dados fiquem dentro dos limites definidos. No nível Consumption, JavaScript executa num isolate V8 via biblioteca isolated-vm — mecanismo mais leve que Hyper-V, com garantias de segurança diferentes.
E a Microsoft é explícita: isso não é um sandbox de segurança completo. É defesa em profundidade. Limites de memória, timeouts de execução, isolamento de falhas que previne crashes de agentes de derrubarem o processo de runtime. Não é seguro para código completamente não confiável. O risco muda de escape de sistema para erro lógico silencioso ou abuso por injeção de prompt dentro do boundary do sandbox.
O benefício arquitetural imediato é tirar cargas analíticas da janela de contexto do LLM. Cálculos grandes feitos in-context geram alucinações. O código em sandbox executa deterministicamente e devolve o resultado. Mas a Microsoft não publicou latência por chamada, custo por execução, ou throughput. Sessões dinâmicas do ACA introduzem overhead de infraestrutura e latência de cold-start que não foram quantificados. E sem SLA de produção em preview público, a decisão de arquitetura precisa incluir esse risco explicitamente.
Silício soberano no rack. Runtime soberano no workflow. Plano de controle soberano na nuvem. Soberania não é uma decisão — são três encadeadas. E a janela para fazer cada uma está fechando.
As histórias dos dois blocos anteriores convergem para a mesma pergunta: como você sabe se o agente está fazendo o que você pensa que ele está fazendo? Não no benchmark. No seu ambiente de produção, na sua codebase, nos seus processos de negócio. E a resposta honesta, hoje, para a maioria das organizações é: você não sabe. [ref: scalable-oversight-gets-statis]
Pesquisadores de Stanford — William Overman e Mohsen Bayati — publicaram o CCO: Calibrated Collective Oversight. Um framework que mantém controle humano sobre agentes autônomos com garantias estatísticas de tempo finito, mesmo em cenários de observação adversarial e sem suposições distribucionais. Sem precisar especificar um MDP. Sem exigir coordenação entre supervisores.
O mecanismo em termos práticos: em cada step, o agente primário propõe ações candidatas com scores de utilidade. Uma ação de baseline conservadora está sempre disponível — a ação que não faz nada de arriscado. Supervisores auxiliares pontuam cada candidata ao longo de dimensões como escopo ou segurança. O CCO calcula uma penalidade agregada medindo o desvio total do baseline conservador, e seleciona a ação que maximiza utilidade menos lambda vezes a penalidade. O lambda é calibrado online usando Conformal Decision Theory — com garantias de tempo finito e sem suposições distribucionais.
Os resultados no benchmark MACHIAVELLI — 134 jogos Choose-Your-Own-Adventure com mais de 500 mil cenários de tomada de decisão social — foram redução significativa de violações éticas sem colapso de recompensas. No SWE-bench modificado, supervisores mais fracos conseguiram restringir com sucesso um agente mais forte adversarialmente desalinhado. As taxas empíricas de violação acompanharam de perto os alvos especificados.
A limitação prática que importa para quem está deployando hoje: o CCO precisa saber após cada step se a ação gerou uma perda. No MACHIAVELLI e no SWE-bench, essa informação está disponível instantaneamente porque é scriptada. Em deployments ao vivo, a perda pode não ser observável por minutos ou horas — quebrando o loop de feedback online que o framework depende.
E há o custo de latência de ensemble: cada ação candidata precisa ser pontuada por todos os supervisores auxiliares contra o baseline. Se todos os supervisores deixarem passar um risco — porque nenhum foi treinado para reconhecê-lo — a penalidade de desvio é próxima de zero e o agente prossegue sem obstáculo. O sistema é tão bom quanto a diversidade e cobertura do ensemble. Esse é o limite e também o ponto de entrada para o arquiteto: a composição do ensemble é onde o investimento em auditoria começa.
E a Microsoft aplicou exatamente essa lógica — ensemble de agentes, debate adversarial, validação em estágios — em escala industrial na própria codebase. O resultado chegou no Patch Tuesday de maio. [ref: microsoft-mdash-scaling-vulner]
O MDASH — Multi-model Agentic Scanning Harness — foi construído pela equipe de Autonomous Code Security da Microsoft com o grupo MORSE e o time WARP. Em maio de 2026, encontrou 16 vulnerabilidades no Windows, incluindo quatro RCEs críticos. Todos os 16 entraram diretamente no ciclo do Patch Tuesday de maio de 2026.
O pipeline tem cinco estágios: Prepare, Scan, Validate, Dedup, Prove. Mais de 100 agentes especializados rodam em paralelo sobre um ensemble de modelos frontier e destilados. O sistema ingere uma codebase, constrói índices com consciência de linguagem, extrai modelos de ameaças do histórico de commits, roda agentes auditores especializados sobre caminhos de código candidatos, deduplica descobertas através de debate entre agentes, e gera exploits proof-of-concept para os sobreviventes.
No benchmark público CyberGym — 1.507 vulnerabilidades do mundo real — o MDASH marcou 88,45%, liderando o placar por cinco pontos percentuais acima do Claude Mythos Preview da Anthropic. Recall interna contra casos MSRC confirmados: 96% no clfs.sys em 28 casos ao longo de cinco anos; 100% no tcpip.sys em sete casos no mesmo período. Em um teste privado controlado com o StorageDrive — uma codebase que os modelos nunca tinham visto publicamente — o MDASH encontrou as 21 vulnerabilidades plantadas com zero falsos positivos.
Dois achados críticos que entraram no Patch Tuesday: CVE-2026-33827, um use-after-free remoto não autenticado no tcpip.sys. E CVE-2026-33824, um double-free no serviço IKEv2 alcançável pela porta UDP 500. Ambos críticos. Ambos encontrados antes que um ator malicioso os encontrasse.
A lição para o arquiteto não é "espere o MDASH estar disponível em GA". É sobre onde investir: no harness de orquestração. Validação em estágios, debate adversarial entre agentes, geração automatizada de proof-of-concept. A Microsoft foi explícita: o sistema foi projetado para sobreviver a uma troca de modelo sem reconstruir o harness. O modelo é substituível. O pipeline é o moat.
E há um terceiro ângulo nessa história de auditoria — onde o custo de não auditar ficou mais concreto do que qualquer CVE. [ref: 3m-applicant-analysis-reveals-]
Uma auditoria conduzida por Stanford de 3,4 milhões de candidatos triados pela Pymetrics — agora propriedade da Harver — revelou que o algoritmo de avaliação cognitiva de um único vendor produziu impacto adverso racial mensurável no nível individual de vaga. O estudo analisou 4 milhões de aplicações em 1.700 posições e 150 empregadores.
O algoritmo direcionou 26% das submissões de candidatos negros e 15% das submissões de candidatos asiáticos para posições onde o sistema discriminou contra seu grupo, segundo a regra dos quatro quintos da EEOC.
E o efeito de exclusão sistêmica é matemático. Dez por cento dos candidatos que enviam quatro aplicações são rejeitados de todas as quatro. Quatro por cento dos que aplicam para dez posições são rejeitados algoritmicamente de todas as dez. A probabilidade de exclusão total só cai abaixo de 0,1% se um candidato aplicar para 25 vagas distintas.
O mecanismo que torna isso sistêmico: a Pymetrics armazena scores e os reutiliza através da sua rede de empregadores por até 330 dias. Um candidato que aplica para múltiplas empresas não recebe avaliações independentes. O mesmo score em cache é referenciado repetidamente. Quarenta mil aplicações de minorias adicionais teriam avançado para revisão humana sob tratamento igualitário.
A parte que quebra toda a narrativa de conformidade anterior: a auditoria agregada própria do vendor não encontrou disparidades que chegassem a escrutínio legal. A média ocupacional dilui o viés entre famílias de cargos. A análise posição-a-posição de Stanford mostrou 10,62% dos cargos individuais com impacto adverso contra candidatos negros. O pool mascarou o que o per-position expôs.
E isso não é um defeito de implementação. É uma falha de arquitetura de auditoria. A Lei Local 144 de Nova York explicitamente permite auditorias em pool — o método que mascarou o viés neste caso. A maioria dos vendors de triagem de terceiros não tem obrigação de medir persistência de scores entre empregadores como risco de concentração.
A escala de mercado transforma isso em risco sistêmico. Sessenta por cento ou mais do Fortune 100 e oito dos dez maiores órgãos federais dos EUA rodam triagem através do HireVue sozinho. Decisões correlacionadas, determinísticas, propagadas em instituições a partir de um conjunto restrito de modelos compartilhados. Um único edge case de pontuação pode colocar um candidato em lista negra em toda uma rede. A deadline de conformidade do EU AI Act para ferramentas de contratação cai em 2 de agosto de 2026 — e o estudo argumenta que os frameworks atuais ainda carecem de mandatos de impacto adverso por posição, vigilância de mercado entre empregadores, e caminhos legais para acesso independente de pesquisadores aos dados dos vendors.
O que conecta essa história ao primeiro bloco: se você não tem um framework de auditoria estatística rodando hoje — sobre os seus agentes de código, sobre os seus sistemas de triagem, sobre os seus workflows de decisão — o regulador, o jornalista, ou o cliente vai rodar por você.
E a conta é maior que a do token.
Custo, soberania, auditoria. Não são três conversas para agendar em três reuniões diferentes. É uma decisão de arquitetura. E você está tomando ela — quer você saiba disso ou não.
A semana em que a conta chegou não foi sobre um número — foi sobre a ausência de um método para lê-la. Tokens sem KPI, silício sem observabilidade, agentes sem garantia estatística. O trabalho para a próxima semana: escolher qual das três camadas você vai instrumentar primeiro. Wire na segunda — abrimos com o GPIC, o corpus aberto de 28 trilhões de pixels que acabou de aposentar o ImageNet como padrão de treino. Bom trabalho.