El primer Copilot Day: el agente ya no es una ventana, es un proceso

El jueves, de cinco a nueve de la tarde hora de aquí, GitHub retransmitió cuatro horas seguidas de Copilot Day. Es el primero que celebra con ese nombre: hasta ahora lo de Copilot iba dentro de Universe —que este año es el 28 y 29 de octubre— o repartido en talleres presenciales.

Lo vi a trozos, que es como se ven estas cosas cuando la retransmisión te pilla a la hora de cerrar el día. Y me quedé con una sensación rara, que es la que ha acabado siendo este artículo:

Casi nada de lo que enseñaron era nuevo. El agent host de VS Code lleva desde julio. La clave propia para usar tus modelos, desde abril. El SDK salió de vista previa en junio. Lo de Slack y Teams es de agosto. Lo más reciente del programa, HydraFusion, se había anunciado seis días antes.

Eso no es una crítica. Eso es la pista.

Porque cuando alguien dedica cuatro horas a enseñar cosas que ya estaban publicadas, no está anunciando. Está explicando. Y lo que estaba explicando tardé un rato en verlo, porque no era ninguna de las piezas: era cómo encajaban.

Qué fue exactamente

Vamos con los hechos antes que con las interpretaciones, que es el orden que intento respetar aquí.

Y los bloques del programa, que son lo que importa:

• Agent Skills
• HydraFusion
• Copilot en Slack y en Teams
• Claude, Codex y clave propia dentro de VS Code
• El SDK de Copilot y el Agent Host Protocol

Mientras el evento hablaba de eso, el changelog de esa misma semana iba publicando la otra mitad del dibujo, que nadie enseñó en directo porque no es vistosa:

Conviene decir con claridad qué es cada cosa, porque es fácil mezclarlas: el guion del evento salió del programa de arriba; la tabla es el contexto con el que yo lo he leído. Los permisos, el sandbox, los secretos y la caché no fueron el centro de la retransmisión. Son lo que estaba pasando al lado, y lo que a mí me terminó de ordenar el asunto.

Puestas en fila las dos listas, llama la atención que la mayoría de las entradas no hablan de que el modelo escriba mejor código. Hablan de dónde corre el agente, qué puede tocar y quién lo autoriza.

Lo que el evento estaba separando

Aquí está, creo, la idea del día, y no la dijo nadie con estas palabras porque estaba repartida entre cinco demostraciones.

Hasta hace bien poco, en la cabeza de cualquiera que use esto —en la mía, desde luego—, todo eso era una sola cosa: abro el editor, hay un chat, elijo un modelo en un desplegable y le hablo. Modelo, agente, procedimiento, conversación y ventana eran la misma caja.

Lo que GitHub lleva un año haciendo, y el jueves enseñó junto, es partir esa caja en piezas independientes:

Cinco capas que antes venían pegadas y ahora se pueden combinar por separado.

Eso es una arquitectura, no un producto. Y lleva a una consecuencia que es la que da título a esto y a la que voy a llegar por partes.

Primero: ya no se elige solo un modelo

La pieza que más me interesó no se anunció en el evento, sino seis días antes, aunque en la retransmisión tuviera bloque propio.

Se llama Project HydraFusion y es una research preview. La idea es sencilla de contar y bastante incómoda de asumir: en vez de que tú elijas un modelo en un desplegable y ese modelo resuelva tu petición, HydraFusion compone un flujo en tiempo de ejecución y reparte el trabajo entre varios modelos, de distintos proveedores, dentro de una sola interacción.

Elige entre tres patrones:

Fíjate en lo que hay debajo de esa tabla, porque no es una función de producto: es una postura. GitHub está diciendo que la pregunta «¿qué modelo uso?» está mal planteada, y que la buena es «¿qué composición de modelos conviene a esta tarea concreta?».

Los números, que es donde esto se pone honesto

Estas son las cifras que publica GitHub, comparando su mejor configuración contra Claude Opus 5:

Ahora léelo como lo leería un cliente al que le estás vendiendo esto.

Abarata en las tres. Mejora la calidad en una, se queda prácticamente empatado en otra y pierde un punto y medio en la tercera.

