Limitaciones y estado de Koinessa: la franqueza como evidencia

2026-08-30 · Ingeniería ·

Ya viste la demo. El agente lee el repositorio, escribe la funcionalidad, corrige el fallo de su propia prueba, y quien presenta declara el futuro de la entrega de software. Tu pregunta — aprendida a las malas — es si el sistema sobrevive al contacto con las restricciones reales de producción: operadores concurrentes, estado corrupto, un auditor que pide pruebas. El temor de fondo es específico: el sistema funciona en una demo pero no puede sobrevivir al uso real en producción. La mayoría de los proveedores responden con más funcionalidades. Esta publicación responde con la sección de limitaciones del libro blanco de Koinessa, porque la forma en que un sistema reporta sus propias debilidades es la evidencia más determinante sobre cómo se comportará cuando algo realmente se rompa.

Lo que el libro blanco dice primero sobre sí mismo

La sección 10 del libro blanco de Koinessa abre con una frase que la mayoría del marketing de ingeniería nunca publicaría: Koinessa está en prelanzamiento y operado por su fundador, no ha sido auditado de forma independiente, y ninguna afirmación del libro blanco debe leerse como certificación o cumplimiento normativo. Eso no es cautela retórica. Es una declaración de clasificación, que separa cuatro cosas que los compradores suelen fusionar en una sola:

Un proveedor que dice «seguimos NIST» solo te ha hablado del primer elemento. La orientación sin un control es una aspiración, un control sin evidencia es una afirmación, y la evidencia sin certificación sigue siendo autoinforme — un autoinforme honesto, pero autoinforme al fin.

Los dos documentos del NIST detrás de esa distinción

El libro blanco fundamenta esta separación en dos publicaciones del NIST que vale la pena entender por sí mismas.

El primero es el NIST AI Risk Management Framework (AI RMF 1.0), junto con su Generative AI Profile, NIST AI 600-1. El AI RMF, publicado en enero de 2023, es un marco voluntario para gestionar el riesgo de la IA para individuos, organizaciones y la sociedad; el Generative AI Profile lo siguió en julio de 2024 con riesgos específicos de la IA generativa y acciones propuestas. La palabra clave es voluntario — el propio NIST describe el marco como orientación, no como un estándar de aprobado o reprobado. Un sistema de entrega de IA que dice que «se alinea con el AI RMF» te está diciendo que leyó el mapa. Nada en el marco certifica a nadie.

El segundo es el NIST SP 800-218, el Secure Software Development Framework (SSDF) v1.1, publicado en febrero de 2022, junto con el SP 800-218A, el Community Profile de IA generativa finalizado en 2024. El SSDF es un conjunto central de prácticas de desarrollo seguro de alto nivel, pensado para integrarse en el ciclo de vida de desarrollo de software que ya utilices; el 218A las extiende al desarrollo de modelos de IA bajo la Executive Order 14110. De nuevo: prácticas y tareas, no una auditoría. El SSDF te da el vocabulario para preguntarle a un proveedor «cuáles de estas prácticas están realmente implementadas, y muéstrame el registro» — la pregunta que la capa de evidencia de Koinessa responde con evidence-gated agentic development en lugar de con atestación.

Entonces, cuando el libro blanco dice «los marcos son orientación, un control es comportamiento implementado, la evidencia demuestra que el comportamiento ocurrió», está aplicando el propio alcance del NIST: estos documentos definen cómo se ve lo correcto; solo el sistema en ejecución puede demostrar que sucede.

Las limitaciones medidas, según la instantánea

Esto es lo que el libro blanco realmente concede, con sus matices intactos. Cada número mutable a continuación es una instantánea fijada al 2026-08-23 y cambiará con el tiempo; el registro de afirmaciones, no la prosa, es la fuente de verdad.

La capa multiproveedor está construida pero no habilitada

La capa de proveedores de sesión gestionada existe en el código pero está deliberadamente apagada: seis descriptores de proveedor registrados, cero habilitados, y el árbitro que enrutaría entre ellos no tiene quién lo invoque. Los recibos de coordinación multiproveedor que el libro blanco presenta en otras partes provienen de sesiones interactivas, no de la capa gestionada funcionando sin supervisión. Un sexto proveedor registrado permanece deshabilitado a la espera de simulacros en el momento de habilitación, y su salvaguarda de rechazo está limitada al carril de CLI de un único árbol de trabajo; una sesión en la nube de ese proveedor sobre su propio clon de un repositorio queda fuera de esa salvaguarda.

Los registros del lado del Cerebro tenían cero filas

Los registros de evidencia y conformidad del lado del Cerebro — paquetes, suficiencia, evidencia de resultados, delegaciones, ejecuciones de conformidad y digests de transcripciones — tenían cero filas en la instantánea. El camino operativo actual son los manifiestos y la firma del lado de CI. La compactación de transcripciones está integrada de forma desigual entre proveedores. El libro blanco imprime el cero en lugar de redondearlo hacia un elemento de la hoja de ruta.

Todavía no hay un pipeline verde de extremo a extremo

Al 2026-08-23, ningún pipeline de CI completo de la rama principal se había completado en verde de extremo a extremo. Los trabajos de verificación se ejecutan localmente y por trabajo — cada control sigue produciendo su propia prueba binaria — pero el primer pipeline verde de la rama principal está en curso, no logrado todavía. Para un sistema cuya propuesta de valor es el pipeline verde verificado, imprimir esto es precisamente el punto: el estándar se aplica al sistema que lo hace cumplir.

