A edição em que a camada abaixo do modelo virou o problema

É a fatia das queries internas da Anthropic que já roda via Claude — não via SQL. E a empresa que faz o modelo decidiu, em silêncio, que o BI tradicional acabou.

A Palana é a resposta da Grab. Uma plataforma de execução Kubernetes-nativa, hoje rodando centenas de agentes em produção — desde ambientes de desenvolvimento remoto até automações no Slack, agentes Hermes e workers do OpenClaw. O design parte de uma premissa radical: trate o agente como hostil por padrão.

E merece ser. Quando um agente pode executar ferramentas arbitrárias, chamar APIs externas e escrever código, o modelo de risco é completamente diferente de um serviço stateless. A Grab listou explicitamente as ameaças no escopo: injeção de prompt, hijacking de lógica, comprometimento de dependência, busca excessiva de objetivos, exposição de credenciais. Isso não é paranoia — é threat modeling sério para quem opera fintech em produção.

Cada agente roda em seu próprio namespace Kubernetes, com RBAC restritivo, quotas de recursos, network policies customizadas e service accounts isoladas. Mas o detalhe mais elegante é o tratamento de credenciais. Tokens de controle de versão, chaves de API do model gateway — ficam no HashiCorp Vault e nunca chegam ao container do agente. O agente recebe apenas placeholders abstratos. Quando inicia uma chamada externa, um proxy seguro intercepta, valida o destino e substitui o placeholder pela credencial real. O segredo nunca toca a memória de execução nem os logs do container.

O kill switch segue a mesma filosofia. Perguntar para um agente parar é uma feature — não um controle de segurança. Um agente comprometido não pode ser confiado para se auto-encerrar. Os kill switches da Palana operam no control plane: network policies são desativadas diretamente de fora do runtime, e um reaper externo cuida dos shutdowns por idle sem tocar no processo do agente.

Essa é exatamente a questão do saga rollback. A Cloudflare entregou em 25 de junho uma resposta elegante: você declara a lógica de compensação diretamente dentro da definição do step. Não no catch block — no step em si.

O catch block acumula estado. Conforme o workflow evolui, o código de compensação fica fora de sincronia com o forward path. Com o padrão saga da Cloudflare, o rollback vive ao lado da operação que precisa desfazer. Você passa um objeto options para step.do() com a função de rollback. Ela recebe o output do step forward — mas deve tratar output igual a undefined, porque um provedor de pagamento pode capturar uma cobrança antes que a confirmação chegue ao Workflows. O step falhou, mas a transação já foi processada. O rollback ainda roda.

Fica sutil. Steps sequenciais fazem rollback em ordem reversa — simples. Steps paralelos completam em ordem imprevisível, então o Cloudflare ordena pelo momento de início reverso, não pelo momento de conclusão. Isso torna a sequência determinística independente de qual branch terminou primeiro. Crítico quando dois steps paralelos escrevem em recursos compartilhados que precisam ser desfeitos em sequência específica.

A API tem quatro argumentos: model factory, lista de tools, special instructions e caminho da cuga_folder. Você chama await agent.invoke() e o harness cuida do loop de planejamento, execução, despacho de ferramentas, rastreamento de estado e um passo de reflexão que detecta tool calls ruins e replana sem expor a falha ao usuário. Num task de 20 steps, a maioria dos harnesses perde o rastro de resultados intermediários. O CUGA os mantém num variable manager na camada de orquestração.

Em produção isso importa muito. A maioria dos harnesses bake o tradeoff custo-performance no código do agente. Mudar exige reescrita. No CUGA é uma chave em settings.toml. A galeria hospedada roda no gpt-oss-120b via Groq — não numa API frontier — porque modelos open weight custam oitenta a noventa por cento menos que alternativas fechadas, segundo a própria IBM.

Quatro tiers de isolamento: process isolation para workloads leves e sensíveis a latência, session isolation que separa o agente do desktop interativo e do clipboard do usuário, micro-VMs via Hyper-V para código de maior risco, e containers Linux via WSL para toolchains de ML. O GitHub Copilot CLI já usa o tier de process isolation para restringir código gerado dinamicamente.

