HydraFusion de Copilot construye un flujo de trabajo de modelos por solicitud: el contexto de tu proyecto debe vivir fuera de todos ellos (2026)

Cinco cosas en la publicación importan para esta pregunta, y las cinco están en las propias palabras de GitHub.

Primero, la unidad de decisión. "Para cada solicitud, HydraFusion actualmente elige uno de tres patrones de ejecución". Estos son Single (Único), donde "un modelo seleccionado resuelve la tarea directamente"; Cascade (Cascada), donde "un modelo eficiente redacta una solución y una puerta de calidad decide si la acepta o la escala a un modelo más fuerte"; y Critique (Crítica), donde "un modelo redacta un resultado, un crítico independiente de solo lectura de una familia de modelos diferente lo revisa, y el modelo redactor lo revisa una vez".

Segundo, el crítico está deliberadamente aislado. GitHub enumera la "Revisión aislada" como uno de los cinco principios operativos: "Ejecutar los pasos de revisión en contextos aislados y sin herramientas, mientras que los pasos del solver utilizan el espacio de trabajo compartido y el bucle de agente normal con reconocimiento de permisos. Esto permite a los modelos evaluar el trabajo de forma independiente sin modificar el repositorio". El crítico lee. No puede tocar tus archivos y no lleva tus herramientas.

Tercero —la frase que la cobertura omitió por completo—, el registro de lo que sucedió existe, pero al otro lado del muro. "Internamente, el entorno de ejecución registra el rol, el resultado, el costo, la latencia y los diagnósticos de cada etapa para que el flujo de trabajo pueda entenderse después de la ejecución. Externamente, el desarrollador recibe una respuesta coherente y un conjunto de cambios con reconocimiento de permisos".

Cuarto, el trabajo intermedio se retiene a propósito, y GitHub explica por qué: "Hoy: HydraFusion muestra las etapas del flujo de trabajo pero retiene los borradores intermedios hasta que devuelve un resultado coherente", porque "esos borradores pueden ser revisados, modificados o descartados, por lo que mostrarlos en vivo podría hacer que el trabajo inacabado parezca final". GitHub nombra la compensación en lugar de ocultarla —"Esperar sin suficiente visibilidad es una compensación real para los desarrolladores"— y dice que está "explorando activamente mejores actualizaciones de progreso".

Quinto, el alcance propio de la vista previa. "Para esta vista previa, las tareas de codificación de un solo turno y un solo prompt son el mejor lugar para comenzar. A continuación, nos centraremos en un sólido rendimiento multi-turno con sesiones iterativas más largas". GitHub también advierte que "los resultados, modelos, flujos de trabajo, disponibilidad, nombres y comportamiento del producto pueden cambiar a medida que aprendamos de la vista previa". Se ejecuta a través de /experimental en Copilot CLI en todos los planes.

Juntos, estos cinco puntos describen un sistema optimizado para entregarte una respuesta limpia por solicitud, un objetivo de diseño razonable, y uno en el que el razonamiento que produjo la respuesta es un artefacto del entorno de ejecución en lugar de uno duradero.

No cambia lo que hace un buen archivo de instrucciones. Copilot sigue leyendo tus archivos de instrucciones, y el propio informe de ingeniería de GitHub de dos días antes hace explícito el mecanismo: "Los prompts llevan instrucciones que dan forma a cómo funciona un agente, y se envían al modelo en cada turno". Las instrucciones se vuelven a enviar, no se recuerdan. Eso ya era cierto con un modelo, y es cierto con tres.

Sí cambia quién está acumulando. En una sesión de un solo modelo, existe al menos la intuición —generalmente errónea, pero intuición al fin— de que el modelo está "conociendo" la base de código a medida que avanzas. Con un plan de ejecución por solicitud, esa intuición no tiene dónde aferrarse. El crítico que detectó tu condición de carrera fue, en palabras de GitHub, un "crítico independiente de solo lectura de una familia de modelos diferente". Vio el borrador, formó un juicio y su juicio te llegó comprimido en un resultado revisado. No estará en la sala la próxima vez, y ninguna parte de la cadena retiene lo que notó. Si el enrutamiento es por solicitud y el grupo de modelos puede cambiar a medida que GitHub "evalúa e incorpora" nuevos modelos, cualquier cosa que desees que esté presente de manera confiable debe declararse en algún lugar que el enrutador no pueda esquivar.

And esto no es una peculiaridad de un solo proveedor. Amp, de Sourcegraph, documenta una arquitectura casi idéntica desde un punto de partida completamente diferente. Su página de Modos y Modelos dice que Amp "utiliza diferentes modelos para diferentes tipos de trabajo. El agente principal maneja tu tarea, los subagentes especialistas se encargan de partes enfocadas de la misma, y los modelos de sistema más pequeños manejan trabajos de soporte", y que "los modelos pueden cambiar a medida que haya mejores opciones disponibles, mientras que el rol de cada modo y subagente se mantiene estable". En cuanto a la cuestión del aislamiento, Amp es más directo que GitHub: sus subagentes especialistas "trabajan de forma aislada, por lo que no pueden comunicarse entre sí, no puedes guiarlos a mitad de la tarea, y comienzan con las instrucciones y el contexto que les da el agente principal en lugar de la conversación completa. El agente principal solo recibe su resumen final en lugar de monitorear su trabajo paso a paso".