Esa frase es más larga que un titular y por eso no la vas a leer en ningún sitio. Pero es lo que dicen los números, y la diferencia importa: donde más pierde es en DeepSWE, que mide trabajo de ingeniería a nivel de repositorio —dependencias entre ficheros, arreglos de principio a fin—, o sea, la prueba que más se parece a lo que hago yo. Donde gana es en tareas de terminal.

Que conste que un punto y medio por un tercio menos de factura es un trato que yo firmo casi siempre. Lo que no firmo es la frase de que sale gratis.

Hay otra letra pequeña que importa más de lo que parece: GitHub dice que el mejor sitio para empezar son tareas de un solo turno y un solo prompt. Es decir, justo lo contrario de cómo trabajo yo, que es una conversación larga arrastrando contexto durante media tarde. Lo de varios turnos sigue siendo terreno de trabajo.

Y el coste, ojo, es «estimado». Se factura al precio estándar de tokens de cada modelo que intervenga, y en un patrón de cascada el modelo barato lo pagas siempre: el caro solo entra cuando el barato no ha llegado. Es una apuesta sobre la distribución de tus tareas, no un descuento.

Lo que esto me cambia a mí

En agosto escribí un artículo sobre lo de que la IA se abarata cien veces cuya tesis era que la tarifa por token no es el coste por tarea. HydraFusion es esa frase convertida en producto, y por eso me interesa tanto: es la primera vez que un fabricante grande dice en voz alta que el precio de la unidad no es la unidad que importa.

Y a la vez me señala una cosa que yo hacía mal y no me había parado a mirar.

Porque, ¿cómo elijo yo el modelo? Con sinceridad: por inercia y por rumor. Porque el mes pasado uno me fue bien con algo parecido, porque leí un hilo, porque el desplegable venía con ese puesto. No tengo una medida propia. No he comparado nunca dos modelos sobre el mismo encargo mío, con mi código, y contado lo que costó cada uno.

HydraFusion automatiza una decisión que yo, a decir verdad, nunca he tomado de forma razonada. Y eso está bien y da un poco de vergüenza al mismo tiempo.

Se prueba en la CLI de Copilot, en todos los planes, con /update, /experimental on y luego /model.

Segundo: tampoco eliges necesariamente un solo agente, ni un solo proveedor

Este bloque es el que yo me había perdido, y es el que mejor sostiene todo lo demás.

Desde la versión 1.129, de julio, VS Code corre los agentes en un proceso dedicado —el agent host— y ese proceso no ejecuta solo Copilot. Ejecuta harnesses distintos: Copilot, Claude y Codex. Se elige en un desplegable, como antes se elegía el modelo. El soporte se activa con el ajuste chat.agentHost.enabled.

Y el harness de Copilot, por dentro, usa el SDK de Copilot, el mismo que salió de vista previa en junio y que cualquiera puede empotrar en su propia herramienta. Por eso Copilot se comporta de forma coherente en la CLI, en la app y en el editor: no son tres integraciones construidas por separado, sino el mismo motor debajo —aunque cada superficie conserve su contexto y sus capacidades—.

A eso súmale la clave propia (bring your own key). GitHub la abrió en abril para Business y Enterprise, activada por defecto y con una política que el administrador puede apagar: permite usar en el chat de VS Code tus propias claves de Anthropic, Gemini, OpenAI, OpenRouter y Azure, y también modelos que corran en tu máquina con Ollama o Foundry Local. Lo paga tu proveedor, no consume la cuota de peticiones de Copilot, y no sirve para el autocompletado: solo para el chat. Desde entonces se ha ido ensanchando, y el jueves se vio hasta dónde: en la demostración, el flujo arrancó sin suscripción de Copilot, con OpenRouter de proveedor.

Junta las tres cosas y sale algo que no es una función, es una declaración de intenciones: el editor quiere ser la cabina. No la cabina de Copilot: la cabina, a secas. Tú pones el agente, tú pones el proveedor, tú pones la clave, y GitHub pone el sitio desde el que se conduce.