Filtro de rede de saída não funciona na versão atual. Isso é um gap sério — comprometimento de agente tipicamente se manifesta como exfiltração de dados para endpoints do atacante. A própria documentação da Microsoft afirma que os perfis MXC não devem ainda ser tratados como fronteiras de segurança. Equipes implantando agentes em ambientes regulados precisam adicionar controles de rede explícitos em cima do MXC, e tratar o SDK como primeira camada de controle, não como limite de segurança.

Os dados são do TrendForce, reportados pelo Tom's Hardware. E a causa não tem nada de nostálgico. Samsung, SK Hynix e Micron redirecionaram capacidade de wafer para HBM e DRAM de servidor para alimentar a infraestrutura de IA. O Micron declarou uma taxa de conversão de três para um: cada slot de ramp de HBM aposentou três slots de DDR5. À medida que a DRAM de servidor absorveu a produção das fabs, o DDR4 apertou. OEMs e ODMs passaram a especificar DDR3. Alguns designs DDR3 foram refeitos para usar DDR2. A cascata chegou até o fundo da pilha de memória legada.

Isso diz tudo sobre o estado atual do mercado. A hierarquia normal de preços quebrou. O CEO da MediaTek, Rick Tsai, colocou de forma direta no ISSCC em fevereiro: memória representa cerca de cinquenta por cento do BOM total em desenvolvimento de XPU. O CFO da HP reportou no início de 2026 que memória e armazenamento subiram de quinze a dezoito por cento do BOM de PC para aproximadamente trinta e cinco por cento.

Nova capacidade significativa de DRAM não chega antes do final de 2027 no melhor caso. A fábrica nova do Micron no Idaho não fica operacional até 2027. Para qualquer stack de inferência que depende de equipamentos de rede de longa vida, controladores embarcados ou hardware de edge com specs de memória fixas: o impacto de capex já está chegando. Auditoria de BOM agora, não na renovação do contrato.

A mistura é 75% água e 25% propilenoglicol fluindo por cold plates diretamente sobre cada processador. O líquido entra a 45 graus e sai a cerca de 55 graus, tendo puxado a carga de calor da superfície do die. Porque o trabalho térmico acontece na fonte, o ar ambiente ao redor não precisa ser frio. A temperatura ambiente se desacopla dos termos do servidor, eliminando o layout de hot-aisle/cold-aisle exigido em instalações resfriadas a ar. O calor vai para dry coolers externos — grandes arrays de radiadores — onde é rejeitado para o ar externo sem perda de água por evaporação.

Data centers convencionais com torres de resfriamento consomem cerca de 2,6 milhões de galões de água por megawatt por ano. O design DSX reduz isso a próximo de zero — até 100% de redução — em climas onde o ar externo consegue fazer o trabalho de rejeição de calor sem chillers mecânicos. Ali Heydari, diretor de resfriamento e infraestrutura de data center da NVIDIA:

Chillers são necessários apenas cerca de 1% do tempo no ano na maioria das geografias. Para um operador de 50 megawatts, a economia combinada de energia de resfriamento e água passa de quatro milhões de dólares ao ano. A geração Rubin é 100% resfriada a líquido — cada chip, cada componente de rede, zero ventiladores em qualquer lugar no sistema. O que significa que qualquer provedor de cloud construindo sobre ela não tem escolha: a transição para liquid cooling é obrigatória.

Em regiões onde a temperatura do ar externo é persistentemente alta, a estimativa de 1% de uso de chillers se estende. Operadores em climas quentes precisam modelar perfis locais de bulbo úmido antes de remover a infraestrutura de resfriamento mecânico. O design de referência DSX é um blueprint, não uma garantia universal.

