A semana em que autonomia de agente virou número medido — e a economia do silício embaixo deles mudou de dono.
De cinquenta e quatro para quinze por cento.
É o quanto um benchmark de agente encolheu quando um contribuidor independente checou a conta. E quinze por cento é exatamente o teto de autonomia que a Harness impõe nos próprios agentes que ela roda em produção.
Esta é a Edition da ai|expert. A semana em que autonomia de agente virou número medido — e a economia do silício embaixo deles mudou de dono.
Vamos começar pelo número que ninguém queria ouvir.
O Ponytail é um skill open-source com 82 mil estrelas no GitHub em menos de dois meses. O pitch: instrua seu agente de código a se comportar como "o dev sênior mais preguiçoso da sala." A lógica de operação é uma escada de decisão injetada no contexto do agente: isso precisa existir? Já existe no código? A biblioteca padrão resolve? Um recurso nativo da plataforma resolve? Uma dependência instalada resolve? Pode ser uma linha? E só então: escreva o mínimo que funciona. O ruleset roda em 16 plataformas de agente — Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Aider e outros. O SKILL.md central tem aproximadamente 100 linhas. As 6.232 linhas restantes são boilerplate de adaptadores.
O benchmark original prometia 80 a 94 porcento de redução de código.
Aí Colin Eberhardt, CTO da Scott Logic, puxou os números. E encontrou o problema fundamental: a linha de base do benchmark era um modelo nu e chatty, que enchia cada resposta de prosa, ressalvas e múltiplas opções de implementação. Isso inflava a comparação artificialmente. O teste dele: substituir o Ponytail por sete palavras em inglês — "Follow YAGNI principles, and one-liner solutions." Esse prompt bateu o Ponytail no próprio benchmark do Ponytail.
O Hacker News chegou à mesma conclusão de forma independente, descrevendo o repositório como "essencialmente apenas essas regras, e uma tonelada de boilerplate para sistemas de plugin específicos." Cada linha além do core é adaptador.
O autor reconstruiu o benchmark do zero. Doze tarefas de feature rodadas pelo Claude Code 2.1.177 em um repositório real de FastAPI e React. A versão corrigida do README agora reporta 54 porcento menos código em média — 94 porcento apenas onde um agente teria over-built, perto de zero em código já minimal. Custo caiu 20 porcento. Execução acelerou 27 porcento. A figura anterior era um teto por tarefa relatado como se fosse média.
Mas então o JetBrains rodou um estudo independente: 80 tarefas pareadas — a terceira de uma série que anteriormente mediu o caveman skill em menos 8,5 porcento de código contra os anunciados menos 65 porcento, e o rtk em mais 7,6 porcento contra os anunciados menos 60 a 90 porcento. O JetBrains usou um modelo diferente — claude-sonnet-5 com esforço de raciocínio médio — um conjunto de tarefas maior, e um harness externo.
Resultado: menos 15 porcento de código, menos 10,3 porcento de custo, menos 11 porcento de tempo. O JetBrains chamou de "a primeira ferramenta desta série com um sinal de economia de custo estatisticamente sólido." Mas deixou claro: a redução só apareceu onde havia espaço para over-build. O Ponytail mira tokens de saída; o lado de input praticamente não se moveu.
A distância entre 54 porcento — auto-reportado corrigido — e 15 porcento — independente — é o número prático. Economias reais. Mas entre um quarto e metade do que o README ainda anuncia.
Tem um ponto de segurança que não pode passar despercebido: em um tier adversarial cobrindo path traversal, SQL injection e token forgery, o Ponytail marcou 100 porcento. Um prompt simples de "YAGNI mais one-liners" caiu para 95 porcento, perdendo um caso de guarda. Essa é a única dimensão onde a complexidade do framework compensa claramente.
A questão maior que Eberhardt levanta sobrevive ao benchmarking específico: skills e frameworks baseados em prompt estão se proliferando sem nenhum padrão de avaliação compartilhado. A questão que ele publicou no repositório de Skills da Anthropic — como os autores testam e garantem qualidade — segue entre os mais votados e sem resposta em nenhuma biblioteca de skills.
O que me leva direto para a Harness. Eles não estão construindo benchmarks — estão medindo o que seus próprios agentes fazem em produção há seis meses. E o número que publicaram é o mais honesto que vi de um vendor de CI/CD até hoje: 15 a 20 porcento do trabalho de engenharia é genuinamente autônomo, do Jira ao pull request. Oitenta porcento ainda é assistido — desenvolvedores usando agentes como ferramentas, não delegando workflows inteiros.
Quatro em cada cinco tarefas, o humano ainda está no loop. Esse é o estado real da arte — não o que o keynote de qualquer vendor apresenta como a nova normalidade do desenvolvimento de software.
A Harness identificou quatro pilares depois de redesenhar o SDLC inteiro em torno de agentes. Pillar one: desenvolvimento baseado em specs. Tudo — produto, tech, UI, specs de teste — vive em repositórios com version control. Páginas do Confluence não funcionam porque agentes precisam de contexto estruturado e sempre atual. Resultado: times prototipam mockups de UI em 30 minutos em vez de semanas. O segundo pilar quantifica onde agentes pertencem — essa divisão 15-80. A arquitetura combina microsserviços tradicionais com endpoints de agente expostos via Model Context Protocol. Cada agente tem permissões delimitadas e uma única responsabilidade. Um agente de code review não implementa mudanças. Um agente de testing não toca produção.
O terceiro pilar — e o mais negligenciado — é onde o gap se revela. A Harness especifica seis camadas de teste. A quinta — monitoramento contínuo de eficácia em produção — é a mais pulada e a mais dolorosa. Troque um system prompt, atualize uma base de conhecimento, ou mude a versão do modelo: a qualidade do output do agente degrada silenciosamente sem um harness de monitoramento observando.
A Forrester encontrou que ganhos de codificação de 30 a 40 porcento frequentemente se traduzem em menos de 10 porcento de ganho de produtividade para o time inteiro quando planejamento, testes e pipelines de release continuam manuais. Os gargalos se deslocam — não desaparecem.
O quarto pilar são Operational Readiness Reviews do playbook de hyperscaler — imediatamente após design review, não desenvolvimento. Com tiers de severidade aplicados: itens high bloqueiam o launch, medium precisam ser resolvidos em 90 dias, low vão para o backlog. Post-launch, times de serviço se reúnem semanalmente para revisar saúde de data-plane e control-plane.
Dado esse quadro — agentes com autonomia real em 15 porcento das tarefas, benchmarks que encolhem sob escrutínio independente, monitoramento que a maioria das equipes ainda não tem — a pergunta que fica é: onde o controle deve viver?
A Cloudflare publicou uma resposta formal para isso: o Agent Access Model — um framework de segurança e autorização que trata agentes de IA como entidades de infraestrutura de primeira classe, não como extensões de identidade humana. A premissa é uma regra: não confie na execução. Autorize cada ação contra a tarefa e seu estado acumulado.
Os controles existentes falham em quatro pontos específicos com agentes. Primeiro: credenciais sobrevivem às tarefas. Service accounts foram projetados para software de longa duração — carregam escopos amplos, chaves de longa duração, ciclos de rotação raros. Aplicado a um agente de curta duração, essas credenciais sobrevivem ao trabalho para o qual foram emitidas e ficam em memória, logs e variáveis de ambiente onde podem ser re-executadas. A correção da Cloudflare: o tempo de vida da credencial deve corresponder ao tempo de vida da tarefa — para um agente, isso frequentemente é minutos.
Segundo: agentes operam na velocidade da máquina. Detecção de anomalias sintonizada para atividade humana reage devagar demais. Um agente com conexão de banco de dados e um caminho de rede de saída pode ler uma tabela e enviar via POST para um endpoint externo antes de um controle sintonizado para humanos terminar de amostrar. Terceiro: o prompt não é um perímetro. Instruções como "não acesse produção" moldam o comportamento mas não enforçam acesso — e um modelo pode ser manipulado por conteúdo injetado nos dados que ele lê.
Quarto: agentes compõem autoridade através de saltos de delegação. Quando um agente invoca uma ferramenta que invoca outro agente que chama uma API em nome do humano original, a resposta para "quem é esse e o que ele pode fazer" desaparece em algum lugar da cadeia. A resposta do AAM: cada ação é avaliada contra três critérios — quem é o agente, qual tarefa ele foi autorizado a executar, e quais recursos o grafo já tocou. Esse estado acumulado só pode reduzir o conjunto de capacidades restantes — uma catraca que estreita, nunca amplia.
A comparação que a Cloudflare usa é precisa: o BeyondCorp removeu a confiança implícita da rede. O AAM remove a confiança implícita do grafo de execução de tarefas.
"A boundary you can talk your way past is not a boundary."
Enforcement pertence ao harness que media tool calls e à camada de rede que media pacotes — não ao instruction set do modelo. A Cloudflare também lançou infraestrutura concreta: o Agents SDK agora inclui MCPClientManager com fluxo completo de OAuth 2.1 — redirect para login, geração de code challenges, troca de authorization codes por access tokens, e namespacing de ferramentas para evitar colisões. Durable Objects, a primitiva de computação stateful que serve de âncora de identidade para agentes, foi movido para o tier gratuito. E lançaram signed agents — uma extensão do programa de verified bots que usa assinaturas HTTP de Web Bot Auth para autenticar criptograficamente tráfego de agentes na camada de rede. O primeiro grupo: ChatGPT agent, Goose do Block, Browserbase e Anchor Browser.
Enquanto a Cloudflare resolve identidade no nível da rede, a LangChain publicou a arquitetura de referência para o agente SRE autônomo que eles rodam em produção no próprio Kubernetes da empresa. Eric Johanson, Deployed Engineer da LangChain, escreveu o walkthrough completo. E o número mais importante não é de capacidade — é de custo.
95 a 99 porcento de redução de custo por verificação agendada. Sem perda na detecção de problemas.
A arquitetura anterior rodava o orquestrador completo — aproximadamente 20 chamadas de modelo — a cada ciclo agendado, mesmo quando o cluster estava saudável. A mudança: coleta de estado em Python puro mais uma única chamada ao Claude Haiku com uso forçado de ferramenta. Isso gera um relatório de saúde estruturado entregue no Slack, ordenado por severidade. Poder total do agente — fan-out paralelo para seis subagentes especialistas: pod-inspector, scaling-analyzer, performance-analyzer, log-analyzer, security-auditor, reliability-auditor — só dispara em investigações sob demanda. A inversão certa.
O split estrutural de read/write é o que torna o HITL genuíno. Read e write são codebases distintas. As ferramentas de escrita existem apenas dentro de um único subagente change-executor, atrás de um interrupt gate. O orquestrador literalmente não tem caminho para um write tool. RBAC in-cluster espelha o split: read cluster-wide, write com escopo restrito. O agente pode ler qualquer namespace. Não pode tocar um recurso sem aprovação humana da ação proposta específica via Slack — usando Socket Mode, um WebSocket de saída, sem nenhum endpoint de entrada exposto.
Johanson é direto sobre a questão de quais write tools incluir: HITL só protege produção quando o humano pode genuinamente avaliar o que está aprovando. Escalar um deployment para 3 réplicas é legível. Um `helm upgrade` reescreve dezenas de recursos invisíveis no momento de aprovação — então foi deliberadamente excluído apesar de ser operacionalmente útil. Coarse, high-blast-radius tools ficam de fora independentemente da utilidade.
Para fechar o bloco de agentes, a Brex publicou o padrão que separa lógica de workflow de runtime para unificar evals e produção. Um time de cinco engenheiros TypeScript construiu a abordagem porque seus agentes rodam por uma hora através de dezenas de chamadas de LLM — tornando drift entre eval e produção caro e arriscado.
O problema é estrutural. Frameworks como LangGraph e Mastra expressam orquestração diretamente nos próprios SDKs. A lógica de orquestração e o framework são o mesmo artefato. Para fazer eval da lógica, você roda o framework. Para entregar, você roda o mesmo framework. Não existe versão da orquestração independente do runtime. A abordagem antiga da Brex: reimplementar agentes em um runtime de eval separado — duas cópias da mesma lógica, garantidamente divergindo com o tempo.
A solução: escrever o workflow como lógica de negócio pura sem conhecimento de onde vai rodar, e injetar um adapter de runtime no momento da execução. Em produção, o adapter conecta ao Temporal Cloud via workers no Kubernetes da Brex. Em evals, conecta a um runner in-process leve na plataforma de eval interna. LLM calls roteiam através do Vercel AI SDK para um LLM Gateway interno que centraliza rate limiting e auth. Uma única versão da orquestração existe — o que passa pelo eval é exatamente o que vai para produção.
O enforcement é arquitetural, não disciplinar. O time construiu a restrição no próprio build system: se um desenvolvedor escreve código de orquestração dependendo de features específicas do runtime, o build falha. Mas o custo é real — orquestração perde acesso direto a primitivas nativas do runtime. Toda nova capacidade além do denominador comum precisa ser re-exposta através da interface agnóstica. Esse padrão só compensa se a equipe genuinamente precisa tanto de durabilidade de produção quanto de eval offline rápida no mesmo caminho de código. Times com agentes curtos ou tolerando implementações separadas não devem pagar esse custo.
Agentes sob escrutínio — 15 porcento de autonomia real, identidade no ciclo da tarefa, arquitetura que enforça e não apenas instrui. Agora vamos para onde os dólares estão indo de verdade.
A AMD reportou Q2 de 2026. Revenue de data center: 6,7 bilhões de dólares. Crescimento de 107 porcento ano a ano, a partir de 3,2 bilhões um ano antes. Sequencialmente: de 5,8 bilhões no Q1 para 6,7 bilhões no Q2. Data center agora representa 58 porcento da receita total da AMD. Revenue total: 11,54 bilhões — 50 porcento de crescimento ano a ano, batendo o consenso LSEG de 11,28 bilhões. Non-GAAP EPS: 1,66 contra estimativa de 1,62.
Para colocar em perspectiva: a receita do Q3 de 2026, guiada em 13 bilhões de dólares, vai ser igual a toda a receita da AMD no fiscal 2023 — em um único semestre.
Lisa Su guiou que a receita de data center vai dobrar de novo em 2027 — e que server revenue vai crescer mais de 80 porcento ano a ano no segundo semestre de 2026. AWS, Microsoft, Google e Oracle expandiram deployments de EPYC no trimestre. O Helios — sistema rack-scale da AMD integrando CPUs, GPUs e networking — começou a ser entregue para Meta, OpenAI e Oracle esse trimestre, com ramp volumétrico esperado no Q4. A Anthropic fechou acordo para deploy de até 2 gigawatts de Instinct GPUs em sistemas Helios num pacto multianual.
O CapEx da AMD triplicou em quatro trimestres: 808 milhões no Q2, partindo de 282 milhões um ano antes e 389 milhões no Q1. Pré-build de capacidade antes da demanda chegar. A ação caiu de 5 a 10 porcento no after-hours apesar de bater top e bottom line — alguns analistas tinham modelado guidance de Q3 em até 14 bilhões. Para operadores avaliando estabilidade de supply, esse movimento é ruído. O que importa: a aceleração sequencial de data center e a lista de clientes do Helios.
E há uma peça faltando no stack para servir inferência a custo otimizado — e a Taalas vai tentar fechar isso. Em 6 de agosto de 2026, a AMD anunciou acordo definitivo para adquirir a Taalas, startup de Toronto que grava pesos de modelos de IA diretamente em silício. Os termos não foram divulgados. O time — co-fundado por Ljubisa Bajic, ex-CEO da Tenstorrent e ex-executivo da AMD, junto com COO Lejla Bajic e CTO Drago Ignjatovic — vai se juntar ao grupo de IA da AMD sob Vamsi Boppana.
O mecanismo do chip HC1: fixa o dataflow do modelo e queima os pesos em mask-ROM. SRAM separada lida com KV cache e adapters de fine-tuning. No Llama 3.1-8B, entrega mais de 16 mil tokens por segundo por usuário — múltiplos do que GPU atual alcança. Um time de 24 pessoas construiu o HC1 com 30 milhões de dólares. Depois levantaram 169 milhões em fevereiro de 2026. Total de funding: 219 milhões.
O trade-off é claro: o HC1 roda exatamente um modelo. Trocar modelos exige dois novos máscaras de metal via tooling proprietário — em torno de dois meses. O HC2, previsto para esse verão, suporta 20 bilhões de parâmetros por chip. Um modelo de um trilhão de parâmetros mapearia para aproximadamente 50 aceleradores — dentro da capacidade do rack Helios. O DeepSeek-671B no HC1 exige 30 tape-outs, mostrando por que a tecnologia serve modelos deployed estáveis, não weights de fronteira em iteração rápida.
A lógica de integração é inferência desagregada: Instinct GPUs fazem prefill — o processamento compute-intensivo de prompt — e aceleradores Taalas fazem decode, a geração de tokens. A AMD já anunciou solução similar com a Cerebras em 23 de julho no evento Advancing AI 2026. A Taalas poderia deslocar a Cerebras para modelos menores estáveis.
Mas aqui preciso fazer um pushback no enquadramento otimista. Em um mercado onde os melhores modelos mudam em escala de semanas, o custo de oportunidade de dois meses de re-spin para trocar modelos é real. A AMD está apostando que existe uma classe grande de workloads onde modelos não mudam — code assistants, document extraction, transcrição em tempo real. Pode estar certa para verticais específicas. Mas esse não é o padrão da fronteira.
É uma aposta de vertical versus horizontal. E que nos leva ao custo escondido que fica embaixo de qualquer cluster de GPU — independente de qual silício está rodando.
A SpaceX gastou 295 milhões de dólares em Megapacks da Tesla no Q2 de 2026. Total do primeiro semestre: 329 milhões de dólares.
Cada Megapack armazena mais de 3,9 MWh. Mais de 420 unidades implantadas fornecem cerca de 1,6 GWh de capacidade de bateria — suficiente para absorver picos do cluster de GPU sem sobrecarregar a rede regional. No Colossus 1, 208 Megapacks foram implantados antes de a subestação permanente do Memphis Light, Gas and Water entrar em operação. Essa subestação levou 97 dias para ser construída — contra 2,5 anos no processo normal.
O Colossus está mirando aproximadamente 580 mil GPUs NVIDIA: 520 mil GB200s, 30 mil GB300s e 30 mil H100/H200s — em capacidade de 2 gigawatts. A configuração GB200-NVL72, com 72 GPUs por rack, implica cerca de 8 mil racks no deployment completo. Infraestrutura total — prédios, energia, resfriamento, rede, mais de 420 Megapacks — chega a 35 a 40 bilhões de dólares.
Musk na call de Q2: "Nossa meta tentativa é ter 20 gigawatts de potência e resfriamento online até o final do próximo ano." Depois ele mesmo ajustou: "Eu esperaria algo próximo a 15 gigawatts no nível da usina." A SpaceX se comprometeu com 2,8 bilhões para construir infraestrutura própria de gás natural, reduzindo dependência de contratadores de turbina terceiros.
A receita de lease cobre tudo com margem. A Anthropic paga 1,25 bilhão por mês pelo Colossus 1 até maio de 2029 — 40 bilhões no total. O Google alugou 110 mil GPUs do Colossus 2 a 920 milhões por mês até junho de 2029. Leases combinados: 2 bilhões mensais. A conta de energia de 90 a 160 milhões de dólares anuais representa menos de 1 porcento da receita anual de lease. Os Megapacks são marginais no P&L — mas são a camada de estabilidade de grid que torna clusters acima de 50 megawatts operacionalmente possíveis.
E embaixo de tudo isso — do Colossus, dos racks Helios, dos Instinct GPUs — tem uma guerra de memória que vai determinar quem controla o gargalo de latência dos próximos cinco anos. A Samsung apresentou o roadmap completo de memória no Future of Memory and Storage Summit em Santa Clara. O problema central que Leno Park, VP de flash solutions da Samsung Electronics, colocou na mesa: clusters de IA hoje suportam cerca de 100 tokens por segundo por usuário. A Samsung está projetando para 1.000 tokens por segundo até 2030 — 10x de throughput.
O HBM4E é o próximo deliverable concreto. Amostras enviadas em maio, avaliação ativa por parceiros do ecossistema. Usa base die de 4 nm, aumenta a contagem de TSVs em aproximadamente 4x, e emprega packaging avançado com mais de 300 mil microbumps em pitches mais apertados. Resultado: 4 terabytes por segundo de bandwidth e 64 GB de capacidade em um único stack de 16 camadas, a 16 Gbps por pino — mais de 20 porcento mais rápido que o HBM4. Para gerenciar concentração térmica em stacks densos, a Samsung adicionou um heat pipe block — uma "chaminé" colocada diretamente sobre hot spots no stack.
O HBM5 muda para base die de 2 nm com tecnologia gate-all-around, encurtando comprimentos de canal de interposer para melhorar sinalização I/O. Aí vem o zHBM — que colapsa o layout 2.5D atual. O acelerador de IA senta diretamente acima do stack de HBM como uma estrutura 3D unificada, cortando a distância física entre processador e memória. A Samsung afirma que a interface de próxima geração pode entregar 8x a performance do HBM5, mais de 10x densidade de memória, 3x eficiência energética, e menos da metade da resistência térmica.
Mas chegar nesses números exige co-design próximo com parceiros de acelerador — limitando adoção a vendors dispostos a compartilhar dados de design no nível de die e coordenar packaging. HBM4E a 4 TB/s e 64 GB por stack está disponível para avaliação agora. HBM5 e zHBM permanecem itens de co-design — fatore essa incerteza em qualquer build de cluster além de 2027.
E a receita de HBM da Samsung sinaliza a urgência do próprio mercado: vendas de HBM vão mais que triplicar em 2026 versus 2025, e atingir 50 porcento da receita total de DRAM até 2030. A questão estrutural é se o zHBM com integração 3D co-projetada chega em tempo e com yields que o tornam utilizável para decisões de procurement — e não apenas slides de roadmap.
Para fechar o bloco de silício, há uma última peça — sobre o que acontece quando você tem o hardware certo mas não o kernel certo para extrair performance dele. Em 4 de agosto de 2026, o Cursor open-sourcou o Mixture-of-Kittens — MoK — um megakernel que aumentou o throughput de treinamento end-to-end em 1,41x em 512 GPUs GB300. No mesmo dia, o Latent Space publicou argumentos de por que megakernels são obsoletos. A colisão clarificou uma tensão real.
O caso contra: megakernels eliminam overhead de launch de kernel e lag de sincronização entre kernels, mas escrevê-los é difícil. Por-kernel tuning mais overlap de scheduler frequentemente supera um kernel monolítico fusionado porque cada componente pode ser otimizado independentemente. A NVIDIA está resolvendo sincronização em hardware: o Rubin introduz triggers de dependência em nível de tile, permitindo que o kernel N+1 lance CTAs para um tile assim que o kernel N terminar — sem esperar por stragglers. Isso é o que megakernels faziam em código CUDA.
O Cursor argumentou o oposto para camadas MoE em racks NVL72. MoE consome mais da metade do tempo de treinamento end-to-end. Um GB300 NVL72 é 72 GPUs em um único domínio NVLink — topologia de comunicação qualitativamente diferente de um cluster DGX. CPUs Grace integrados são lentos relativo às GPUs: GPU streams regularmente esperavam por trabalho de CPU — logging, métricas. Apenas um megakernel pode eliminar sincronização CPU-GPU por completo; kernels individuais não conseguem.
Os números do MoK: MXFP8 forward corre 2,37x mais rápido que o melhor baseline público — DeepEP mais TransformerEngine, HybridEP mais Megatron — com grau de EP 64 e 2.048 tokens por GPU. BF16: 1,92x. End-to-end em 512 GPUs: tokens por segundo por GPU subiram de 760,9 para 1.070,2 — ganho de 1,41x. Dispatch baseado em pull atinge 29 porcento mais utilização de bandwidth NVLink sob expert imbalance versus push-based. Latência de sinalização caiu de 103 microssegundos para 18.
A restrição: MoK exige NVIDIA Blackwell SM100 ou SM103 — especificamente GB200 NVL72 ou GB300 NVL72 racks. Precisa de CUDA 13.0 ou superior, PyTorch 2.10 ou superior, Python 3.12 ou superior. Roda em H100 ou B200 DGX nodes vai falhar no build. O projeto é Apache-2.0 e já alimenta o treinamento do modelo Composer do Cursor em dezenas de milhares de GPUs. Em clusters commodity e hardware Rubin, kernel-splitting mais CTA scheduling em hardware é cada vez mais viável com fardo de manutenção muito menor — sem 67 mil linhas de forward pass fusionado para debugar. Em racks NVL72, onde o gargalo de CPU Grace e topologia NVLink criam restrições distintas, fusão ainda vence por uma margem que justifica o custo de engenharia.
Silício com receita que dobrou, bateria em bilhões para estabilizar clusters, memória disputada camada a camada. Agora a última pergunta: quem controla o gateway por onde todo esse poder flui?
A Together AI respondeu com dados concretos. Eles colocaram o DeepSeek-V4 Flash 0731 e o GPT-5.6 Luna frente a frente no DeepSWE — 113 tarefas reais de código de longo horizonte em repositórios open-source ativos, quatro tentativas por tarefa, corrigidas por suite de testes oculta.
Luna é o melhor engenheiro. Pass@1: 67,2 porcento contra 53,3 do DeepSeek. O gap se mantém em cada contagem igual de tentativas: 81,6 porcento contra 70,1 em k=2, 90,3 porcento contra 80,5 em k=4. Luna também roda mais rápido: 16 minutos de mediana contra 23, 92 passos contra 148, e produz menos: 70 mil tokens contra 104 mil. Em qualidade bruta de tiro único, não é uma corrida próxima.
Mas o custo inverte a história. DeepSeek custa 10 centavos por tentativa. Luna: 61 centavos — diferença de 6x. Isso entrega 532 tarefas resolvidas por 100 dólares no DeepSeek, contra 110 da Luna. Concretamente: o pass@2 do DeepSeek — 70,1 porcento — já bate o pass@1 da Luna — 67,2 porcento — e duas tentativas do DeepSeek custam 20 centavos. Um terço de uma única execução da Luna.
A cascata é a resposta prática. Rodar o DeepSeek primeiro e escalar para Luna apenas em falha atinge 78,9 porcento de precisão a 38,5 centavos por tarefa — mais preciso que Luna sozinha, e 37 porcento mais barato.
Tem um detalhe que a maioria das análises perdeu: quando o DeepSeek falha, ele quebra a suite de testes existente do repositório em 9 porcento dos casos. Luna faz isso em 15 porcento. O modelo mais caro tem maior probabilidade de corromper código que funcionava. Deployments de Luna precisam de gates de regressão completos. DeepSeek precisa menos.
E há segmentação clara por domínio. Luna vence 7 de 8 domínios de tarefas. As maiores margens: análise de programa — 69 porcento de Luna contra 33 do DeepSeek. Concorrência e durabilidade — 70 contra 38. Internos de runtime de linguagem — 86 contra 59. Gaps de 30 pontos em trabalho de raciocínio. O DeepSeek vence em um único domínio: query e config languages — 78 contra 70. SQL builders, window functions, keyset pagination, parsers de config.
JavaScript é um precipício para o DeepSeek: 35 porcento contra 60 da Luna. Se seu stack de agente toca JavaScript, DeepSeek é falsa economia. Se vive em config, query ou Rust — onde o DeepSeek chega a 55 porcento contra 60 da Luna — o gap fecha e a cascata faz sentido.
Open weights deixou de ser experimento e virou linha de orçamento. O próximo passo é que alguém controle o gateway por onde essa roteação passa. E três movimentos esta semana definem onde esse gateway vai viver.
O primeiro: a Microsoft colocou o AI Gateway tier do Azure API Management em public preview em 27 de julho de 2026, disponível em East US 2 e Sweden Central sem custo enquanto o preço é determinado.
A mudança estrutural não é sutil. O control plane do novo tier é organizado em torno de modelos, servidores MCP e ferramentas — não APIs. É uma separação estrutural do approach de policy-layering dos tiers clássico e v2, que retêm suas capacidades inalteradas. O gateway roteia baseado em match exato do campo `model`. Todos os provedores compatíveis com OpenAI compartilham um caminho de endpoint; cada modelo publicado precisa de um nome único. Anthropic corre através de um custom provider com passthrough da Messages API. O gateway provisiona em cerca de um minuto sem unidades de escala para planejar.
A federação de ferramentas estende o mesmo padrão para a camada MCP. Times podem expor um servidor MCP existente via SSE ou Streamable HTTP, converter operações de REST API em um servidor MCP fazendo upload de um spec OpenAPI, ou usar mais de 1.400 ferramentas baseadas em conector da Power Platform e Logic Apps — sem hospedar um servidor. Múltiplos servidores MCP federados atrás de um único endpoint, então um agente conecta uma vez e resolve ferramentas em todos eles. Autenticação por backend suporta API keys, OAuth 2.0 client credentials, managed identity e mTLS.
A governance roda em policy cards no portal como propriedades JSON — não as expressões XML que veteranos do APIM conhecem. Cobre limites de request e token, quotas, Azure AI Content Safety e fallback para modelo secundário. Telemetria flui como métricas OpenTelemetry com convenções semânticas GenAI para Application Insights, Datadog, Splunk, Grafana Cloud ou qualquer endpoint OTLP que o cliente controla. O recurso roda na própria subscription e tenant Entra do cliente.
Mas há um ponto de atenção concreto no modelo de acesso. A runtime key tem escopo de gateway — alcança todos os modelos e todas as ferramentas publicadas naquele gateway. A guidance da Microsoft é uma chave por aplicação, mas uma chave vazada tem blast radius do gateway inteiro, não de um produto específico. Times que confiavam no scoping de subscriptions do APIM para limitar consumidores a APIs específicas precisam redesenhar essa fronteira completamente.
E há um status de preview que não pode ser ignorado: sem SLA, APIs e limites podem mudar antes do GA, regiões são East US 2 e Sweden Central por enquanto, e — mais significativo — o preço não está anunciado. O argumento central de governance de custo fica sem resolução até o preço ser definido.
O segundo movimento: a Cloudflare unificou cinco primitivas — Workers AI, AI Gateway, Vectorize, R2 e Browser Run — em um namespace único de AI Search. Um comando `wrangler ai-search instance create` aponta para uma URL de fonte, lida com crawling via Browser Run, chunking, embedding e armazenamento vetorial em um único passo. Para sites sem sitemap, o flag `--parse-type discover` segue links para encontrar páginas.
O Dev Stack MCP da Cloudflare demonstra o deploy: 10 superfícies — Docs, Blog, API Docs, Comunidade, Astro, Vite, Vitest, Hono, Replicate e OpenNext. Cada uma com uma instância de AI Search. Um único binding no wrangler.jsonc deixa um Worker fazer uma chamada `AI_SEARCH.search()` que faz fan-out para as 10 simultaneamente. Resultados retornam como `res.chunks` com metadata de citação e tags de instância, com reranking habilitado e até 10 resultados por chamada. Embedding e reranking custam zero por token quando usando modelos Workers AI designados — eliminando o overhead operacional de prever contagens de tokens para workloads de busca com volume de queries imprevisível.
O terceiro movimento — e o mais estrutural — é o MCP V2. A maior revisão do Model Context Protocol desde o lançamento chegou em 28 de julho de 2026. O protocolo agora registra 400 milhões de downloads mensais de SDK — crescimento de 4x em um ano, impulsionado por pressão do ecossistema para rodar servidores em infraestrutura HTTP padrão.
A mudança central: remoção do handshake initialize/initialized e do header Mcp-Session-Id. Seis SEPs convergiram em um único design — cada request carrega versão do protocolo, identidade do cliente e capacidades inline. Qualquer instância de servidor pode lidar com qualquer request. Sticky sessions, session stores e lógica de stream-hold desapareceram na camada de protocolo. O Agents SDK da Cloudflare embarcou suporte imediatamente — a nova primitiva é `createMcpHandler` rodando em um Worker comum. A Amazon Bedrock AgentCore Gateway habilitou via uma única chamada de API UpdateGateway. SDKs atualizados em TypeScript, Python, Go e C# v2.0 foram entregues junto com a spec.
Três upgrades de infraestrutura seguem a statelessness. Roteabilidade: novos headers Mcp-Method e Mcp-Name permitem que load balancers roteiem tráfego sem inspecionar o body JSON — mismatch de header retorna erro HeaderMismatch. Cacheability: respostas de list e resource carregam campos ttlMs e cacheScope modelados no HTTP Cache-Control. Traceability: W3C Trace Context propaga por nomes de chave fixos em `_meta`, habilitando rastreamento distribuído compatível com OpenTelemetry através de SDKs e gateways sem instrumentação customizada.
Mas a migração de elicitation é o ponto duro — a breaking change real da spec. Quando um servidor MCP precisava de input no meio de um request — aprovação antes de um deploy, confirmação de billing — o protocolo antigo mantinha um stream aberto. O novo spec introduz Multi Round-Trip Requests: o servidor retorna `input_required` com o que precisa, o cliente coleta a resposta, e a operação é retentada com esse input. Sem sessão preservada entre rounds. Times usando elicitation server-initiated não conseguem fazer upgrade com um bump de SDK — o modelo de interação exige reescrita de código.
A extensão Tasks foi promovida de experimental para oficial. O lifecycle é stateless por design: tools/call retorna um handle de tarefa, e clientes conduzem progresso via tasks/get, tasks/update e tasks/cancel. O método tasks/list foi removido — sem sessões, enumerar tarefas ativas não é uma operação segura para expor. Roots, Sampling, Logging e transporte SSE entram em um clock de 12 meses de depreciação a partir de 28 de julho — remoção mais cedo possível em 28 de julho de 2027.
Para fechar o bloco — e a edição — a NVIDIA liberou o Alpamayo 2 Super para uso comercial sob licenciamento OpenMDW-1.1. Um modelo open-weights de 34 bilhões de parâmetros construído para percepção, planejamento e data workflows de robotaxi e veículos autônomos. Primeiro lançamento da família Alpamayo que permite deploy em produção sem permissões adicionais da NVIDIA.
A arquitetura combina um Cosmos 3 Super Reasoner de 32 bilhões de parâmetros com um Action Expert difusivo de 2 bilhões, pós-treinado com reinforcement learning. O score no benchmark LingoQA de raciocínio para direção autônoma: 79,2 — primeiro lugar entre 37 modelos avaliados. Margem de 17 pontos sobre o Qwen2.5-VL de 72 bilhões de parâmetros, que tem o dobro dos parâmetros. 15,1 pontos sobre o Gemini 2.5 Pro. 23,2 pontos sobre o GPT-4o.
Em simulação closed-loop AlpaSim — 910 cenários reais reconstruídos — o modelo atinge score de 1,50 ± 0,13. Quase o dobro do 0,81 ± 0,01 do Alpamayo 1.5 de 10 bilhões de parâmetros. Trajetória: minADE_6 de 0,911 metros sobre um horizonte de 6,4 segundos em 1.434 amostras. O corpus de treinamento inclui aproximadamente 115 mil horas de vídeo de direção multi-câmera e 3,7 milhões de traces de raciocínio.
Os 34 bilhões de parâmetros tornam o Alpamayo 2 Super um workload de inferência em nuvem. O modelo que vai dentro do carro é um derivativo destilado — o score do benchmark é o teto do modelo teacher, não a spec de runtime para o veículo. Mas a licença OpenMDW-1.1 cobre fine-tuning, modelos derivados e redistribuição comercial — e modelos destilados derivados do Alpamayo 2 Super não carregam condições de licença adicionais. Isso remove um bloqueio legal comum para programas de AV que querem construir stacks proprietárias em fundações abertas. O pipeline de auto-labeling comprime ciclos de anotação de meses para dias.
A família Alpamayo acumulou 400 mil downloads no Hugging Face desde o lançamento no CES 2026. E a família inteira foi retroativamente relicenciada sob OpenMDW-1.1.
A pergunta que fica para o CTO no final desta edição é a mesma que abre o segundo bloco: seu roadmap de inferência assume o preço de 2025 ou o stack de 2027? Porque quem controla o gateway — cloud provider, CDN ou stack próprio — controla o custo. E a maioria ainda não tomou essa decisão.
A semana provou que autonomia é um número, não uma promessa. Quinze porcento. Esse é o teto que a engenharia honesta coloca na autonomia de agentes hoje — e cada dado desta edição orbita essa fronteira. O Wire de segunda começa pela conta que a Meta escondeu no ranking de dois estágios do Instagram — e o que ela ensina sobre alocar compute em pipelines de ranking. Até lá.