Los Agent Skills hacen lo mismo con el procedimiento. Son carpetas de instrucciones, scripts y recursos que el agente carga cuando vienen al caso, en vez de que tú vuelvas a explicar por enésima vez cómo se despliega esto o qué convenciones sigue aquel proyecto. Viven en el repositorio o en tu carpeta personal, funcionan en el agente de la nube, en la revisión de código, en la CLI, en la app y en el modo agente de VS Code y JetBrains, y —esto es lo llamativo— la especificación es un estándar abierto que comparten con Claude. Una misma skill se puede reutilizar entre agentes compatibles, aunque lo que consiga en cada uno dependa de las herramientas y los permisos que tenga allí.

Y luego está la superficie. Desde agosto, en vista previa, se puede mencionar a @GitHub en un canal de Slack o de Teams y abrir ahí una sesión del agente de la nube: contesta, investiga un fallo, implementa el cambio en un sandbox y abre un pull request enlazado a la conversación.

De todas estas piezas, la que yo aplicaría primero en un sitio pequeño son las skills. No necesitan plan de empresa, no son una vista previa y resuelven un problema que tengo todos los días.

Tercero: la sesión se va de la ventana

Debajo del agent host hay un protocolo, y es la pieza que de verdad me hizo levantar la cabeza.

Se llama Agent Host Protocol (AHP), lo publica Microsoft con licencia MIT, y resuelve un problema que hasta ahora se daba por bueno sin discutirlo: que la sesión de un agente vive dentro de la aplicación desde la que la abriste.

Con AHP, el agente corre en ese proceso aparte —el host— que es el que conserva el estado autoritativo y ordena los cambios. Los clientes se conectan a canales direccionados por URI, reciben una instantánea inicial del estado y luego una secuencia ordenada de acciones. Cada cambio lleva un número de secuencia monótono, los clientes aplican las cosas de forma optimista en local y reconcilian cuando el servidor les devuelve el eco.

Traducido de la jerga a lo que significa, tres cosas:

1. Sesiones compartidas. Varios clientes —el editor, la web, la CLI, el móvil— ven y conducen la misma sesión viva. Una sola sesión puede pintarse a la vez en varias ventanas de VS Code.
2. Ejecución remota. El host puede correr al lado del espacio de trabajo, en otra máquina.
3. Vida propia. La sesión puede seguir viva sin ningún cliente conectado: sobrevive a que cierres el editor, mientras siga en pie el proceso y la máquina donde corre.

Ese tercer punto es el que cambia la categoría de la cosa.

Un agente que puede seguir trabajando con el editor cerrado ya no es una ventana de chat. Es un demonio. Un proceso de larga duración, con estado, que puede estar haciendo cosas mientras tú no miras.

Y un demonio no se «usa». Un demonio se administra: se le pone un usuario, unos permisos, un sitio donde escribir, un registro y una forma de matarlo. Eso es lo que llevo haciendo veinte años con cualquier otro proceso que corra en un sitio del que yo respondo, y no veo por qué este iba a ser distinto.

Y por eso lo importante de la semana fue lo más aburrido: los permisos

Si has llegado hasta aquí, esto ya se ve venir. Y no estaba en el programa del evento, sino en el changelog del día anterior.

El 9 de septiembre GitHub publicó permisos gestionados para las operaciones del agente, disponibles de forma general para administradores de Business y Enterprise. Se controlan tres cosas:

• Comandos de shell
• Lecturas y ediciones de ficheros
• Dominios de red

Y cada una puede estar en uno de tres estados: bloqueada, requiere aprobación humana, o pasa sin preguntar. Funciona en la app de Copilot, en la CLI y en las sesiones de VS Code que usan el Agent Host —o sea, exactamente en la arquitectura de la que hemos estado hablando— y se pueden hacer políticas distintas para equipos distintos.

Pero la frase que de verdad importa es esta otra, y la traduzco entera porque es la única línea de todo el anuncio que cambia algo de fondo:

Las restricciones gestionadas no pueden debilitarse mediante ajustes de usuario o de espacio de trabajo, autoaprobación o aprobaciones guardadas previamente.

Léela otra vez. Eso es un control externo. No es una instrucción. No es una recomendación en el AGENTS.md. No es un «por favor, no toques producción» puesto en el prompt.

Y resulta que eso es lo que yo pedía en la segunda entrega de «IA en producción», donde el argumento entero era que una instrucción en lenguaje natural no es un control de acceso: no es externa a quien la obedece, no falla de forma segura y no es auditable.