O framework roda modelos de 3 bilhões a 70 bilhões de parâmetros completamente no device, em iPhone, iPad, Mac e Apple Vision Pro, com zero dependências de servidor e zero custo por token. É o mesmo runtime que a Apple usa internamente para o Apple Intelligence, agora exposto a desenvolvedores terceiros. A API Swift é memory-safe e zero-copy. Compilação ahead-of-time compila os modelos uma vez e os carrega quase instantaneamente nas execuções seguintes.

850 milhões de parâmetros, quantização int4 simétrica por canal, redução de 3 gigabytes para 430 megabytes — 86% de redução de tamanho, com "perda mínima de acurácia" segundo a documentação da Apple. Equipes devem validar essa afirmação nos próprios eval sets antes de entrar em produção. O AFM Core Advanced — o modelo foundation da própria Apple — é um sparse MoE de 20 bilhões de parâmetros que ativa apenas 1 a 4 bilhões por inferência, seguindo a arquitetura do tipo DeepSeek. E o demo do teto: um modelo de 1 trilhão de parâmetros — o Kimi 2.6 — rodando distribuído em quatro Mac Studios via rede macOS Tahoe 26.2. Prova de conceito, não configuração de produção. Mas sinaliza onde a Apple quer chegar com orquestração multi-device.

Um comando. hf jobs run. GPU a10g-large, um dólar e cinquenta centavos por hora, faturado por minuto por uso de hardware. O servidor fala a API OpenAI Chat Completions, protegido por token HF — privado por padrão. O demo mais ambicioso: Qwen3.5-122B num flavor de dois H200 com tensor-parallel-size 2. A janela de contexto padrão do Qwen3.5-122B é de 256 mil tokens, o que esgota a VRAM nas configurações padrão do vLLM — é preciso limitar max-model-len e max-num-seqs antes de aumentar o flavor.

E a leitura que fica desse bloco inteiro: o capex de inferência está se partindo em dois extremos. Edge barata — um dólar e cinquenta por hora ou custo zero no device Apple. Cluster ultradenso — Rubin 100% líquido, rack ao limite de densidade. E a memória legada está comendo a margem no meio, sem alívio de capacidade antes de 2027.

Um LLM bruto apontado para um data warehouse responde corretamente 21% das perguntas de analytics. Esse é o número de partida. A equipe da Anthropic identificou três classes de falha. Ambiguidade de conceito-entidade: o termo "revenue" mapeia para 40 tabelas plausíveis no warehouse deles — a própria palavra não resolve o dado. Staleness: definições de métricas mudam diariamente, e a documentação que era 95% precisa no lançamento caiu para 65% em um único mês quando manutenção foi desprioritizada. E falha de recuperação: o dado certo existe, mas em um warehouse de um milhão de campos o agente passa direto.

Quatro camadas: fundações de dados com modelagem dimensional e testes shift-left; uma camada de sources-of-truth com definições canônicas de métricas e um grafo de conhecimento da empresa indexando docs, roadmaps e decision logs; uma camada de skills — pastas markdown que o Claude lê sob demanda, com cerca de 30 arquivos de referência por domínio descrevendo tabelas, colunas, joins e gotchas antes de qualquer SQL ser escrito; e uma camada de validação com suítes de eval em CI e revisão adversarial de cada resposta.

Seis por cento de ganho de acurácia. Trinta e dois por cento mais tokens. Setenta e dois por cento de aumento de latência. Esse é o custo real de cada ponto percentual acima de 95%. E o risco mais crítico não é o modelo — é o skill decay. Acurácia caiu de 95% para 65% em um único mês quando os arquivos de skill ficaram para trás das mudanças de schema. A solução: colocar os arquivos markdown de skill no mesmo repositório que os modelos de transformação dbt. O pull request que muda um modelo é o mesmo pull request que atualiza o skill. Noventa por cento dos PRs de modelo de dados agora incluem uma mudança de skill no mesmo diff.