Escritor único por diseño, y lo que eso cuesta

El Cerebro es de escritor único por diseño; la operación multiescritor no está resuelta aquí. Dos operadores comparten un único escritor a través del gateway — no cada uno mantiene su propia conexión de escritura. La profundidad de verificación también es desigual entre lenguajes, y el modelo de producción de dos ramas significa que la línea de Desktop va por detrás del centro de mando del operador en capacidades medidas en una fecha dada, y la brecha se indica por capacidad y nunca se asume cerrada.

Autopilot se mantiene fail-closed

Autopilot se mantiene fail-closed por norma: cuando la verificación no puede demostrar el trabajo, la automatización se detiene en lugar de degradarse con gracia hacia la esperanza. Este es el modelo de autonomía por niveles de riesgo aplicado al propio funcionamiento del sistema — la automatización con puerta humana no es una fase que el sistema planee superar con el tiempo.

Sin multiplicador, y la aritmética honesta

No se afirma ningún multiplicador de rendimiento de tarea completa. El 85.6% de participación de tokens del lado de entrada que cita el libro blanco es una derivación a partir de un ejemplo de trabajo publicado, no una estadística impresa por un proveedor, y las lecturas de caché por sí solas representan alrededor del 51% en ese ejemplo (la aritmética completa está en la publicación sobre la economía del contexto). El camino declarado hacia cifras de productividad reales son los autobenchmarks preregistrados de EGD-001; hasta que esos existan, el libro blanco no inventará un multiplicador.

Las dos corrupciones y el supervisor de restauración

Esta es la parte de la sección que se lee como un informe de incidente, porque lo es. Dos corrupciones del archivo principal del Cerebro ocurrieron en la semana previa a la novena edición. Para un producto cuya premisa es la memoria compartida persistente, un archivo principal corrupto es el peor escenario posible — que el almacén de registro de cada resultado verificado se eche a perder.

La respuesta es la evidencia. La restauración automática desde instantánea se ha ejecutado en el proceso del gateway desde el 2026-08-24. Su supervisor es ahora un servicio nativo que permanece detenido ante el código de salida de rechazo de arranque, por diseño — se niega a arrancar hacia un estado degradado que parezca saludable. La legibilidad en modo degradado es un borrador, no una función publicada. Fail-closed no es una propiedad reservada solo para los agentes; es el mismo estándar aplicado al propio sustrato de memoria.

Un sistema de demostración nunca tiene esta sección, porque los sistemas de demostración nunca se someten a suficiente exigencia como para corromper nada. Dos corrupciones en una semana es el aspecto que tiene, visto desde dentro, poner a prueba si algo «sobrevive al uso real en producción» — el fallo ocurrió, la detección funcionó, la ruta de restauración es automática, y el registro de los tres hechos está en el libro blanco.

El libro blanco se mide a sí mismo midiendo

La limitación más sutil es recursiva. La propia publicación del libro blanco escribe en el sistema que mide — sus filas de revisión, hechos, reclamos de archivo y commit aterrizan todos en el Cerebro y en el historial de git. Por lo tanto, cada contador mutable es un instante de instantánea que necesariamente precede a la publicación que lo modifica. La disciplina consiste en fijar el instante (2026-08-23), declarar qué recuentos cambian, y nombrar el registro de afirmaciones como la fuente de verdad viva.

La misma disciplina se aplica a la evidencia externa. Las 22 filas de estadísticas externas permanecen en disputa para su reutilización automatizada u operativa; ninguna ha sido promovida a live. Las cifras que son telemetría de proveedor, están en disputa, o son metodológicamente débiles — la afirmación «el 95% de los pilotos de IA fracasan» es el ejemplo nombrado — se omiten o se matizan en lugar de citarse por efecto. Y la puerta de promoción es humana: un agente puede asistir en la investigación pero no puede promover una afirmación. La recuperación antes que la repetición también aplica a las estadísticas.

Por qué publicar esto es la estrategia

La franqueza aquí no es una postura de marketing; es la disciplina de evidencia demostrada sobre el sujeto más difícil disponible — el propio sistema. Un proveedor que publica registros con cero filas, un pipeline de la rama principal que todavía no está en verde, dos corrupciones y un carril de proveedor deshabilitado te está diciendo algo que ninguna lista de funciones puede decirte: la instrumentación es lo bastante real como para producir cifras poco favorecedoras, y la cultura las reporta en lugar de blanquearlas. Ese es el comportamiento que quieres que el sistema exhiba la primera vez que falle en tu entorno. La confianza construida a partir de recibos verificados — incluso los adversos — se acumula; la confianza construida a partir de afirmaciones pulidas se evapora en el primer incidente.

La conclusión

«El sistema funciona en una demo pero no puede sobrevivir al uso real en producción» se responde no prometiendo robustez, sino publicando la lista de costuras: prelanzamiento, operado por su fundador, sin auditar, de escritor único, con profundidad de lenguaje desigual, capa multiproveedor no habilitada, registros vacíos, todavía sin pipeline verde de extremo a extremo, sin multiplicador, dos corrupciones y el supervisor de restauración que las resolvió — cada afirmación fijada a la instantánea del 2026-08-23 con sus matices. El argumento completo, con la tabla de recibos operativos y la lista de referencias, está en el libro blanco de Koinessa; lo que está construido, en curso y planeado se rastrea en la publicación de la hoja de ruta. Juzga al sistema de la manera en que el libro blanco pide ser juzgado: no por lo que dice que hará, sino por la evidencia de lo que ha hecho — incluidos los fallos.