Pues GitHub ya ha construido ese control externo. Al menos las dos primeras propiedades, y al menos para Business y Enterprise, que es una limitación que toca decir en voz alta en un blog que lee mucha gente que trabaja sola o en equipos de tres. De lo de auditable, el anuncio no dice nada, así que yo tampoco.

Los secretos, la caché y los veinticinco arreglos

Una vez que ves el patrón, las demás novedades de la semana dejan de parecer un surtido. Todas contestan a la misma pregunta: si esto es un servicio, ¿qué le dejamos hacer?

Bloquear la fusión de un pull request con secretos sin resolver. Una regla de ruleset que comprueba dos cosas antes de dejar fusionar: que el escaneo de secretos haya terminado sobre el último commit, y que no queden alertas abiertas por secretos que introduzca ese PR. Está en vista previa pública y necesita Secret Protection o Advanced Security. No sustituye a la protección en el push: la complementa, porque pilla lo que aquella no pilla o no está configurada para pillar.

Esto, exactamente esto, es lo que le faltaba al caso que conté hace dos días: una red social generada entera por IA con un millón y medio de credenciales expuestas a los pocos días de nacer. Una regla que no deja fusionar no habría arreglado aquel diseño, pero sí es la clase de control que no depende de que nadie se acuerde.

cache-mode en Actions. Cuatro modos —read, write, write-only, none— para dar acceso mínimo a la caché por flujo o por tarea. Por defecto es read en eventos poco fiables como pull_request_target y write en los fiables como push. El ajuste de la tarea pisa al del flujo, se propaga a los flujos reutilizables —el llamado no puede exceder al que llama— y declarar write en un evento de poca confianza te saca un aviso. El motivo es el envenenamiento de caché. Está disponible en github.com en todos los planes, que no es poca cosa después del párrafo anterior. Eso sí: solo te sirve si usas Actions.

Autofix agéntico para Code Quality. Seleccionas hasta 25 hallazgos de una página, se los asignas a Copilot en una sola acción, y él los arregla en una rama, valida sus propios cambios y te abre un pull request. Necesita Code Quality en Team o Enterprise Cloud y consume créditos de IA.

De las tres, la que más me hace pensar es la última, y no por lo que hace, sino por lo que traslada. Veinticinco arreglos en un PR. El trabajo de generar se abarata otra vez; el de revisar no se abarata en la misma proporción, y lo sigue pagando una persona.

El contrapeso, que si no esto es una nota de prensa

Cuatro cosas que no aparecen en el titular y me parecen tan informativas como lo que sí aparece.

Una. Ya está dicho arriba, pero conviene repetirlo: HydraFusion abarata en las tres pruebas y solo supera a Opus 5 en una. Y las pruebas las elige, las corre y las publica quien vende.

Dos, y esta es la que me da que pensar. El mismo día del evento, GitHub retiró MAI-Code-1-Flash de todas las experiencias de Copilot: chat, ediciones en línea, modos ask y agent, y autocompletado. La alternativa indicada es MAI-Code-1.1-Flash, y en las empresas hay que habilitarla en las políticas de modelos.

Es decir: el mismo día que te enseñan cómo montar flujos de trabajo sobre modelos, desaparece un modelo. Y no es la primera vez ni será la última. Si has ajustado instrucciones, temperaturas o costumbres alrededor de uno concreto, tienes un sustituto, sí, pero sustituir el modelo no te devuelve exactamente el flujo que tenías.

En el artículo del jueves por la noche decía que mi horizonte de previsión se había encogido de diez años a mañana. Esto es lo mismo visto desde el otro lado y en pequeñito: el modelo sobre el que montaste el flujo del mes pasado puede no estar el mes que viene, y esa decisión no la tomas tú.

Tres. Buena parte de lo que se enseñó es vista previa. HydraFusion es research preview; la regla de secretos, vista previa pública; lo de Slack y Teams, vista previa pública desde agosto —y ahí, además, las sesiones consumen créditos de IA y el sandbox de la nube se factura aparte, con su propio contador—. Y una parte relevante del resto es solo para Business y Enterprise. Lo que se ve en una retransmisión no es lo que puedes montar el lunes; es lo que podrás montar si sobrevive a la vista previa. Yo ya me he comido alguna.