Dos productos independientes, dos conjuntos de documentación independientes, la misma conclusión: la ejecución compuesta aporta calidad y eficiencia de costos, y el precio es que el entendimiento intermedio se resume en lugar de retenerse. Ese es un resultado arquitectónico, no una crítica a ninguno de los equipos. Simplemente significa que la capa duradera tiene que estar en otro lugar.

"Es solo un selector de modelos más barato". El enfoque en el precio lideró la mayor parte de la cobertura, y pasa por alto que la composición cambia por solicitud. Un selector elige una sola cosa. HydraFusion construye un plan, y GitHub describe el movimiento como "pasar de elegir el mejor modelo a construir dinámicamente la mejor manera de resolver cada tarea".

"Entonces la revisión del crítico está en mi historial". No lo está, por diseño. Recibes "una respuesta coherente y un conjunto de cambios con reconocimiento de permisos". El registro de cada etapa es interno.

"El multi-turno está en camino, así que esto se resuelve solo". GitHub dice que el rendimiento multi-turno es lo siguiente, lo cual se refiere a la calidad de las sesiones más largas. Una sesión mejor sigue siendo una sesión. Nada en la publicación sugiere la persistencia entre tareas de lo que aprendió una ejecución, y tratar "multi-turno" como sinónimo de "memoria duradera" es lo que hace que los equipos vuelvan a explicar en octubre las restricciones que explicaron en septiembre.

"Entonces Copilot no tiene memoria". Incorrecto, y vale la pena decirlo claramente. Copilot tiene superficies de memoria documentadas, y esta vista previa no es una de ellas. La afirmación precisa es más acotada: el comportamiento documentado de HydraFusion cubre la planificación de la ejecución y la entrega de resultados, y no hay un equivalente documentado en él para un almacén que acumule hechos del proyecto a través de las tareas. Esa es una declaración de alcance sobre la característica, no una afirmación sobre el producto.

La estrategia no es luchar contra el enrutador. Es dejar de pedirle a cualquier modelo de la cadena que sea el que recuerde, y colocar una capa pequeña y explícita donde cada etapa de cada plan pueda leerla.

Paso 1: Separa los dos tipos de contexto que estás mezclando actualmente

Divide cada línea de tu archivo de instrucciones en uno de dos grupos.

El primero es cómo trabajar aquí: comandos de construcción, pasos de revisión, restricciones de estilo, directorios que no se deben tocar. Esto pertenece a los archivos, se vuelve a enviar en cada turno, exactamente como hoy. Tanto GitHub como Amp lo manejan bien y no deberías moverlo.

El segundo grupo es lo que establecimos: la decisión de abandonar el analizador de streaming y por qué, el hecho de que el servicio de pagos utiliza un comando de prueba diferente debido a un sandbox del proveedor, los dos enfoques ya probados en la prueba de integración inestable. Este grupo crece continuamente, se descubre durante el trabajo en lugar de escribirse por adelantado, y es exactamente lo que un plan por solicitud no puede contener, porque la etapa que lo descubrió fue aislada y resumida.

Si tu archivo de instrucciones contiene actualmente contenido del segundo grupo, has estado utilizando un prompt reenviado como almacén de memoria. Funciona hasta que deja de hacerlo, y compite silenciosamente por el mismo presupuesto que el primer grupo.

Paso 2: Captura en el momento de la corrección, no al final de la sesión

El material valioso aparece cuando le dices al agente que se equivoca. Ese es el momento en que una restricción se vuelve explícita, y el momento en que es menos probable que escribas algo, porque quieres terminar la tarea.

Haz que sea una sola acción en lugar de una tarea pesada. Cuando corrijas al agente, expresa la corrección como un hecho duradero —"las pruebas del servicio de pagos se ejecutan a través de make test-payments, no de npm test, porque el sandbox del proveedor necesita el servidor de fixtures"— y envía esa frase a tu capa de memoria en lugar de solo al chat. La razón es lo que hace que sobreviva al contacto con una decisión futura; una regla simple sin justificación se anula la primera vez que resulta inconveniente.

Paso 3: Dale a cada etapa del plan la misma ruta de lectura

El punto de colocar la capa fuera es que no le importa qué modelo se esté ejecutando. Una etapa de solver, una escalada en cascada y una nueva sesión mañana llegan al mismo almacén de la misma manera. En la práctica, eso significa exponerlo a través de MCP, para que cualquier cliente que hable el protocolo pueda leerlo, y a través de una API para las superficies que no puedan.

Eso también soluciona el problema del aislamiento desde la otra dirección. El crítico de GitHub se ejecuta "sin herramientas" por diseño, por lo que no consultará nada a mitad de la revisión, pero el modelo redactor, que sí utiliza el espacio de trabajo compartido, puede extraer los hechos establecidos antes de escribir. Introducir la restricción en el borrador es mejor que detectarla en la revisión.

