¿Quién se toma el trabajo de leerse un paper de 88 páginas que habla de la arquitectura concreta detrás de DeepSeek Harness? Nosotros lo hemos hecho.
"A Programming Paradigm for Spatiotemporal Composability" es el paper detrás de la arquitectura de plugins basada en Cordis sobre la que se ha construido el dsh.
Son 88 páginas ( aquí tienes el PDF ) que responden a una pregunta muy concreta: ¿cómo se compone software que cambia mientras está corriendo? La respuesta del paper tiene forma de cálculo y de cinco teoremas demostrados. Pero leerlo, junto a las evidencias, puede ser un poco tedioso.
Lo firman tres autores: Yifan Shi, que aparece con doble filiación, Universidad de Pekín y DeepSeek-AI; Wei Zhang, de la Universidad de Pekín; y Tianyi Cui, de DeepSeek-AI.
Es un paper de lenguajes de programación escrito desde dentro de un laboratorio de IA.
Así que hemos creado una guía de lectura: qué problema hay debajo, qué es Cordis, quién lo firma, qué demuestran los teoremas y qué parte está funcionando ya en código real.
El problema: cambiar un sistema que está funcionando sin romper nada
Imagina un sistema que está funcionando y al que quieres añadir una capacidad nueva sin detenerlo. Por ejemplo, una herramienta nueva de visión a un modelo o a un harness.
Esa capacidad puede depender de una base de datos, de un modelo o de otro servicio, y más tarde puedes querer retirarla, cambiarla, sustituir una dependencia o recargar el componente.
La parte difícil llega después de añadir o quitar el código: garantizar qué ocurre con todo lo que ese código había registrado, qué dependencias siguen disponibles y en qué estado queda el sistema cuando el cambio termina.
En muchos sistemas, buena parte de esa responsabilidad recae sobre código de infraestructura y convenciones de los desarrolladores. Lo que Cordis propone es intentar llevarla a la semántica del propio runtime, con reglas explícitas para los cambios dinámicos y propiedades que puedan demostrarse formalmente.
Qué es Cordis y qué tiene que ver con DeepSeek Harness
Cuando DeepSeek publicó DeepSeek Harness el 13 de agosto de 2026, junto a V4-Pro, casi toda la atención se fue al agente.
Pero a nosotros nos interesó mucho más el harness. Porque debajo hay algo menos vistoso y más interesante: Cordis, el framework de plugins sobre el que está montado todo.
En DeepSeek Harness no existe un núcleo protegido en el sentido tradicional. Las capacidades del agente, o sea, los modelos, las herramientas, las sesiones, los permisos y la propia interfaz, se estructuran como plugins que se registran en un contexto compartido.
Cordis pone las reglas por las que esos plugins se cargan, se descargan y conviven mientras el sistema sigue en marcha.
Pero Cordis no nació con el harness. Es un proyecto anterior, con años de producción encima y repositorio propio , que DeepSeek Harness incorpora como dependencia. El paper que nos ocupa es la formalización de unas reglas que Cordis ya venía aplicando en código.
Cómo funciona ese micronúcleo por dentro, con sus servicios, sus eventos tipados y su contexto compartido, está contado en nuestra sección dedicada a Cordis .
La idea central de Cordis: dos dimensiones del cambio dinámico
El paper separa el problema de la composición dinámica en dos dimensiones ortogonales: tiempo y espacio. La palabra "spatiotemporal" es la parte más importante del título, y le dedican medio paper.
Tiempo: los efectos revertibles (revertible effects)
La primera dimensión es el tiempo, y la herramienta son los revertible effects, o efectos revertibles.
Todo lo que un plugin hace al cargarse, como registrar un comando, engancharse a un evento o abrir una conexión, es un efecto sobre el contexto compartido.
En este modelo cada efecto lleva consigo su inversa, que el runtime va apuntando. Cuando el plugin se descarga, el sistema ejecuta esas inversas y revierte sus efectos: no debería quedar un listener huérfano, una conexión abierta o un comando fantasma.
La idea importante es que deshacer deja de depender de una función de limpieza escrita a mano y pasa a formar parte de las reglas del modelo.
La sección de efectos revertibles lo cuenta con más detalle.
Espacio: los coefectos reactivos (reactive coeffects)
La segunda dimensión es el espacio, y ahí entran los reactive coeffects, o coefectos reactivos.
Si un efecto es lo que tu plugin le hace al sistema, un coefecto es lo que tu plugin necesita del sistema: una base de datos, un modelo o un servicio del que depende.
En Cordis esas necesidades se declaran, y el runtime utiliza la declaración para gestionar el ciclo de vida: no activa el plugin hasta que lo declarado está servido, y reacciona cuando las dependencias cambian, desactivando o reconfigurando el componente cuando corresponde. La dependencia deja de ser una línea en un import y pasa a ser algo que el sistema vigila en tiempo de ejecución.
La sección de coefectos reactivos recorre el ciclo completo de activación y desactivación.
El movimiento central del paper es unificar las dos caras en un único tipo de contexto, de forma que efectos y coefectos se siguen con la misma maquinaria. Sobre esa base define qué es un componente y construye un cálculo de composición dinámica: las reglas formales de un sistema donde las piezas entran y salen sin detener el conjunto.
Los cinco teoremas del paper de Cordis, explicados
La metateoría es lo más tedioso de revisar e incorporar a la divulgación. Pero el paper trae consigo cinco resultados demostrados sobre el cálculo. Esto es lo que dice cada uno.
| Teorema | En lenguaje llano | Qué propiedad aporta |
|---|---|---|
| Preservación | Ningún paso válido, sea cargar, descargar o recargar, deja el sistema en un estado mal formado | Después de cada movimiento, el sistema sigue cumpliendo sus propias reglas |
| Composabilidad temporal | Revertir los efectos de un componente devuelve el sistema al estado en que estaría si no hubiera actuado, aunque otros hayan seguido trabajando entre medias | Deshacer es exacto |
| Composabilidad espacial | Nadie se activa sin sus dependencias servidas, y a nadie le retiran una dependencia mientras la usa | Quien provee algo solo se retira cuando sus dependientes han desactivado |
| Progreso | Mientras el grafo de dependencias no tenga ciclos, toda transición pendiente termina por completarse | El sistema no se queda atascado a medio cambio |
| Confluencia | Bajo las condiciones del teorema, distintos órdenes de cambios llevan al mismo estado estable | El resultado final no depende de la historia dinámica |
La confluencia es la que manda. Un sistema que lleva horas cargando y descargando piezas converge al mismo estado que habrías obtenido montando de una vez, en orden de dependencias, los componentes que quedaron activos.
La sección de teoremas desarrolla los enunciados formales, con sus condiciones y su notación.
Lo que los teoremas no dicen
Esta parte importa tanto como los propios resultados. Un teorema demostrado sobre un modelo formal es una afirmación sobre ese modelo, bajo sus condiciones.
Aquí las hay, y el paper las enuncia. La confluencia, por ejemplo, se demuestra asumiendo que el grafo de dependencias no tiene ciclos y que los pasos implicados son independientes entre sí. Fuera del modelo queda casi todo lo demás: que el código de cada plugin haga lo que promete, que la implementación real del runtime sea fiel al cálculo, que la red y el disco se comporten como esperamos. El propio estudio de caso reconoce una limitación importante: la evidencia viene de un único ecosistema en un único lenguaje y es observacional.
Del paper a producción: Koishi y los 49 paquetes del harness
Lo que hace singular a *A Programming Paradigm for Spatiotemporal Composability* frente a muchos papers de lenguajes es la dirección del viaje: el código llevaba años en producción cuando llegó la formalización.
Cada construcción del cálculo tiene su contrapartida en la API de Cordis. El efecto que en el paper lleva su inversa es lo que un plugin registra al cargarse, el coefecto es la lista de dependencias que declara y las transiciones del cálculo corresponden al ciclo de vida que el runtime ejecuta de verdad. La pieza sobre DeepSeek Harness recorre esa correspondencia símbolo a símbolo , con la API real al lado de cada definición.
El caso de estudio del paper es Koishi, un framework de chatbots de código abierto construido sobre Cordis que en cuatro años ha acumulado más de 4.000 plugins de la comunidad. No demuestra que el modelo sea correcto en todos los sistemas posibles, pero sí que sus abstracciones se usan en un ecosistema real con contribuidores independientes.
DeepSeek Harness es la otra prueba de vida. En el commit 47f9438, que usamos como referencia para este análisis, el repositorio estaba organizado en 49 paquetes, todos ellos plugins sobre ese mismo núcleo.
Qué cambia si tienes agentes de IA en producción
Si tienes agentes en producción, su lista de capacidades rara vez se queda quieta: una herramienta nueva este mes, un modelo que entra, una integración que se retira. Hoy, muchos de esos cambios terminan implicando un redeploy o una lógica específica para tocar un sistema vivo sin dejar recursos pendientes ni dependencias rotas.
Lo que aporta el paper es una base formal para esos cambios: sobre un runtime que implemente este modelo, puedes añadir y quitar capacidades a un agente en producción sin que el sistema acabe en un estado que nadie sepa explicar. Los cambios en caliente convergen al mismo estado que una instalación limpia, y ninguna operación se queda colgada a medias.
El paper formaliza el andamiaje de composición, pero no la inteligencia de cada agente ni la corrección de cada plugin. Puedes cambiar las capacidades de un agente mientras corre, con una semántica definida sobre cómo entran, de qué dependen, qué deshacen al salir y en qué estado convergen. Ese es el punto más interesante de Cordis.
Si quieres el recorrido completo, desde el arranque de DeepSeek Harness hasta la formalización matemática, nuestro microsite dedicado lo desarrolla en 24 secciones.