Cuatro. Y esta es de honestidad conmigo mismo, porque es fácil confundirse aquí. Los números de HydraFusion sí miden calidad: miden tareas verificadas como resueltas sobre unas pruebas concretas. Lo que ninguna de estas novedades demuestra es que el código salga más seguro, más mantenible o mejor diseñado. Nadie mide lo que cuesta revisar ese código dentro de seis meses, ni cuántas vulnerabilidades arrastra.

Y ese hueco tiene datos, que son los que traía la quinta entrega de la serie: la corrección sintáctica del código generado supera el 95 % y el aprobado en seguridad sigue clavado en torno al 55 %.

Esa distancia no la cierra ningún enrutador de modelos.

Lo que me llevo al lunes

Sin épica. Cinco cosas de tamaño real, que es a lo que aspira esto.

1. Escribir las skills que llevo dos años repitiendo a mano. Es lo único de todo el evento que puedo aplicar hoy, sin plan de empresa y sin esperar a que salga de vista previa: el despliegue de un cliente, las convenciones de un proyecto, el repaso previo a tocar producción.
2. Escribir la política antes que el prompt. Qué comandos puede ejecutar, qué ficheros puede tocar, a qué dominios puede salir. Si tengo el plan que me deja imponerlo desde arriba, lo impongo desde arriba; si no, lo escribo igual y lo reviso a mano, que es peor pero no es nada.
3. Probar HydraFusion en algo que no duela, y medirlo con lo mío. TerminalBench no es mi trabajo. Mi trabajo es un WordPress de 2019 con un plugin que nadie mantiene. Dos tardes, dos encargos reales, y anotar lo que costó cada uno.
4. Tratar la versión del modelo como una dependencia y anotarla. Si MAI-Code-1-Flash se puede evaporar un jueves, cualquiera puede. Que quede escrito con qué se hizo cada cosa, como se anota la versión de PHP.
5. No confundir la vista previa con producción. Ni delante de un cliente, ni delante de mí.

Vuelvo a lo del principio, que es lo único que me parece que aporta este artículo.

Casi todo lo que se enseñó el jueves ya estaba publicado, algunas cosas desde hacía meses. El evento no fue el anuncio: el evento fue el marco. Cuatro horas para enseñar juntas cinco piezas que llevaban un año saliendo por separado, y que separadas no dicen nada.

Juntas dicen que el agente ha dejado de ser una ventana en la que escribes.

Corre en su propio proceso. Sobrevive a que cierres el editor. Lo ven varios clientes a la vez. Puede no ser el de la casa. Puede usar tu clave y tu proveedor. Carga procedimientos escritos por ti que también entiende la competencia. Se le conceden permisos, y hay quien los concede por encima de ti. Y elige por su cuenta con qué modelos trabajar, puede que con varios a la vez.

Nada de eso es una función del editor. Todo eso es un servicio corriendo en un sitio del que alguien responde.

Y de eso sí sé. Eso lleva teniendo el mismo manual desde antes de que existiera ninguna de estas empresas: usuario propio, permiso mínimo, registro de lo que hace y un interruptor para apagarlo.

Lo que ha cambiado no es el manual. Es que ahora hace falta aplicárselo a algo que escribe código.

El evento fue la retransmisión GitHub Copilot Day live: new releases, real workflows, and live coding, del 10 de septiembre de 2026. Las novedades de esa semana están en el changelog de GitHub: permisos gestionados del agente, bloqueo de PR con secretos, autofix de Code Quality, cache-mode en Actions y la retirada de MAI-Code-1-Flash. HydraFusion, con sus cifras, en el artículo de GitHub del 4 de septiembre y en la discusión de la comunidad; la lectura crítica de esas cifras, en VentureBeat. Los Agent Skills, en la documentación de GitHub; la clave propia en VS Code, en su anuncio de abril; el SDK, en el suyo de junio. La especificación del Agent Host Protocol está publicada en microsoft.github.io/agent-host-protocol, y el estreno del agent host en VS Code 1.129 lo resumió Help Net Security. Las traducciones de las citas son mías.