La semana en que los agentes dejaron de ser prototipo y se volvieron una unidad implantable—obligando a supply, regulación y confiabilidad a reorganizarse alrededor de ellos.
Tres días.
Del lanzamiento al apagón global. El modelo de código más capaz del mundo, borrado por orden ejecutiva americana, sin fecha de retorno.
Esta es la Edición de ai|expert, número diecisiete. La semana en que los agentes dejaron de ser prototipo y se volvieron una unidad implantable—y supply, regulación y confiabilidad salieron corriendo a alcanzarlos.
Comenzamos con lo que cambió en el banco de desarrollo. Dos lanzamientos esta semana que, vistos juntos, definen qué significa operar agentes a escala real—no en sandbox de investigación, no en un piloto aislado.
El primero es Omnigent de Databricks, open-source bajo licencia Apache 2.0. Databricks fue directa sobre la motivación: su propia organización de más de cinco mil ingenieros había adoptado agentes de código temprano—Claude Code, OpenAI Codex, agentes customizados sobre SDKs propios—y el problema que emergió no era de capacidad del modelo. Era operacional. Con cuatro o cinco agentes corriendo en paralelo, los ingenieros gastaban tiempo copiando contexto manualmente entre terminales, Google Docs y Slack. No existía un harness único capaz de compartir estado o delegar entre fronteras de herramientas. [ref: databricks-launches-omnigent-to-operationalize-multi-agent-workflows]
La arquitectura tiene dos componentes centrales. Un Runner que envuelve cualquier agente en una sesión aislada con una API uniforme—mensajes y archivos entran, streams de texto y llamadas de herramientas salen. Un Server que hospeda políticas, lógica de compartición y acceso multi-modal. El stack opera encima de los harnesses existentes sin reemplazarlos. Un cambio de una línea en YAML intercambia el modelo subyacente o porta un agente customizado entre Claude Code, el SDK de OpenAI Agents y el SDK de Claude Agents. La composición ocurre en la meta-capa—un único workflow puede orquestar subagentes corriendo en harnesses diferentes simultáneamente.
Lo que importa para los equipos que ponen esto en producción son las políticas de sesión. Omnigent aplica costo y seguridad en el límite de la sesión—no a nivel del modelo. El sistema puede pausar un agente y solicitar confirmación humana después de cada cien dólares gastados en LLM. Las políticas de seguridad son dinámicas por sesión: el sistema puede exigir aprobación humana para un git push solo después de que el agente haya descargado un paquete npm en esa sesión específica. Un sandbox de OS endurecido intercepta solicitudes de red en un proxy de egress—credenciales como tokens de GitHub nunca quedan expuestas al proceso del agente, solo se inyectan en llamadas de salida aprobadas.
Rastreo de estado por sesión. No lista estática de reglas.
Pero Databricks no publicó benchmarks de latencia del overhead generado por el meta-harness. La pregunta abierta para arquitectos de plataforma: si el policy engine o el state tracker se degradan, todos los agentes compuestos se detienen. Ahora tienes dos capas de abstracción para debugar en lugar de una. Agregar coordinación encima de harnesses ya opinativos crea un nuevo single point of failure—y cuando algo se rompe, la falla atraviesa dos capas antes de poder atribuirla.
El segundo lanzamiento es GitHub Copilot desktop—disponible desde el 2 de junio de 2026 para suscriptores Pro, Pro+, Business y Enterprise. La proposición central: un desarrollador supervisando hasta diez agentes trabajando en el mismo repositorio al mismo tiempo, con aislamiento garantizado de rama.
El mecanismo de aislamiento son git worktrees. Cada sesión de agente corre en su propia rama completamente chequeada, en un camino de filesystem separado. Un agente triagea un bug de producción, otro implementa un issue de backlog, un tercero responde a comentarios de review—en el mismo repositorio, al mismo tiempo. La app crea y destruye esos worktrees automáticamente. Cuando una sesión está lista para integrar, Agent Merge se encarga de CI, feedback de review y merge tan pronto como todas las condiciones configuradas se cumplan. En ramas con protección de política, requiere aprobación humana—no puede contornar reglas de branch protection. [ref: github-copilot-desktop-parallel-agentic-workflows-native-to-ide]
La escala detrás del timing de este lanzamiento es reveladora. Los commits en GitHub llegaron a 1.400 millones por mes—aproximadamente el doble año a año. GitHub Actions superó dos mil millones de minutos por semana. Cuando el propio coding agent de la plataforma fue lanzado, el uso creció aproximadamente doscientas veces en seis meses—muy más allá del capacity planning. El CTO Vlad Fedorov reconoció en abril de 2026 que el equipo necesitaba diseñar para 30 veces la escala actual. Y hoy, Copilot es el primero, segundo y tercer contribuidor más prolífico al codebase propio de GitHub—CLI primero, Coding Agent segundo, Code Review tercero.
El CPO Mario Rodriguez describió la distinción entre los dos modos de trabajo así: "Chat es donde instruyes, discutes y razonas sobre ambigüedad. Canvases es donde esa intención se convierte en trabajo visible que puedes inspeccionar, dirigir y verificar." Es una distinción operacional real—y la arquitectura que apuesta en los primitivos de GitHub—issues, PRs, Actions, code review—como scaffolding para workflows agentivos tiene una ventaja de integración genuina para equipos que ya operan enteramente dentro de la plataforma.
Pero el detalle que ningún comunicado de prensa destacó es el cambio de billing.
El 1 de junio, GitHub migró a cobranza por token. Un AI Credit cuesta un centavo de dólar. Una sesión típicamente agentic consume treinta a cuarenta dólares. Los equipos corriendo múltiples sesiones paralelas reportaron aumentos de diez a cincuenta veces respecto al modelo anterior de precio fijo. Los suscriptores Pro tienen diez dólares por mes en créditos. Tres sesiones paralelas a treinta y cinco dólares cada una consumen el presupuesto mensual entero antes del mediodía. Copilot Max, a cien dólares por mes, incluye cien dólares en AI Credits más una franquicia flex—pero diez sesiones paralelas a treinta y cinco dólares cada una ya superan ese envelope.
Cualquier equipo evaluando la app necesita modelar el consumo de créditos antes de habilitar acceso amplio. El número de treinta a cuarenta dólares por sesión es un piso, no un techo. Omnigent, comparativamente, tiene un gate explícito de cien dólares. Copilot aún no tiene un equivalente nativo.
Ahora hacia dónde esos agentes fallan. Y la literatura de esta semana es la más densa que hemos revisado sobre runtime en producción.
Un post-mortem publicado en arXiv documenta ocho semanas de un runtime de agente personal en producción continua desde marzo de 2026. Cuarenta jobs agendados, ocho proveedores de LLM, un proxy de gobernanza de herramientas, y un memory plane de base de conocimiento—defendidos por 4.286 pruebas unitarias y 827 governance checks. Resultado: 22 incidentes con post-mortems completos de causa raíz. Un meta-patrón manifestándose al menos 28 veces. [ref: longitudinal-study-uncovers-22-failure-modes-in-llm-agent-runtimes]
"Silenciosas" es la palabra operativa.
La clase de falla más endémica y de mayor riesgo operacional es la que los autores llaman "chained hallucination and fabrication". Cuando el runtime encuentra un error, el modelo no lanza excepción. Reescribe el error en una conclusión coherente y plausible entregada directamente al usuario. Los autores llaman esto "fail-plausible": el observador no solo está ciego al error. El observador está siendo activamente engañado por la propia señal de falla. El sistema fabrica su coartada.
¿Y los métodos de detección existentes capturan ese patrón?
No. Aproximadamente 70 por ciento de las fallas silenciosas fueron detectadas por observación humana del output final—no por pruebas automatizadas o auditorías. Una revisión retrospectiva de 15 incidentes mostró cero por ciento de prevención ex-ante y 87 por ciento de bloqueo de regresión. La auditoría no previene falla. La auditoría bloquea falla que ya pasó—y solo funciona si recurre de la misma forma.
¿Y la latencia de los incidentes?
De 13 horas a 60 días. Las fallas de mayor duración vivían en las costuras entre componentes—el proxy de herramientas, el memory plane y los LLM providers—donde ninguna prueba corre. La complejidad de código no era predictor. El área de superficie de frontera era. El paper propone un Physical Integrity Gate engine y un protocolo de Agent Delivery Engineering como contramedidas determinísticas. Pero la conclusión central es que los sistemas multi-provider tienen que tratarse como sistemas distribuidos donde el modo de falla más peligroso es indistinguible del output correcto—y log aggregation y governance checks son necesarios, pero no suficientes.
El segundo paper de esta semana vino de un proyecto de software real, no de laboratorio. Y documenta qué pasa cuando los ingenieros hacen la cosa intuitivamente obvia cuando algo se rompe con un agente—y consiguen resultados peores.
Hui Zhang y Shuren Song publicaron el 17 de junio un reporte de 391 sesiones consecutivas de colaboración con IA en el proyecto Bang-v3, a lo largo de aproximadamente un mes. El modo de falla que identificaron se llama "Index Sickness". El mecanismo es contraintuitivo: conforme los equipos agregan estructura formal a prompts—sistemas de ID simbólico, reglas numeradas, capas de constraints—esperan guardrails más claros. El registro del Bang-v3 muestra lo opuesto. [ref: real-software-project-documents-llm-semantic-drift-across-391-sessions-formal-co]
Una vez que el sistema simbólico supera un threshold de complejidad, el modelo deja de razonar sobre el dominio de negocio semánticamente. Entra en pattern-matching autorreferencial dentro de la propia capa simbólica—produciendo outputs que parecen internamente consistentes pero están desconectados del estado real del proyecto. El paper llama la falla canónica "Phantom Legislation": el LLM genera reglas o construtos de código coherentes en abstracto, pero físicamente desconectados de la realidad.
Y esto se alinea directamente con lo que Chroma documentó en 2025 testeando 18 modelos frontier—todos se degradan conforme la longitud del input aumenta. Los agentes de código son los más afectados: cada archivo leído, resultado de grep y output de herramienta se acumula en la context window por el resto de la sesión, mientras la estructura lógica crea distracciones densas. En pregunta-y-respuesta con múltiples documentos, la acurácia cayó más de 30 por ciento cuando el documento relevante estaba en posiciones intermedias en lugar de al principio o al fin. El benchmark RULER de NVIDIA coloca el contexto efectivo en 50 a 65 por ciento de la capacidad anunciada para la mayoría de los modelos. Y—este es el resultado más contraintuitivo—Chroma descubrió que los modelos performan mejor en contextos embarullados e incoherentes que en contextos lógicamente estructurados. La densidad estructural es una liability, no un activo.
¿Y la solución que encontraron Zhang y Song?
"Baseline-Log Physical Separation." Mantén la arquitectura estable del proyecto—dominio, decisiones de diseño, estado canónico—en un documento separado del log corriente de la sesión. El LLM recibe un snapshot limpio de verdad al inicio de cada sesión, no un heap creciente de estado mezclado con ruido conversacional. El volumen de AI Instructions cayó aproximadamente 75 por ciento. Index Sickness no recurrió en las 150 sesiones siguientes.
Los autores llaman el principio subyacente el "Pang Principle"—Ley de la Vitalidad Semántica: el lenguaje natural con propósito explícito carga calidad de información mucho superior a la expresión simbólica. Más reglas, menos semántica.
Es arquitecturalmente idéntico a la lógica del CLAUDE.md en Claude Code—documentación estable cargada upfront, archivos individuales buscados just-in-time vía grep y glob, bypass de indexación obsoleta. Zhang y Song llegaron al mismo lugar de forma independiente. La dificultad no es técnica. Es organizacional: los equipos de ingeniería son recompensados por agregar constraints cuando algo se rompe. Remover scaffolding simbólico y confiar en lenguaje natural parece reducir rigor. El registro del Bang-v3 dice que ese instinto es la causa del problema, no la solución.
De la falla a la ofensiva. Un paper publicado el 17 de junio muestra agentes de LLM en la posición de atacante de seguridad—con resultados que ya entraron en disclosure.
OpenAnt, de Knostic. Un pipeline open-source de seis etapas bajo Apache 2.0 que escanea bases de código a escala de repositorio y valida cada hallazgo con un exploit real ejecutado en un contenedor sandboxed antes de surfacear cualquier resultado. En OpenSSL: 15.232 funciones parseadas en 1.769 archivos. Después de filtrar por reachability desde puntos de entrada controlados por atacante—handlers de CLI, callbacks, funciones main—la superficie de análisis cayó 97 por ciento. De 15.232 unidades a 390. [ref: openant-llm-agents-discover-repository-scale-vulnerabilities-solving-cost-and-co]
Ningún LLM es invocado hasta la etapa tres. Las dos primeras son análisis de grafo estático pura.
En la Etapa 3, un agente Sonnet 4 clasifica cada unidad alcanzable por nivel de exposición—externamente expuesta, internamente expuesta, control de seguridad, o neutra. La iteración continúa hasta que la clasificación sea confiante o alcance un cap de 20 iteraciones. Costo: de $0,13 por iteración para funciones simples hasta $10,92 en el cap para cadenas de llamada complejas. Mediana en OpenSSL: 9 iteraciones por unidad. Después de la Etapa 3, las 390 unidades alcanzables colapsan a 49 externamente expuestas. Reducción total de 99,6 por ciento del count original. La Etapa 4 usa Claude Opus 4.6 para análisis de patrones de vulnerabilidad. De las 49, 28 fueron marcadas como potencialmente vulnerables.
¿Y el verificador adversarial—la Etapa 5—es donde la arquitectura diverge del estándar del mercado?
El modelo asume una persona de atacante con constraints explícitos: sin acceso a servidor, sin credenciales de base de datos, sin acceso a archivos locales, sin comandos CLI. Si el único camino de ataque viable requiere acceso shell local, el hallazgo es clasificado NOT EXPLOITABLE y descartado. Los prompts del tipo "actúa como un atacante" sin constraints son la causa raíz de tasas altas de falsos positivos en scanners basados en LLM—los modelos son agradables por defecto y construyen ataques plausibles que asumen capacidades que simplemente no existen en producción. La Etapa 6 convierte los candidatos supervivientes en ambientes de exploit reales, ejecuta en contenedores sandboxed de corta duración y destruye el ambiente después. Knostic está actualmente en el proceso de disclosure para hallazgos en OpenSSL, WordPress y Flowise. La implicación más amplia: el mismo modelo que tu agente usa para escribir código puede encontrar vulnerabilidades explotables en el código que otros agentes escribieron. La superficie de ataque y la superficie de detección ahora habitan el mismo stack.
Ahora hacia la dimensión que no estaba en el roadmap de ningún equipo de ingeniería hace seis meses: regulación y geopolítica como variable operacional concreta.
El 12 de junio de 2026, a las 17:21 horario del este americano, el secretario de Comercio Howard Lutnick invocó el Export Controls Reform Act para suspender el acceso a Fable 5 y Mythos 5 de Anthropic para todos los ciudadanos extranjeros—incluyendo empleados de Anthropic sin ciudadanía americana. Anthropic no tiene forma de verificar nacionalidad por solicitud de API. Hizo la única cosa que garantizaba compliance: desactivó ambos modelos globalmente. Tres días después del lanzamiento, cada llamada a la API retornaba error. [ref: us-export-ban-on-anthropic-fable-5-compliance-gates-for-model-selection-and-regi]
El gatillo técnico citado por el gobierno fue una técnica de jailbreak involucrando lectura de código para identificar fallos.
Anthropic dice que la misma técnica está disponible en otros modelos en producción, incluyendo GPT-5.5. Ningún jailbreak universal fue encontrado en red-teaming pre-lanzamiento conducido por el gobierno americano, el UK AISI y terceros. La carta de Lutnick no provee justificación específica de seguridad nacional. Anthropic discrepa con la decisión, está cumpliendo, y envió ingenieros seniores a Washington para negociar con el Departamento de Comercio. Al 17 de junio, no había fecha de restauración.
Los modelos que quedan en el catálogo de Anthropic: Claude Opus 4.7—62 por ciento en SWE-bench Pro, quince dólares por millón de tokens de entrada y setenta y cinco dólares por millón de tokens de salida—Claude Sonnet 4.5, Claude Haiku 4.5, y la familia Claude 4.5 completa. Cualquier solicitud para claude-fable-5 retorna error; cambiar a claude-opus-4-7 es una línea de código.
Pero Opus 4.7 no es un sustituto equivalente en tareas de código complejo y razonamiento multi-etapa. Los equipos que hardcodearon el endpoint de Fable 5 pasaron el fin de semana en incident bridges. Los equipos con gateways multi-provider hicieron un cambio de ruta—cero deploys de emergencia. La lección arquitectónica es directa: ECRA, escrito para controlar exportaciones de hardware, ahora se aplica a una API comercial de IA sin aviso previo y sin exención por usuario. La arquitectura que asume disponibilidad garantizada de modelo es demostrablemente frágil. El precedente fue establecido—cualquier modelo frontier puede ser blanco de una orden similar. Mantén fallbacks calientes con benchmarks actualizados. No firmes contratos que asuman disponibilidad continua de un modelo frontier específico.
El segundo frente regulatorio vino de donde pocos lo esperaban. Tennessee.
McMinnville y Coffee County aprobaron moratoriums unánimes el 9 de junio. El Metropolitan Council de Nashville siguió esa misma noche, avanzando una pausa de 90 días en todas las licencias de data center en Davidson County por 26 votos a 1. Warren County y Knox County estaban agendadas para votar el 22 de junio. Desde el otoño pasado, nueve ciudades y condados de Tennessee aprobaron moratoriums. Cinco en una sola semana. [ref: tennessee-counties-block-ai-data-centers-nashville-passes-near-unanimous-morator]
Dos proyectos concretos dispararon Nashville. DC Blox propuso un data center de 69.000 pies cuadrados y 10 MW adyacente al Nashville Zoo—con licencias ya protocoladas para una Fase 2 de 202.000 pies cuadrados y 40 MW en el mismo terreno, tres pisos. Más de 360.000 personas firmaron una petición contra el proyecto. McMinnville fue disparada por un data center de 96.064 pies cuadrados y 25 MW de Hixson, alimentado por gas natural y generadores diesel—cuyo desarrollador no consultó a autoridades locales antes de anunciar públicamente el proyecto. McMinnville aprobó un moratorium de 18 meses.
El decreto ejecutivo firmado por el alcalde Freddie O'Connell tiene un threshold con implicaciones prácticas directas para quien diseña clusters de inferencia: cualquier instalación encima de 20.000 pies cuadrados o consumiendo más de 5 MW se califica como gran data center sujeto a revisión. Una sola fila de 64 racks de GPUs clase H100 ya supera 5 MW antes de contabilizar el overhead de enfriamiento.
Y el patrón es nacional. Sesenta y nueve jurisdicciones enactaron moratoriums desde mayo de 2026. Nueva York, Seattle, Maine—el mismo patrón. Data Center Watch estima que al menos 75 proyectos totalizando aproximadamente 130 mil millones de dólares fueron bloqueados o atrasados solo en el primer trimestre de 2026—equivalente a toda la disrupción de 2025 comprimida en tres meses.
El administrador municipal de McMinnville, Nolan Ming, fue preciso: "Un moratorium no es una prohibición permanente. Es un timeout responsable." Pero un timeout de 18 meses en McMinnville y 90 días en Nashville no se alinean con los timelines de procurement de data centers—12 a 24 meses de selección de sitio a energización. Una pausa de permiso en el medio del proceso puede encallar contratos de interconexión y acuerdos de utilidad ya firmados. El Tennessee rural no es más una alternativa de bajo atrito para Ashburn o Phoenix. La selección de sitio ahora necesita incluir riesgo de oposición comunitaria antes del RFP.
Si la demanda por agentes es real—y los números de esta semana confirman que lo es—el hardware que los sustenta también tiene que reorganizarse. Dos movimientos concretos revelan dónde están los gargalos reales en la cadena de supply.
Primero: interconexión óptica. Coherent dio inicio a las obras de expansión de su fab en Sherman, Texas. El sitio alberga la primera fab de fosfeto de indio—InP—en wafers de seis pulgadas del mundo. La expansión recibe cincuenta millones de dólares del CHIPS Act, más diecisiete millones del programa Texas CHIPS y de la Sherman Economic Development Corporation. Jensen Huang y el CEO de Coherent, Jim Anderson, estuvieron presentes en la ceremonia de inauguración. [ref: coherent-expands-texas-optical-fab-to-scale-ai-backbone-capacity]
¿Por qué importa InP ahora específicamente?
El Vera Rubin Ultra NVL576 de NVIDIA conecta ocho racks NVLink con 72 GPUs Rubin Ultra cada uno—576 GPUs operando como un único dominio. A esa escala, con centenas de pies separando componentes a través del piso de un data center, el cobre falla en eficiencia energética. Los retimers y hardware de condicionamiento de señal para empujar señales eléctricas de alta velocidad por los ocho racks consumen potencia que el cluster preferiría gastar en compute. La óptica paga una penalidad de conversión una única vez—eléctrico a fotón—y después la distancia se vuelve esencialmente gratuita. A esa escala, el trade-off no es opcional.
El gargalo está en la producción de wafers. La mayoría de las fábricas de InP en el mundo operan en wafers de tres y cuatro pulgadas. Los wafers de seis pulgadas tienen aproximadamente cuatro veces el área utilizable de un wafer de tres pulgadas—el área se escala con el cuadrado del diámetro. Más die por run, menor costo por unidad, más headroom de supply.
Huang cuantificó el ritmo en la ceremonia de inauguración:
"Cincuenta años para crear la primera línea de InP en Sherman. En un año, la capacidad de producción se ha cuadruplicado."
En marzo, NVIDIA y Coherent formalizaron una alianza estratégica de múltiples años. NVIDIA comprometió dos mil millones de dólares para P&D, capacidad futura y manufactura doméstica, más un compromiso de compra de múltiples miles de millones en productos de láser e interconexión óptica. La expansión de Sherman ejecuta ese acuerdo. La dificultad de escalar no es área de piso—son los semiconductores compuestos en sí. InP y arseneto de galio usan fotoresistes diferentes, químicas de deposición diferentes y trabajan con wafers que se quiebran más fácilmente que silicio. El tooling, gestión de yield y cadenas de supply de químicos upstream son más finas que los equivalentes en silicio. El grant federal de cincuenta millones y los diecisiete millones en soporte estatal y local reflejan exactamente esa brecha: sin capital subsidiado, la economía de la expansión doméstica de semiconductores compuestos permanece marginal en los volúmenes actuales.
El segundo movimiento de supply chain es Intel—y los timelines aquí son tan decisivos como la tecnología.
El nodo 14A de Intel tiene su primer cliente externo comprometido: Tesla, para el complejo Terafab AI en Austin, con producción de prueba proyectada para 2029. Todo lo demás en el calendario de foundry de Intel—Ohio, Arizona, Oregon—depende de ese único cliente llevando a un segundo y tercero antes de dos deadlines que convergen en los próximos dieciocho meses. [ref: intels-14a-roadmap-arizona-ohio-timeline-hints-at-when-inference-chip-supply-tha]
¿Cuáles son esos deadlines?
Primero: el CEO Lip-Bu Tan dijo a inversionistas en enero de 2026 que compradores prospectivos del 14A tomarán decisiones firmes de proveedor a partir del segundo semestre de 2026 y extendiéndose hasta el primer semestre de 2027. Segundo: el crédito fiscal de manufactura avanzada de 35 por ciento—firmado en ley en julio de 2025—cubre solo construcción de fab que comience antes del 31 de diciembre de 2026. Los proyectos que se resbalen a 2027 pierden el crédito enteramente. Ambos relojes expiran con meses de diferencia, y ambos apuntan a los sitios de construcción en Ohio.
La producción actual permanece enteramente en Arizona. La Fab 52 en el campus Ocotillo en Chandler se convirtió en la primera instalación 18A de alto volumen de Intel en octubre de 2025, construyendo compute tiles de Panther Lake. El CTO Naga Chandrasekaran dijo que la fábrica es capaz de más de 10.000 wafer starts de 18A por semana—aproximadamente 40.000 por mes en capacidad total, excediendo las fases 1 y 2 combinadas de la Fab 21 de TSMC. Esa es capacidad evaluada, no throughput actual.
Los yields del 18A no alcanzarán niveles estándar industriales antes de principios de 2027. Tan confirmó en mayo de 2026 que los yields están mejorando 7 a 8 por ciento por mes. Intel está activamente limitando el output de CPUs. La segunda fábrica del Arizona, Fab 62, no tiene nó asignado y está en construcción con fecha de conclusión en 2028—funcionando como válvula de overflow para 14A si Ohio se atrasa, o capacidad adicional de 18A si los bookings externos llegan primero. Brookfield Infrastructure sostiene 49 por ciento de la joint venture de Chandler, e Intel no se movió para recomprar ese stake, así que cada wafer de ambas fábricas de Arizona carga obligaciones de revenue-share.
Ohio es el bet de larga duración. El sitio de New Albany entró en construcción en 2022, con una primera fase de 28 mil millones de dólares originalmente mirando producción en 2025. Un reset en febrero de 2025 empujó el Módulo 1 a 2030-2031 y el Módulo 2 a 2032. Intel ya gastó aproximadamente cinco mil millones de dólares en un terreno de casi mil acres con espacio para hasta ocho fábricas. El ritmo depende explícitamente de commits de clientes. Intel dice que preserva flexibilidad para acelerar si la demanda lo justifica.
Para arquitectos evaluando opciones no-TSMC: la ventana de decisión está abierta ahora y cierra a principios de 2027. Producción de riesgo en 2028, volumen significativo en 2029—el mismo timeline proyectado para el A14 de TSMC. Las señales de demanda están materializándose: las cargas de inferencia e IA agentiva están redefiniendo las ratios CPU-GPU. Tan dijo que los clientes reportan cambios de la norma de la era de entrenamiento—un CPU por ocho GPUs—a 1 a 1, y en algunos casos cuatro CPUs por GPU para inferencia. Los equipos queriendo capacidad en Ohio en 2030-2031 necesitan que sus socios de chip estén enganchados con Intel hoy.
Cerramos con una herramienta que parece infraestructura interna de investigación—pero tiene implicaciones estratégicas directas para cualquier organización que compra, despliega o audita capacidad de modelo.
Allen AI y Hugging Face lanzaron olmo-eval el 12 de junio—un harness open-source de evaluación que separa definición de benchmark de política de ejecución. El proyecto hereda de OLMES, el estándar de reproduciblidad de 2024 que estandarizó formateo de prompt y formulación de tareas para las familias OLMo y Tülu 3. OLMES resolvió inconsistencia entre papers. olmo-eval resuelve velocidad de loop de desarrollo. [ref: olmo-eval-standardizing-model-development-evals-at-scale]
¿Qué agrega concreto a lo que ya existe?
Error estándar y efecto mínimo detectable para cada resultado de benchmark, más comparación por instancia de preguntas idénticas entre checkpoints. La pregunta central: ¿es una variación de 2,4 puntos porcentuales entre iteraciones de entrenamiento señal real o varianza de muestra? Los backends de inferencia son intercambiables—GPU local, API comercial vía LiteLLM, o mock provider para dry runs sin costo. La arquitectura de seis abstracciones—Task, Suite, Harness, Formatter, Scorer, Metric—permite que la misma spec de task corra contra baseline, tool-augmented o contra API remota sin modificación. Las evaluaciones agentivas y multi-turn corren en contenedores Docker, Podman o Modal cuando sea necesario; el camino ligero es el predeterminado, y olmo-eval solo opta por el setup pesado cuando un benchmark de verdad lo requiere, a diferencia de herramientas que usan contenedores para todo.
El punto estratégico aquí no es técnico. Es sobre quién controla la narrativa del benchmark. Cuando un proveedor anuncia un salto de tres puntos en GPQA-Diamond, la pregunta relevante no es si el número es correcto. Es si el delta es estadísticamente distinguible del ruido dado el tamaño de muestra usado y si el threshold fue pre-registrado o elegido después de que los resultados llegaron.
Sin thresholds pre-registrados, cualquier herramienta estadística puede convertirse en racionalización post-hoc con barniz científico. olmo-eval entrega la infraestructura para hacer la pregunta correctamente. La disciplina de uso sigue siendo responsabilidad del equipo que opera la evaluación.
Agentes como unidad implantable. El stack de orquestración llegó—y traía la factura de costo junto. La regulación llegó—y estableció precedentes que ningún arquitecto de sistema puede ignorar: una API comercial de IA puede ser apagada por orden ejecutiva en 72 horas, y un rack de GPUs puede ser bloqueado por un voto de consejo municipal de 26-1. La cadena de supply comenzó a moverse—y los timelines son reales y cerrando. Lo que esta semana dejó claro es que la pregunta ya no es si los agentes llegan a producción. Es quién controla las políticas cuando llegan, y si tu arquitectura sobrevive cuando el modelo que elegiste desaparece de la API. Próxima Edición el viernes. Buena semana.