Não automaticamente. A Anthropic está descrevendo o que funcionou com seu próprio modelo, seus próprios dados, e uma equipe que tratou manutenção de skills como disciplina de engenharia contínua. Um erro de 5% é inaceitável para reporting business-critical em muitos contextos — analytics financeiro, compliance, métricas de SLA. Isso não é um blueprint que você faz fork e deploya.

A Meta publicou um case study da infraestrutura de classificação de ativos que alimenta o stack de privacidade deles. A linha central é direta.

A Meta usa LLMs nos extremos — cold start de classificação, interpretação semântica a partir de contexto de código e documentação, raciocínio de política para casos que não correspondem a padrões conhecidos. Regras determinísticas lidam com o volume de produção porque são de baixa latência, repetíveis e auditáveis. E conforme os padrões se estabilizam, as decisões do LLM são destiladas em regras versionadas aprovadas por humanos.

Antes de chamar um LLM, o sistema monta um "evidence brief" — sinais de suporte, sinais contraditórios, metadados de proveniência e resolução de código. Resolução de código rastreia a fonte real de runtime do valor de um campo. Se o campo `age` em um pipeline de cache vem de um objeto de configuração de TTL, não de um perfil de usuário, esse rastreamento elimina toda uma classe de falsos positivos. Horas de otimização de prompt produziram ganhos marginais quando o modelo raciocinou sobre campos brutos e ruidosos. A correção foi estrutural — não era problema de prompt.

Adjudicação dos rótulos de referência e aprovação de promoções de regras. Uma nova regra que expande ou contrai o escopo de proteção de dados exige aprovação humana. O resto é automático. É o oposto de "humano no loop em tudo" — é concentrar accountability onde a consequência é real.

Databricks e NVIDIA open-sourcearam o Genesis Workbench: um stack de referência modular que conecta modelos de biologia acelerados por GPU diretamente na plataforma Databricks para descoberta computacional de fármacos. Genomics, análise single-cell, design de moléculas grandes, docking de moléculas pequenas e fine-tuning — cada um como módulo independente e deployável separadamente. Uma UI React point-and-click para que cientistas de bancada rodem pipelines completos sem tocar em código. Um único script para implantar o ambiente inteiro.

Predições de ligação com 94% de acurácia em 30 minutos. Compare com 48 horas com acurácia de aproximadamente 50% usando software padrão de fornecedor. Qualidade de candidatos melhorou de 25% a 50%. Identificação de leads acelerou em até 50%. Desenvolvimento de linhagem celular — normalmente de seis a oito meses — caiu para 2,5 meses usando NVIDIA VISTA-2D e Geneformer no BioNeMo. Esses são números de uma configuração específica num site específico — mas estabelecem o teto do que o stack consegue quando a governança de dados está apertada.

Sequências, bibliotecas de compostos e resultados de ensaio nunca saem do perímetro governado. Unity Catalog cuida do controle de acesso e auditoria. MLflow rastreia cada artefato de modelo. GPU Model Serving roda inferência dentro do próprio workspace do cliente. Adotar um modelo mais novo — GenMol, Proteina-Complexa — é um passo de deploy, não uma reescrita, porque cada modelo é um submódulo independente no mesmo substrato de registry e serving. E o Genesis Workbench expõe tudo isso como tools MCP — qualquer cliente compatível com MCP, incluindo o Claude, pode chamar os modelos e workflows como ferramentas.

A resposta que emerge não é "LLM ou não LLM." É uma triagem. LLMs onde a ambiguidade semântica é o problema real e o contexto estruturado não resolve sozinho. Regras determinísticas onde latência, auditabilidade e repetibilidade são não-negociáveis. E um caminho claro para distillar as decisões do LLM em regras conforme os padrões se estabilizam — com aprovação humana nas promoções que mudam escopo de proteção. O Genesis Workbench é a resposta para verticais regulados que precisam do modelo mas não podem enviar dados proprietários para fora do perímetro. A Meta é a resposta para escala. A Anthropic é o blueprint para quem está disposto a tratar manutenção de contexto como engenharia permanente, não como configuração inicial.