MemoryLake es la capa que construimos exactamente para este tipo de problema: un almacén que sobrevive a cualquier modelo, sesión o plan de ejecución en particular.

Paso 1: Crea una clave API

Genera una clave y realiza tu primera solicitud en unos treinta segundos. La clave es lo que permite que un flujo de trabajo enrutado, una sesión de CLI y el editor de un compañero de equipo lean los mismos hechos sin que ninguno de ellos sea el propietario.

Paso 2: Sube tus primeras memorias

Arrastra los documentos, imágenes y archivos que ya contienen las decisiones establecidas de tu proyecto: notas de arquitectura, el informe de incidentes detrás de la política de reintentos actual, el documento de diseño sobre el que todos siguen discutiendo. Comienza con lo que estás cansado de volver a explicar en lugar de intentar ser exhaustivo.

Paso 3: Conecta tu IA y agentes

Dale acceso a Claude, Codex, OpenClaw y otros agentes a través de MCP o la API. Para los flujos de trabajo de Copilot CLI, lee las memorias relevantes al inicio de una tarea para que los hechos estén presentes en el borrador, y registra las correcciones que realices durante la misma.

Lo primero que notas es la desaparición de un tipo específico de conversación repetitiva. No "qué hace esta función" —los agentes siempre han sido buenos en eso—, sino "probamos eso en julio y rompió el entorno de staging". Esa frase deja de ser algo que un humano tenga que proporcionar.

Lo segundo es que los cambios de modelo dejan de costarte. GitHub dice: "cuando haya nuevos modelos disponibles en GitHub Copilot, podemos evaluarlos e incorporarlos a su grupo de modelos". Si tu conocimiento duradero vive fuera del grupo, un cambio en el grupo es un cambio en la calidad y el costo, no en lo que sabe tu agente. Esa es la diferencia entre una actualización y una migración.

Lo tercero es que el crítico aislado se convierte en una pérdida menor. No puedes ver su razonamiento, y probablemente no deberías querer hacerlo; el argumento de GitHub de que mostrar borradores descartados "could make unfinished work appear final" (podría hacer que el trabajo inacabado parezca final) es sólido. Pero cuando su juicio surge como un cambio que aceptas, puedes registrar la conclusión en una sola frase. El razonamiento se queda en el entorno de ejecución; la conclusión pasa a ser tuya.

Lo cuarto importa principalmente a los equipos: un almacén que cualquier cliente puede leer es un almacén que el agente de un nuevo ingeniero puede leer desde el primer día, por lo que el conocimiento deja de ser propiedad de quien haya tenido la sesión larga.

"Escribe conclusiones, no transcripciones". Un flujo de trabajo enrutado produce mucho material intermedio que nunca ves. No intentes reconstruirlo. Registra el resultado en una sola línea y la razón.

"Conserva los archivos de instrucciones solo para invariantes". Cualquier cosa que sea cierta independientemente de en qué estés trabajando pertenece a los archivos; cualquier cosa descubierta pertenece al almacén. Mezclarlos pone los hechos descubiertos en competencia con los comandos de construcción por el mismo presupuesto de prompt.

"Adjunta la razón a cada hecho". "Usa make test-payments aquí" se anula. "Usa make test-payments aquí porque el sandbox del proveedor necesita el servidor de fixtures" no.

"Registra los reemplazos en lugar de eliminar". Cuando una decisión se revierta, dilo y di cuándo. Un archivo que conserva cada versión no resuelve nada; un almacén que descarta silenciosamente la versión anterior no puede explicar la nueva.

HydraFusion es una apuesta bien argumentada de que la próxima ganancia en agentes de codificación proviene de componer modelos en lugar de elegir uno. Sus cinco principios operativos —revisión aislada, ejecución acotada, aplicación a prueba de fallos, enrutamiento validado, contabilidad completa— se leen como un equipo que pensó cuidadosamente en ejecutar el repositorio de otra persona.

Lo que la apuesta también hace, silenciosamente, es retirar una suposición. Ya no hay un solo modelo detrás de tu sesión que plausiblemente pueda ser el que recuerde. El enrutador elige un nuevo plan por solicitud, el crítico está aislado a propósito, y lo que te llega es una respuesta y un conjunto de cambios. Amp documenta la misma forma desde una dirección diferente, lo que sugiere que aquí es hacia donde se dirigen los agentes compuestos en general.

La respuesta práctica es pequeña. Decide qué parte de tu contexto es invariante y cuál es descubierta. Deja la parte invariante en los archivos donde ya funciona. Coloca la parte descubierta en algún lugar que ningún plan de ejecución pueda esquivar, adjunta la razón a cada entrada y permite que el modelo que gane la próxima decisión de enrutamiento la lea. Entonces, el grupo de modelos puede cambiar tan a menudo como GitHub quiera, y lo único que cambia es qué tan rápido se escribe tu código.