La semana en que autonomía de agente se convirtió en número medido—y la economía de silicio debajo de ellos cambió de dueño.
De 54 a 15 por ciento.
Eso es cuánto se redujo un benchmark de agente cuando un contribuidor independiente verificó la cuenta. Y 15 por ciento es exactamente el techo de autonomía que Harness impone en los agentes que ejecuta en producción.
Esta es la Edition de ai|expert. La semana en que autonomía de agente se convirtió en número medido—y la economía de silicio debajo de ellos cambió de dueño.
Comencemos con el número que nadie quería escuchar. Ponytail es una skill open-source con 82 mil estrellas en GitHub en menos de dos meses. El pitch: instruye tu agente de código para comportarse como "el dev sénior más perezoso de la sala." La lógica de operación es una escalera de decisión inyectada en el contexto del agente: ¿esto necesita existir? ¿Ya existe en el código? ¿La biblioteca estándar lo resuelve? ¿Un recurso nativo de la plataforma lo resuelve? ¿Una dependencia instalada lo resuelve? ¿Puede ser una línea? Solo entonces: escribe lo mínimo que funciona. El ruleset corre en 16 plataformas de agente—Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Aider, y otros. El SKILL.md central tiene aproximadamente 100 líneas. Las 6.232 líneas restantes son boilerplate de adaptadores. El benchmark original prometía 80 a 94 por ciento de reducción de código.
Entonces Colin Eberhardt, CTO de Scott Logic, extrajo los números. Y encontró el problema fundamental: la línea de base del benchmark era un modelo desnudo y parlanchín que llenaba cada respuesta de prosa, advertencias y múltiples opciones de implementación. Eso inflaba la comparación artificialmente. Su prueba: reemplazar Ponytail con siete palabras en inglés—"Follow YAGNI principles, and one-liner solutions." Ese prompt superó a Ponytail en el propio benchmark de Ponytail. [ref: ponytail-agent-skill-corrects-its-own-benchmark-after-contributor-challenge]
Hacker News llegó a la misma conclusión de forma independiente, describiendo el repositorio como "esencialmente solo estas reglas, y toneladas de boilerplate para sistemas de plugin específicos." Cada línea más allá del núcleo es un adaptador.
El autor reconstruyó el benchmark desde cero. Doce tareas de feature ejecutadas por Claude Code 2.1.177 en un repositorio real de FastAPI y React. La versión corregida del README ahora reporta 54 por ciento menos código en promedio—94 por ciento solo donde un agente habría sobrelevantado, cercano a cero en código ya minimal. El costo cayó 20 por ciento. La ejecución se aceleró 27 por ciento. La figura anterior era un techo por tarea reportado como si fuera promedio.
Pero luego JetBrains ejecutó un estudio independiente: 80 tareas pareadas—la tercera en una serie que previamente midió el caveman skill en 8,5 por ciento menos código contra los 65 por ciento anunciados, y RTK en 7,6 por ciento más contra los 60 a 90 por ciento anunciados de reducción. JetBrains usó un modelo diferente—claude-sonnet-5 con esfuerzo de raciocinio medio—un conjunto de tareas más grande, y un harness externo.
Resultado: 15 por ciento menos código, 10,3 por ciento menos costo, 11 por ciento menos tiempo. JetBrains lo llamó "la primera herramienta de esta serie con una señal estadísticamente sólida de ahorro de costo." Pero fueron claros: la reducción solo aparece donde había espacio para sobrelevantamiento. Ponytail apunta a tokens de salida; el lado de entrada prácticamente no se movió.
La distancia entre 54 por ciento—auto-reportado y corregido—y 15 por ciento—independiente—es el número práctico. Ahorros reales. Pero entre un cuarto y la mitad de lo que el README aún anuncia.
Hay un punto de seguridad que no puede pasar desapercibido: en un tier adversarial cubriendo path traversal, SQL injection y token forgery, Ponytail marcó 100 por ciento. Un prompt simple de "YAGNI más one-liners" cayó a 95 por ciento, perdiendo un caso de guarda. Esa es la única dimensión donde la complejidad del framework claramente compensa.
La pregunta más grande que Eberhardt plantea sobrevive al benchmarking específico: skills y frameworks basados en prompt se están proliferando sin ningún estándar de evaluación compartido. La pregunta que publicó en el repositorio de Skills de Anthropic—cómo los autores prueban y garantizan calidad—permanece entre los más votados y sin respuesta en ninguna librería de skills.
Lo que me lleva directamente a Harness. No están construyendo benchmarks—están midiendo lo que sus propios agentes hacen en producción en seis meses. Y el número que publicaron es el más honesto que he visto de un vendor de CI/CD hasta hoy: 15 a 20 por ciento del trabajo de ingeniería es genuinamente autónomo, desde Jira hasta pull request. Ochenta por ciento aún es asistido—desarrolladores usando agentes como herramientas, no delegando workflows completos. [ref: agentic-development-best-practices-how-to-spec-build-test-and-operate-ai-systems]
Cuatro de cada cinco tareas, el humano aún está en el loop. Ese es el estado real del arte—no lo que el keynote de ningún vendor presenta como la nueva normalidad del desarrollo de software.
Harness identificó cuatro pilares después de rediseñar el SDLC completo alrededor de agentes. Pilar uno: desarrollo basado en specs. Todo—producto, tech, UI, specs de prueba—vive en repositorios con version control. Las páginas de Confluence no funcionan porque agentes necesitan contexto estructurado y siempre actual. Resultado: los equipos prototipen mockups de UI en 30 minutos en lugar de semanas. El segundo pilar cuantifica dónde pertenecen los agentes—esa división 15-80. La arquitectura combina microservicios tradicionales con endpoints de agente expuestos vía Model Context Protocol. Cada agente tiene permisos delimitados y una única responsabilidad. Un agente de code review no implementa cambios. Un agente de testing no toca producción.
El tercer pilar—y el más negligido—es donde la brecha se revela. Harness especifica seis capas de prueba. La quinta—monitoreo continuo de eficacia en producción—es la más omitida y la más dolorosa. Cambia un system prompt, actualiza una base de conocimiento, o cambia la versión del modelo: la calidad del output del agente se degrada silenciosamente sin un harness observando.
Forrester encontró que ganancias de codificación de 30 a 40 por ciento frecuentemente se traducen en menos de 10 por ciento de ganancia de productividad del equipo completo cuando planificación, pruebas y pipelines de release permanecen manuales. Los cuellos de botella se desplazan—no desaparecen.
El cuarto pilar son Operational Readiness Reviews del playbook de hyperscaler—inmediatamente después de design review, no desarrollo. Con tiers de severidad aplicados: items high bloquean el launch, medium necesitan resolverse en 90 días, low van al backlog. Post-launch, equipos de servicio se reúnen semanalmente para revisar salud de data-plane y control-plane.
Dado ese panorama—agentes con autonomía real en 15 por ciento de tareas, benchmarks que se reducen bajo escrutinio independiente, monitoreo que la mayoría de equipos aún no tiene—la pregunta que queda es: ¿dónde debe vivir el control?
Cloudflare publicó una respuesta formal: el Agent Access Model—un framework de seguridad y autorización que trata agentes de IA como entidades de infraestructura de primera clase, no como extensiones de identidad humana. La premisa es una regla: no confíes en la ejecución. Autoriza cada acción contra la tarea y su estado acumulado. [ref: cloudflares-agent-access-model-rethinks-infrastructure-auth-for-ai]
Los controles existentes fallan en cuatro puntos específicos con agentes. Primero: las credenciales sobreviven a la tarea. Las service accounts fueron diseñadas para software de larga duración—llevan scopes amplios, keys de larga duración, ciclos de rotación raros. Aplicado a un agente de corta duración, esas credenciales sobreviven al trabajo para el cual fueron emitidas y se quedan en memoria, logs y variables de ambiente donde pueden ser re-ejecutadas. La solución de Cloudflare: el tiempo de vida de la credencial debe corresponder al tiempo de vida de la tarea—para un agente, eso frecuentemente es minutos.
Segundo: los agentes operan a la velocidad de la máquina. La detección de anomalías sintonizada para actividad humana reacciona muy lentamente. Un agente con acceso a base de datos y un camino de red de salida puede leer una tabla y POST a un endpoint externo antes de que un control sintonizado para humanos termine de muestrear. Tercero: el prompt no es un perímetro. Instrucciones como "no accedas a producción" moldean el comportamiento pero no enforzan acceso—y un modelo puede ser manipulado por contenido inyectado en los datos que lee.
Cuarto: los agentes componen autoridad a través de saltos de delegación. Cuando un agente invoca una herramienta que invoca otro agente que llama una API en nombre del humano original, la respuesta a "quién es esto y qué pueden hacer" desaparece en algún lugar de la cadena. La respuesta del AAM: cada acción es evaluada contra tres criterios—quién es el agente, qué tarea fue autorizado a ejecutar, y qué recursos el grafo ya ha tocado. Ese estado acumulado solo puede reducir el conjunto de capacidades restantes—una trinquete que se estrecha, nunca se amplía.
La comparación que Cloudflare usa es precisa: BeyondCorp removió la confianza implícita de la red. El AAM remueve la confianza implícita del grafo de ejecución de tareas.
"Un límite por el cual puedas hablar no es un límite."
El enforcement pertenece al harness que media tool calls y a la capa de red que media paquetes—no al instruction set del modelo. Cloudflare también envió infraestructura concreta: el Agents SDK ahora incluye MCPClientManager con flujo completo de OAuth 2.1—redirect para login, generación de code challenge, intercambio de authorization codes por access tokens, y namespacing de herramientas para evitar colisiones. Durable Objects, la primitiva de computación stateful que sirve como ancla de identidad para agentes, se movió al tier gratuito. Y lanzaron signed agents—una extensión del programa de verified bots que usa HTTP signatures de Web Bot Auth para autenticar criptográficamente tráfico de agentes en la capa de red. Primer grupo: ChatGPT agent, Goose de Block, Browserbase, y Anchor Browser.
Mientras Cloudflare resuelve identidad a nivel de red, LangChain publicó la arquitectura de referencia para el agente SRE autónomo que ejecutan en producción en su propio Kubernetes. Eric Johanson, Deployed Engineer de LangChain, escribió el walkthrough completo. Y el número más importante no es de capacidad—es de costo. [ref: building-autonomous-sre-agents-in-kubernetes-tool-design-for-cluster-level-contr]
95 a 99 por ciento de reducción de costo por verificación programada. Sin pérdida en detección de problemas.
La arquitectura anterior ejecutaba el orquestrador completo—aproximadamente 20 llamadas de modelo—cada ciclo programado, incluso cuando el cluster estaba sano. El cambio: recolección de estado en Python puro más una única llamada a Claude Haiku con uso de herramienta forzado. Eso genera un reporte de salud estructurado entregado en Slack, ordenado por severidad. Poder total del agente—fan-out paralelo a seis subagentes especialistas: pod-inspector, scaling-analyzer, performance-analyzer, log-analyzer, security-auditor, reliability-auditor—solo se dispara en investigaciones bajo demanda. La inversión correcta.
La división estructural read/write es lo que hace genuino el HITL. Read y write son codebases distintas. Las herramientas de escritura existen solo dentro de un único subagente change-executor, detrás de una interrupt gate. El orquestrador literalmente no tiene camino a una herramienta de write. RBAC in-cluster espeja la división: lectura cluster-wide, escritura con scope restringido. El agente puede leer cualquier namespace. No puede tocar un recurso sin aprobación humana de esa acción propuesta específica vía Slack—usando Socket Mode, un WebSocket de salida, sin ningún endpoint de entrada expuesto.
Johanson es directo sobre la pregunta de qué herramientas de escritura incluir: HITL solo protege producción cuando el humano puede genuinamente evaluar qué está aprobando. Escalar un deployment a 3 réplicas es legible. Un `helm upgrade` reescribe docenas de recursos invisibles en el momento de aprobación—entonces fue deliberadamente excluido a pesar de ser operacionalmente útil. Herramientas coarse, high-blast-radius se quedan fuera independientemente de la utilidad.
Para cerrar el bloque de agentes, Brex publicó el patrón que separa lógica de workflow de runtime para unificar evals y producción. Un equipo de cinco ingenieros TypeScript construyó el approach porque sus agentes corren por una hora a través de docenas de llamadas de LLM—haciendo drift entre eval y producción caro y arriesgado. [ref: decoupling-workflow-logic-from-runtime-for-eval-cycles]
El problema es estructural. Frameworks como LangGraph y Mastra expresan orquestación directamente en los SDKs mismos. Lógica de orquestación y el framework son el mismo artefacto. Para hacer eval de la lógica, ejecutas el framework. Para enviar, ejecutas el mismo framework. Ninguna versión de orquestación existe independiente del runtime. El approach antiguo de Brex: reimplementar agentes en un runtime de eval separado—dos copias de la misma lógica, garantizado de divergir con el tiempo.
La solución: escribe el workflow como lógica de negocio pura sin conocimiento de dónde va a correr, e inyecta un adapter de runtime en el momento de ejecución. En producción, el adapter se conecta a Temporal Cloud vía workers en el Kubernetes de Brex. En evals, se conecta a un runner in-process ligero en la plataforma de eval interna. Las llamadas de LLM rutean a través del Vercel AI SDK a un LLM Gateway interno que centraliza rate limiting y auth. Una única versión de orquestación existe—lo que pasa por eval es exactamente lo que va a producción.
El enforcement es arquitectural, no disciplinario. El equipo construyó la restricción en el propio sistema de build: si un desarrollador escribe código de orquestación dependiendo de características específicas del runtime, el build falla. Pero el costo es real—orquestación pierde acceso directo a primitivas nativas del runtime. Toda nueva capacidad más allá del denominador común necesita re-exponerse a través de la interfaz agnóstica. Este patrón solo compensa si el equipo genuinamente necesita tanto durabilidad de producción como eval offline rápido en el mismo camino de código. Equipos con agentes cortos o tolerando implementaciones separadas no deberían pagar ese costo.
Agentes bajo escrutinio—15 por ciento de autonomía real, identidad dentro del ciclo de tarea, arquitectura que enforza en lugar de meramente instruir. Ahora a dónde van los dólares de verdad.
AMD reportó Q2 de 2026. Revenue de data center: 6,7 mil millones de dólares. Crecimiento de 107 por ciento año a año, desde 3,2 mil millones un año atrás. Secuencialmente: de 5,8 mil millones en Q1 a 6,7 mil millones en Q2. Data center ahora representa 58 por ciento de la revenue total de AMD. Revenue total: 11,54 mil millones—crecimiento de 50 por ciento año a año, superando el consenso LSEG de 11,28 mil millones. Non-GAAP EPS: 1,66 contra estimativa de 1,62. [ref: amd-data-center-revenue-doubles-on-ai-chip-demand]
Para poner en perspectiva: la revenue de Q3 de 2026, guiada en 13 mil millones de dólares, será igual a toda la revenue de AMD en fiscal 2023—en un único trimestre.
Lisa Su guió que data center revenue va a doblar de nuevo en 2027—y que server revenue va a crecer más de 80 por ciento año a año en H2 2026. AWS, Microsoft, Google, y Oracle expandieron deployments de EPYC en el trimestre. Helios—sistema rack-scale de AMD integrando CPUs, GPUs y networking—comenzó a ser entregado a Meta, OpenAI, y Oracle este trimestre, con ramp volumétrico esperado en Q4. Anthropic cerró un acuerdo para deployment de hasta 2 gigawatts de Instinct GPUs en sistemas Helios en un pacto multianual.
El CapEx de AMD se triplicó en cuatro trimestres: 808 millones en Q2, desde 282 millones un año atrás y 389 millones en Q1. Pre-construcción de capacidad antes de que la demanda llegue. La acción cayó 5 a 10 por ciento en after-hours a pesar de superar top y bottom line—algunos analistas habían modelado guidance de Q3 en hasta 14 mil millones. Para operadores evaluando estabilidad de supply, eso es ruido. Lo que importa: la aceleración secuencial de data center y la lista de clientes de Helios.
Y hay una pieza faltante en el stack para servir inferencia a costo optimizado—y Taalas va a intentar cerrar eso. El 6 de agosto de 2026, AMD anunció acuerdo definitivo para adquirir Taalas, startup de Toronto que graba pesos de modelos de IA directamente en silicio. Los términos no fueron divulgados. El equipo—co-fundado por Ljubisa Bajic, ex-CEO de Tenstorrent y ex-ejecutivo de AMD, junto con COO Lejla Bajic y CTO Drago Ignjatovic—va a unirse al grupo de IA de AMD bajo Vamsi Boppana. [ref: amds-taalas-acquisition-specialized-inference-silicon-against-nvidias-dominance]
El mecanismo del chip HC1: fija el dataflow del modelo y graba los pesos en mask ROM. SRAM separada maneja KV cache y adapters de fine-tuning. En Llama 3.1-8B, entrega más de 16 mil tokens por segundo por usuario—múltiplos de lo que GPU actual alcanza. Un equipo de 24 personas construyó el HC1 con 30 millones de dólares. Luego levantaron 169 millones en febrero de 2026. Total de funding: 219 millones.
El trade-off es claro: el HC1 ejecuta exactamente un modelo. Cambiar modelos requiere dos nuevas máscaras de metal vía tooling proprietario—aproximadamente dos meses. El HC2, esperado este verano, soporta 20 mil millones de parámetros por chip. Un modelo de un billón de parámetros se mapearía a aproximadamente 50 aceleradores—dentro de la capacidad del rack Helios. DeepSeek-671B en el HC1 exige 30 tape-outs, mostrando por qué la tecnología sirve modelos deployed estables, no pesos de frontera en iteración rápida.
La lógica de integración es inferencia desagregada: Instinct GPUs hacen prefill—el procesamiento compute-intensivo de prompt—y aceleradores Taalas hacen decode, la generación de tokens. AMD ya anunció solución similar con Cerebras el 23 de julio en el evento Advancing AI 2026. Taalas podría desplazar a Cerebras para modelos más pequeños y estables.
Pero aquí necesito hacer un pushback en el framing optimista. En un mercado donde los mejores modelos cambian en escala de semanas, el costo de oportunidad de dos meses de re-spin para cambiar modelos es real. AMD está apostando que existe una clase grande de workloads donde modelos no cambian—code assistants, document extraction, transcripción en tiempo real. Podría estar en lo correcto para verticales específicas. Pero ese no es el estándar de la frontera.
Es una apuesta de vertical versus horizontal. Y eso nos lleva al costo escondido que se queda debajo de cualquier cluster de GPU—independiente de qué silicio está ejecutando. SpaceX gastó 295 millones de dólares en Megapacks de Tesla en Q2 de 2026. Total del primer semestre: 329 millones de dólares. [ref: spacex-ramps-megapack-purchases-for-ai-datacenter-power-signals-major-compute-ex]
Cada Megapack almacena más de 3,9 MWh. Más de 420 unidades desplegadas proporcionan aproximadamente 1,6 GWh de capacidad de batería—suficiente para absorber picos de cluster de GPU sin sobrecargar la red regional. En Colossus 1, 208 Megapacks fueron desplegados antes de que la subestación permanente de Memphis Light, Gas and Water entrara en operación. Esa subestación tardó 97 días en construirse—contra 2,5 años en el proceso normal.
Colossus está apuntando a aproximadamente 580 mil GPUs NVIDIA: 520 mil GB200s, 30 mil GB300s, y 30 mil H100/H200s—en capacidad de 2 gigawatts. La configuración GB200-NVL72, con 72 GPUs por rack, implica aproximadamente 8 mil racks en el deployment completo. Infraestructura total—edificios, energía, enfriamiento, red, más de 420 Megapacks—llega a 35 a 40 mil millones de dólares.
Musk en la call de Q2: "Nuestro objetivo tentativo es tener 20 gigawatts de potencia y enfriamiento online al final del próximo año." Luego él mismo se corrigió: "Yo esperaría algo cercano a 15 gigawatts a nivel de usina." SpaceX se comprometió con 2,8 mil millones para construir infraestructura propia de gas natural, reduciendo dependencia de contratadores de turbina terceros.
La revenue de lease cubre todo con margen. Anthropic paga 1,25 mil millones por mes por Colossus 1 hasta mayo de 2029—40 mil millones en total. Google alquiló 110 mil GPUs de Colossus 2 a 920 millones por mes hasta junio de 2029. Leases combinadas: 2 mil millones mensuales. La cuenta de energía de 90 a 160 millones de dólares anuales representa menos de 1 por ciento de la revenue anual de lease. Los Megapacks son marginales en el P&L—pero son la capa de estabilidad de grid que hace clusters por encima de 50 megawatts operacionalmente posibles.
Y debajo de todo eso—del Colossus, de los racks Helios, de las Instinct GPUs—hay una guerra de memoria que va a determinar quién controla el cuello de botella de latencia para los próximos cinco años. Samsung presentó el roadmap completo de memoria en el Future of Memory and Storage Summit en Santa Clara. El problema central que Leno Park, VP de flash solutions de Samsung Electronics, puso en la mesa: clusters de IA hoy soportan aproximadamente 100 tokens por segundo por usuario. Samsung está diseñando para 1.000 tokens por segundo hasta 2030—10x de throughput. [ref: samsung-ai-memory-roadmap-targets-hbm-speed-and-capacity-growth]
El HBM4E es el siguiente deliverable concreto. Muestras enviadas en mayo, evaluación activa por partners del ecosistema. Usa base die de 4 nm, aumenta el conteo de TSVs en aproximadamente 4x, y emplea packaging avanzado con más de 300 mil microbumps en pitches más apertados. Resultado: 4 terabytes por segundo de bandwidth y 64 GB de capacidad en un único stack de 16 capas, a 16 Gbps por pin—más de 20 por ciento más rápido que HBM4. Para manejar concentración térmica en stacks densos, Samsung agregó un bloque heat pipe—una "chimenea" colocada directamente sobre hot spots en el stack.
HBM5 cambia a base die de 2 nm con tecnología gate-all-around, acortando largos de canal de interposer para mejorar señalización I/O. Luego viene zHBM—que colapsa el layout 2.5D actual. El acelerador de IA se sienta directamente encima del stack de HBM como una estructura 3D unificada, cortando la distancia física entre procesador y memoria. Samsung afirma que la interfaz de próxima generación puede entregar 8x la performance de HBM5, más de 10x densidad de memoria, 3x eficiencia energética, y menos de la mitad de la resistencia térmica.
Pero llegar a esos números requiere co-design próximo con partners de acelerador—limitando adopción a vendors dispuestos a compartir datos de design a nivel de die y coordinar packaging. HBM4E a 4 TB/s y 64 GB por stack está disponible para evaluación ahora. HBM5 y zHBM permanecen items de co-design—factoriza esa incertidumbre en cualquier build de cluster más allá de 2027.
Y la revenue de HBM de Samsung señaliza la urgencia del propio mercado: ventas de HBM van a más que triplicarse en 2026 versus 2025, y alcanzar 50 por ciento de la revenue total de DRAM hasta 2030. La pregunta estructural es si zHBM con integración 3D co-diseñada llega a tiempo y con yields que la hagan utilizable para decisiones de procurement—y no solo slides de roadmap.
Para cerrar el bloque de silicio, hay una última pieza—sobre qué pasa cuando tienes el hardware correcto pero no el kernel correcto para extraer performance de él. El 4 de agosto de 2026, Cursor open-sourceó el Mixture-of-Kittens—MoK—un megakernel que incrementó el throughput de entrenamiento end-to-end en 1,41x en 512 GPUs GB300. El mismo día, Latent Space publicó argumentos de por qué megakernels son obsoletos. La colisión aclaró una tensión real. [ref: megakernels-are-dead-and-back-cuda-kernel-fusion-trends-for-inference-optimizati]
El caso en contra: megakernels eliminan overhead de launch de kernel y lag de sincronización entre kernels, pero escribirlos es difícil. Per-kernel tuning más overlap de scheduler frecuentemente supera un kernel monolítico fusionado porque cada componente puede ser optimizado independientemente. NVIDIA está resolviendo sincronización en hardware: Rubin introduce triggers de dependencia a nivel de tile, permitiendo que kernel N+1 lance CTAs para un tile tan pronto como kernel N termine—sin esperar por stragglers. Eso es lo que megakernels hacían en código CUDA.
Cursor argumentó lo opuesto para capas MoE en racks NVL72. MoE consume más de la mitad del tiempo de entrenamiento end-to-end. Un GB300 NVL72 es 72 GPUs en un único dominio NVLink—topología de comunicación cualitativamente diferente de un cluster DGX. CPUs Grace integrados son lentos relativo a las GPUs: GPU streams regularmente esperaban trabajo de CPU—logging, métricas. Solo un megakernel puede eliminar sincronización CPU-GPU completamente; kernels individuales no pueden.
Los números del MoK: MXFP8 forward corre 2,37x más rápido que el mejor baseline público—DeepEP más TransformerEngine, HybridEP más Megatron—con grado de EP 64 y 2.048 tokens por GPU. BF16: 1,92x. End-to-end en 512 GPUs: tokens por segundo por GPU subieron de 760,9 a 1.070,2—ganancia de 1,41x. Dispatch basado en pull logra 29 por ciento más utilización de bandwidth NVLink bajo expert imbalance versus push-based. Latencia de señalización cayó de 103 microsegundos a 18.
La restricción: MoK requiere NVIDIA Blackwell SM100 o SM103—específicamente GB200 NVL72 o GB300 NVL72 racks. Necesita CUDA 13.0 o superior, PyTorch 2.10 o superior, Python 3.12 o superior. Ejecutar en H100 o B200 DGX nodes va a fallar el build. El proyecto es Apache-2.0 y ya alimenta el entrenamiento del modelo Composer de Cursor en decenas de miles de GPUs. En clusters commodity y hardware Rubin, kernel-splitting más CTA scheduling en hardware es cada vez más viable con carga de mantenimiento mucho menor—sin 67 mil líneas de forward pass fusionado para debuguear. En racks NVL72, donde el cuello de botella de CPU Grace y topología NVLink crean restricciones distintas, fusión aún vence por un margen que justifica el costo de ingeniería.
Silicio con revenue que se dobló, batería en miles de millones para estabilizar clusters, memoria disputada capa a capa. Ahora la pregunta final: ¿quién controla la puerta de enlace por donde fluye todo ese poder?
Together AI respondió con datos concretos. Pusieron DeepSeek-V4 Flash 0731 y GPT-5.6 Luna cara a cara en DeepSWE—113 tareas reales de código de largo horizonte en repositorios open-source activos, cuatro intentos por tarea, calificadas por suite de pruebas oculta. [ref: deepseek-v4-flash-vs-gpt-56-luna-cost-and-coding-benchmark-showdown]
Luna es el mejor ingeniero. Pass@1: 67,2 por ciento contra 53,3 de DeepSeek. El gap se mantiene en cada conteo igual de intentos: 81,6 por ciento contra 70,1 en k=2, 90,3 por ciento contra 80,5 en k=4. Luna también corre más rápido: 16 minutos de mediana contra 23, 92 pasos contra 148, y produce menos: 70 mil tokens contra 104 mil. En calidad bruta de tiro único, no es una carrera cercana.
Pero el costo invierte la historia. DeepSeek cuesta 10 centavos por intento. Luna: 61 centavos—diferencia de 6x. Eso entrega 532 tareas resueltas por 100 dólares en DeepSeek, contra 110 de Luna. Concretamente: el pass@2 de DeepSeek—70,1 por ciento—ya supera el pass@1 de Luna—67,2 por ciento—y dos intentos de DeepSeek cuestan 20 centavos. Un tercio de una única ejecución de Luna.
La cascada es la respuesta práctica. Ejecutar DeepSeek primero y escalar a Luna solo en falla logra 78,9 por ciento de precisión a 38,5 centavos por tarea—más preciso que Luna solo, y 37 por ciento más barato.
Hay un detalle que la mayoría de análisis perdió: cuando DeepSeek falla, rompe la suite de pruebas existente del repositorio en 9 por ciento de los casos. Luna lo hace en 15 por ciento. El modelo más caro tiene probabilidad más alta de corromper código que funcionaba. Deployments de Luna necesitan gates de regresión completos. DeepSeek necesita menos.
Y hay segmentación clara por dominio. Luna gana 7 de 8 dominios de tareas. Los mayores márgenes: análisis de programa—69 por ciento de Luna contra 33 de DeepSeek. Concurrencia y durabilidad—70 contra 38. Internos de runtime de lenguaje—86 contra 59. Gaps de 30 puntos en trabajo de raciocinio. DeepSeek gana en un único dominio: query y config languages—78 contra 70. SQL builders, window functions, keyset pagination, config parsers.
JavaScript es un precipicio para DeepSeek: 35 por ciento contra 60 de Luna. Si tu stack de agente toca JavaScript, DeepSeek es falsa economía. Si vive en config, query o Rust—donde DeepSeek llega a 55 por ciento contra 60 de Luna—el gap se cierra y la cascada tiene sentido.
Open weights dejó de ser experimento y se convirtió en línea de presupuesto. El siguiente paso es que alguien controle la puerta de enlace por donde esa roteación pasa. Y tres movimientos esta semana definen dónde va a vivir esa puerta de enlace.
El primero: Microsoft puso el tier AI Gateway de Azure API Management en public preview el 27 de julio de 2026, disponible en East US 2 y Sweden Central sin costo mientras el precio es determinado. [ref: azure-api-management-adds-dedicated-ai-gateway-model-governance-at-scale]
El cambio estructural no es sutil. El control plane del nuevo tier está organizado alrededor de modelos, servidores MCP y herramientas—no APIs. Es una separación estructural del approach de policy-layering de los tiers clásico y v2, que retienen sus capacidades inalteradas. La puerta de enlace rotea basado en match exacto del campo `model`. Todos los proveedores compatibles con OpenAI comparten un camino de endpoint; cada modelo publicado necesita un nombre único. Anthropic corre a través de un custom provider con passthrough de la Messages API. La puerta de enlace provisiona en aproximadamente un minuto sin unidades de escala para planificar.
La federación de herramientas extiende el mismo patrón a la capa MCP. Los equipos pueden exponer un servidor MCP existente vía SSE o Streamable HTTP, convertir operaciones de REST API en un servidor MCP subiendo una spec OpenAPI, o usar más de 1.400 herramientas basadas en conector de Power Platform y Logic Apps—sin hospedar un servidor. Múltiples servidores MCP federados detrás de un único endpoint, entonces un agente conecta una vez y resuelve herramientas en todos ellos. Autenticación por backend soporta API keys, OAuth 2.0 client credentials, managed identity y mTLS.
La governance corre en policy cards en el portal como propiedades JSON—no las expresiones XML que veteranos de APIM conocen. Cubre límites de request y token, quotas, Azure AI Content Safety y fallback a modelo secundario. La telemetría fluye como métricas OpenTelemetry con convenciones semánticas GenAI para Application Insights, Datadog, Splunk, Grafana Cloud, o cualquier endpoint OTLP que el cliente controla. El recurso corre en la propia subscription y tenant Entra del cliente.
Pero hay un punto de atención concreto en el modelo de acceso. La runtime key tiene scope de puerta de enlace—alcanza todos los modelos y todas las herramientas publicadas en esa puerta de enlace. La guidance de Microsoft es una key por aplicación, pero una key fugada tiene blast radius de la puerta de enlace completa, no de un producto específico. Los equipos que confiaban en scoping de subscriptions de APIM para limitar consumidores a APIs específicas necesitan rediseñar esa frontera completamente.
Y hay un status de preview que no puede ser ignorado: sin SLA, APIs y límites pueden cambiar antes del GA, regiones son East US 2 y Sweden Central por ahora, y—más significativo—el precio no está anunciado. El argumento central de governance de costo queda sin resolución hasta que el precio sea definido.
El segundo movimiento: Cloudflare unificó cinco primitivas—Workers AI, AI Gateway, Vectorize, R2 y Browser Run—en un namespace único de AI Search. Un comando `wrangler ai-search instance create` apunta a una URL de fuente, maneja crawling vía Browser Run, chunking, embedding y almacenamiento vectorial en un único paso. Para sitios sin sitemap, la flag `--parse-type discover` sigue links para encontrar páginas. [ref: cloudflare-ai-search-agents-get-built-in-retrieval-for-proprietary-data]
El Dev Stack MCP de Cloudflare demuestra el deploy: 10 superficies—Docs, Blog, API Docs, Comunidad, Astro, Vite, Vitest, Hono, Replicate y OpenNext. Cada una con una instancia de AI Search. Un único binding en wrangler.jsonc deja que un Worker haga una llamada `AI_SEARCH.search()` que hace fan-out a las 10 simultáneamente. Los resultados regresan como `res.chunks` con metadata de citación y tags de instancia, reranking habilitado, y hasta 10 resultados por llamada. Embedding y reranking cuestan cero por token cuando usando modelos Workers AI designados—eliminando el overhead operacional de predecir conteos de tokens para workloads de búsqueda con volumen de queries impredecible.
El tercer movimiento—y el más estructural—es MCP V2. La revisión más grande del Model Context Protocol desde el lanzamiento llegó el 28 de julio de 2026. El protocolo ahora registra 400 millones de descargas mensuales de SDK—crecimiento de 4x en un año, impulsado por presión del ecosistema para ejecutar servidores en infraestructura HTTP estándar. [ref: anthropics-mcp-v2-standardizing-agent-tool-binding-across-runtimes]
El cambio central: remoción del handshake initialize/initialized y del header Mcp-Session-Id. Seis SEPs convergieron en un único design—cada request lleva versión del protocolo, identidad del cliente y capacidades inline. Cualquier instancia de servidor puede manejar cualquier request. Sticky sessions, session stores y lógica de stream-hold desaparecieron de la capa de protocolo. El Agents SDK de Cloudflare embarcó soporte inmediatamente—la nueva primitiva es `createMcpHandler` ejecutando en un Worker común. Amazon Bedrock AgentCore Gateway habilitó vía una única llamada de API UpdateGateway. SDKs actualizados en TypeScript, Python, Go y C# v2.0 fueron entregados junto con la spec.
Tres upgrades de infraestructura siguen la statelessness. Routability: nuevos headers Mcp-Method y Mcp-Name permiten que load balancers roteen tráfico sin inspeccionar el body JSON—mismatch de header retorna error HeaderMismatch. Cacheability: respuestas de list y resource llevan campos ttlMs y cacheScope modelados en HTTP Cache-Control. Traceability: W3C Trace Context propaga a través de nombres de clave fijos en `_meta`, habilitando rastreo distribuido compatible con OpenTelemetry a través de SDKs y puertas de enlace sin instrumentación customizada.
Pero la migración de elicitation es el punto duro—el breaking change real de la spec. Cuando un servidor MCP necesitaba input en medio de un request—aprobación antes de un deploy, confirmación de billing—el protocolo antiguo mantenía un stream abierto. El nuevo spec introduce Multi Round-Trip Requests: el servidor retorna `input_required` con lo que necesita, el cliente colecta la respuesta, y la operación es reintentada con ese input. Sin sesión preservada entre rounds. Los equipos usando server-initiated elicitation no pueden hacer upgrade con un bump de SDK—el modelo de interacción requiere reescrita de código.
La extensión Tasks fue promovida de experimental a oficial. El lifecycle es stateless por design: tools/call retorna un handle de tarea, y clientes conducen progreso vía tasks/get, tasks/update y tasks/cancel. El método tasks/list fue removido—sin sesiones, enumerar tareas activas no es una operación segura para exponer. Roots, Sampling, Logging y transporte SSE entran en un reloj de 12 meses de depreciación a partir del 28 de julio—remoción más pronto posible el 28 de julio de 2027.
Para cerrar el bloque—y la edición—NVIDIA liberó el Alpamayo 2 Super para uso comercial bajo licencia OpenMDW-1.1. Un modelo open-weights de 34 mil millones de parámetros construido para percepción, planificación y data workflows de robotaxi y vehículos autónomos. Primer lanzamiento de la familia Alpamayo que permite deployment en producción sin permisos adicionales de NVIDIA. [ref: nvidia-alpamayo-2-super-open-model-now-available]
La arquitectura combina un Cosmos 3 Super Reasoner de 32 mil millones de parámetros con un Action Expert difusivo de 2 mil millones, post-entrenado con reinforcement learning. El score en el benchmark LingoQA de raciocinio para dirección autónoma: 79,2—primer lugar entre 37 modelos evaluados. Margen de 17 puntos sobre Qwen2.5-VL de 72 mil millones de parámetros, que tiene el doble de los parámetros. 15,1 puntos sobre Gemini 2.5 Pro. 23,2 puntos sobre GPT-4o.
En simulación closed-loop AlpaSim—910 escenarios reales reconstruidos—el modelo logra un score de 1,50 ± 0,13. Casi el doble de 0,81 ± 0,01 de Alpamayo 1.5 de 10 mil millones de parámetros. Trayectoria: minADE_6 de 0,911 metros sobre un horizonte de 6,4 segundos en 1.434 muestras. El corpus de entrenamiento incluye aproximadamente 115 mil horas de video de dirección multi-cámara y 3,7 millones de traces de raciocinio.
Los 34 mil millones de parámetros hacen Alpamayo 2 Super un workload de inferencia en nube. El modelo que va dentro del carro es un derivativo destilado—el score del benchmark es el techo del modelo teacher, no la spec de runtime para el vehículo. Pero la licencia OpenMDW-1.1 cubre fine-tuning, modelos derivados y redistribución comercial—y modelos destilados derivados de Alpamayo 2 Super no llevan condiciones de licencia adicionales. Eso remueve un bloqueador legal común para programas de AV que quieren construir stacks proprietarios en fundaciones abiertas. El pipeline de auto-labeling comprime ciclos de anotación de meses a días.
La familia Alpamayo acumuló 400 mil descargas en Hugging Face desde el lanzamiento en CES 2026. Y la familia completa fue retroactivamente relicenciada bajo OpenMDW-1.1.
La pregunta que queda para el CTO al final de esta edición es la misma que abre el segundo bloque: ¿tu roadmap de inferencia asume precio de 2025 o stack de 2027? Porque quienquiera que controle la puerta de enlace—cloud provider, CDN o stack propio—controla el costo. Y la mayoría todavía no ha tomado esa decisión.
La semana probó que autonomía es un número, no una promesa. Quince por ciento. Ese es el techo que la ingeniería honesta coloca en la autonomía de agentes hoy—y cada dato de esta edición orbita esa frontera. El Wire de lunes abre con la cuenta que Meta escondió en el ranking de dos etapas de Instagram—y qué enseña sobre asignar compute en pipelines de ranking. Hasta entonces.