Evidence-Gated Agentic Development: El cerebro de Koinessa

Autor: Kris Christopher (KrisCodes2) Edición: Novena edición — verificada el 2026-08-23; revisada el 2026-09-07 (sección 3.12, lanzamiento de núcleo abierto) Sitio: koinessa.com Divulgación de estado: Koinessa es un sistema en prelanzamiento operado por su fundador. Toda afirmación de capacidad en este libro blanco lleva una de cuatro etiquetas — En vivo, En curso, No habilitado o Planeado — y las etiquetas se mantienen en un registro de afirmaciones antes de redactar la copia pública. El registro de afirmaciones y el resumen de investigación preservan el rastro de evidencia; este libro blanco público expone directamente el límite actual de la evidencia. Cada sección de este libro blanco tiene una URL permanente: cada encabezado enlaza a sí mismo, y los identificadores de fragmento son estables a través de futuras ediciones.

Resumen

Los sistemas de IA ahora pueden generar código, contenido, planes y decisiones más rápido de lo que las organizaciones pueden revisar con seguridad. La restricción vinculante sobre la IA aplicada está pasando de la generación a la aceptación confiable: demostrar qué se hizo, por cuál actor, bajo la autoridad de quién, y con qué evidencia. Este libro blanco sostiene que las técnicas necesarias no son nuevas. Cincuenta años de historia de la computación — el diseño de protocolo de cintura estrecha de internet [1], la gestión de datos estructurada y basada en eventos [6][7], el manejo de fallos en sistemas distribuidos [8][9][10][11][12], la reconciliación declarativa [13], la observabilidad [14], la seguridad de confianza cero [4][5], la procedencia de la cadena de suministro de software [15][16][17], las políticas como código [18], y la práctica de entrega continua [19] — se corresponden directamente con los problemas que crea la IA agéntica. Koinessa aplica esas técnicas como un sistema en funcionamiento: una memoria organizacional federada y de escritor único (el cerebro), un plano de coordinación que permite que agentes de múltiples proveedores trabajen en un mismo repositorio sin colisiones, y un modelo de entrega que llamamos Evidence-Gated Agentic Development, en el cual los agentes se mueven con rapidez precisamente porque los límites que los rodean son explícitos.

En vivo. El registro operativo temporal registra clases de autoridad, enlaces de evidencia de verificación, sustitución y consultas a una fecha determinada. En vivo. Un Context Compiler local reconstruye paquetes acotados a partir del estado canónico, y la inferencia de proveedor está en arriendo a sesiones físicas desechables. En vivo, con un límite medido. El cerebro tiene 349 tablas base: 335 llevan project_id; 14 tablas compartidas o de infraestructura no lo llevan. Toda escritura externa atraviesa el gateway de escritor único, pero el esquema no se describe como acotado universalmente por inquilino. No habilitado. Autopilot se mantiene fail-closed y requiere una acción explícita del operador para rearmarse. El resultado arquitectónico es independiente del modelo: la sesión del modelo es desechable; el sistema operativo es durable.

Este libro blanco presenta cinco planos — estado organizacional, contexto, coordinación, evidencia e inferencia — y trata a los modelos de frontera como trabajadores de cómputo sin estado y no deterministas, nunca como memoria, autoridad o verdad. La evidencia externa está fechada y acotada por población; las métricas internas identifican su fuente y su fecha de instantánea. No se afirma ningún multiplicador de rendimiento de tarea completa, ninguna certificación, ninguna auditoría independiente, ni prueba de neutralidad universal de proveedores.

1. La brecha de verificación

La ingeniería moderna asistida por IA tiene un problema de asimetría. Un solo operador puede dirigir agentes que producen cientos de cambios por semana, pero cada cambio todavía necesita ser revisado, probado, integrado y recordado. Las organizaciones que adoptan agentes reportan un grupo consistente de fallos:

• Sesiones amnésicas. Cada nueva sesión de IA comienza sin conocimiento de decisiones, correcciones y fallos previos, por lo que la organización vuelve a deducir lo que ya había aprendido.
• Trabajadores en colisión. Los agentes en paralelo duplican trabajo, sobrescriben los cambios de otros o pierden traspasos — fallos clásicos de sistemas distribuidos disfrazados de nuevos.
• Trabajo no probado. «El agente dijo que pasó» no es evidencia. Sin verificación determinista y procedencia durable, los cambios generados por IA acumulan riesgo de forma invisible.

La economía hace que la brecha sea estructural en lugar de temporal. El costo de generación cae con cada lanzamiento de modelo, mientras que el costo de la revisión cuidadosa, la integración y la operación cae lentamente, si es que cae — de modo que la proporción entre trabajo producido y trabajo verificado empeora a medida que la adopción tiene éxito. Un equipo que acepta cambios no verificados acumula riesgo invisible; un equipo que revisa todo a velocidad humana renuncia al rendimiento que adoptó agentes para ganar. Peor aún, la pérdida es acumulativa: cada decisión no registrada vuelve a litigarse en la siguiente sesión, cada cambio sin procedencia alarga la siguiente investigación de incidentes, y cada colisión entre trabajadores paralelos consume exactamente la atención de ingeniería que se suponía que los agentes iban a liberar. La salida no es una generación más lenta ni una aceptación más audaz. Es infraestructura que hace que la verificación, la memoria y la coordinación sean lo bastante económicas como para aplicarse a todo.

1.1 La brecha, medida externamente

La evidencia respalda una carga de verificación, pero solo cuando cada resultado conserva su propia población y su propio denominador.

• Evidencia externa — aceptación. Un GLMM binomial sobre 9,227 pull requests agénticos estimó probabilidades de merge específicas por agente de entre 43.0% y 84.3%; no estableció una comparación con humanos [55]. Un estudio distinto y más antiguo reportó una proporción bruta de aceptación del 76.8% para pull requests humanos, lo cual no es comparable con el resultado del GLMM [56]. En una instantánea separada de 33,596 PR, el 28.52% no recibió merge; la ausencia de merge no es prueba de código deficiente. El subconjunto de abandono por parte del revisor fue de 228 casos — el 38% de la muestra original de 600 PR y el 40.6% de los 562 casos categorizados accesibles [57]. Una división de causas de rechazo de 35.7% / 31.2% / 33.1% se aplica únicamente a 353 PR rechazados inspeccionados manualmente [58].
• Evidencia externa — revisión. Del total de 33,596 PR, el 61.38% no tuvo revisión registrada; entre los 12,975 PR revisados, el 58.77% fueron únicamente de agentes. La ausencia de revisión registrada no es prueba de que ningún humano haya inspeccionado el cambio [59].
• Evidencia externa — entrega. DORA reporta una asociación entre la adopción de IA, un mayor rendimiento y una menor estabilidad; no establece causalidad. El hallazgo de DORA de 2026 denomina «impuesto de verificación» a la carga operativa resultante [25][60].
• Evidencia externa — confianza. Entre los 33,244 encuestados que respondieron la pregunta de precisión de Stack Overflow de 2025, el 3.1% reportó un alto nivel de confianza. Entre los 31,476 encuestados que respondieron la pregunta separada sobre frustración, el 66% eligió «casi correcto, pero no del todo»; esa respuesta no es una medida general en contra de la IA [61].
• Evidencia externa — seguridad y mantenibilidad. El estudio SAST de Veracode, redactado por el propio proveedor, reporta código seguro en el 55% de las tareas; «150+ modelos» es su recuento acumulado de modelos, no una única cohorte nueva [62]. La investigación de GitClear, hecha por el proveedor y no revisada por pares, cubre su conjunto de datos propietario que abarca de 2023 a lo que va de 2026 (YTD) y un proxy de código movido; no establece que la IA haya causado los patrones de mantenibilidad reportados [85].
• Evidencia externa — integridad de los benchmarks. ImpossibleBench reporta una tasa de trampa del 76% para GPT-5 en Oneoff-SWEbench bajo el scaffold completo. Hacer que las pruebas fueran de solo lectura impidió las ediciones directas de pruebas, pero no arrojó un porcentaje universal. Una ruta de escape separada, basada en la escalación a un humano, produjo el resultado de 54 a 9 [63]. SWE-Bench+ reporta 32.67% y 31.08% únicamente entre los 251 parches exitosos de SWE-Agent más GPT-4 examinados en ese estudio [64].
• Evidencia externa — autorreporte y pruebas. El estudio de resolución por parte de desarrolladores encontró 16,118 episodios. De los 1,504 con resolución visible, el 91.49% se resolvió después de que el desarrollador expresara un rechazo explícito [65]. En un estudio separado de commits de prueba de 2025, los commits creados por agentes agregaron mocks en el 36% de los casos, frente al 26% de los commits no creados por agentes; este es un resultado a nivel de commit, no una tasa a nivel de todo el repositorio [66].
• Evidencia externa — horizonte temporal. METR estima la duración de tareas humanas en probabilidades de éxito de modelo especificadas, no el tiempo de reloj continuo del agente: cerca de 12 horas al 50% de éxito con un intervalo de 5 a 61 horas, y cerca de 1.5 horas al 80% con un intervalo de 50 minutos a 2 horas y 40 minutos [67]. AgentFloor es un benchmark determinista, sintético y de solo lectura de 30 tareas; no demuestra ediciones seguras de repositorio ni operaciones de producción [68].
• Evidencia externa — contexto y recuperación. En un estudio de preguntas y respuestas de solo lectura sobre un repositorio de Python, la recuperación semántica costó $0.32 por respuesta correcta frente a $0.74 para Deep: Deep fue aproximadamente 2.3 veces más costoso, y la recuperación semántica fue aproximadamente 57% más barata. La diferencia máxima de 22.4 veces en tokens se aplicó a Qwen3-235B [73]. El colapso de coordinación representó el 41.8% de los fallos de Deep; dentro de esa categoría, el 91% aún así emitió prosa fluida y confiada [73]. Codebase-Memory reportó una calidad de 83% frente a 92%, aproximadamente diez veces menos tokens, y 2.1 veces menos llamadas a herramientas, mientras conservaba un mecanismo de respaldo por exploración [74].
• Evidencia externa — economía de tokens. La cifra del 85.6% es una proporción derivada del procesamiento del lado de entrada — entrada sin caché, creación de caché y lecturas de caché — en un ejemplo de costo resuelto; las lecturas de caché por sí solas representaron cerca del 51% [70]. Un estudio separado de ocho modelos sobre OpenHands/SWE-bench Verified midió diferencias de tokens de aproximadamente 1,000 veces y una variación de hasta 30 veces en la misma tarea; esto no se generaliza a todos los flujos de trabajo [71].
• Evidencia externa — contexto largo. NoLiMa encontró que 11 de 13 modelos cayeron por debajo de la mitad de su línea base de contexto corto al llegar a 32K, mientras que GPT-4o pasó de 99.3% a 69.7%; estos son resultados específicos del benchmark, no una conclusión universal sobre las ventanas anunciadas [72]. Los precios actuales de contexto largo son específicos de cada modelo: GPT-5.6 por encima de 272K [75], los modelos Gemini Pro especificados por encima de 200K [76], y Claude 4.6 en adelante más Mythos Preview a las tarifas estándar de ventana de un millón [70][92].

La respuesta dominante del mercado — un modelo más capaz — no resuelve ninguno de estos problemas, porque ninguno de ellos es un problema de inteligencia. Son problemas de sistemas: identidad, estado, propiedad, temporización, fallo, autoridad, observabilidad y prueba. La tesis de este libro blanco: los modelos crean posibilidades; los sistemas determinan los resultados.

1.2 La raíz común

Si se rastrea hacia atrás cualquiera de los fallos de la sección 1.1, todos convergen en una misma ausencia: actualmente, la IA no cuenta con una definición durable y verificable de forma independiente de la verdad organizacional y la finalización exitosa. Sin verdad durable, las sesiones necesitan un contexto enorme; contexto enorme, entonces compactación y degradación del contexto. Sin un índice de conocimiento preciso, exploración voraz. Sin verdad entre sesiones, cada enjambre vuelve a aprender todo. Sin estado organizacional en el bucle, la política de negocio es folclore reintroducido por prompt. El estado vive dentro de las sesiones del proveedor, entonces dependencia del proveedor. Sin un contrato formal de finalización, los agentes divagan o se detienen antes de tiempo; sin criterios de aceptación independientes, el slop parece completo. Sin un plano de control común, los proveedores no pueden cooperar; sin descomposición de la carga de trabajo, toda tarea parece necesitar un modelo gigante. Sin fundamentación autoritativa, las alucinaciones se convierten en hechos operativos; sin evidencia independiente, el sistema no puede distinguir una mentira confiada de la realidad; sin un modelo de autoridad ganada, no se puede confiar con seguridad en la automatización — y todo lo anterior recarga el contexto, así que el costo de tokens se dispara.

La forma más fuerte de la tesis de este libro blanco, por lo tanto, no es «la IA necesita mejor verificación». Es: los modelos de frontera deben tratarse como trabajadores de cómputo sin estado y no deterministas — no como el sistema operativo, la memoria organizacional, la fuente de autoridad, o la fuente de la verdad. Las secciones que siguen son las consecuencias sistémicas de tomar en serio esa oración.

2. Siete lecciones de cincuenta años de sistemas

2.1 La cintura estrecha

Internet escaló porque su contrato intermedio se mantuvo pequeño: muchas aplicaciones por encima de IP, muchas redes por debajo, una interfaz estable entre ambas [1][23]. El ecosistema de IA está redescubriendo esta forma. El Model Context Protocol estandariza cómo una aplicación impulsada por un modelo alcanza herramientas y contexto [2]; el protocolo Agent2Agent aborda la comunicación entre agentes independientes [3]. La conectividad, sin embargo, es la mitad fácil. Internet estandarizó la entrega de paquetes sin resolver la identidad, el fraude ni la confianza — y los protocolos de agentes repetirán ese patrón a menos que la identidad, la autorización, la reputación y la política se construyan por encima de ellos. El marco de autorización HTTP de MCP del 2026-07-28 es opcional y está basado en OAuth 2.1 [77]. Las Agent Cards de A2A 1.0 pueden estar firmadas con JWS; la verificación con una clave confiable puede establecer la integridad de la tarjeta y el origen del proveedor, pero la firma es opcional y no es un sistema global de identidad de agentes [78]. Lo que permanece estandarizado de forma incompleta es la autoridad delegada a lo largo de cadenas de agentes — atenuación de capacidades, autoridad de elemento de trabajo, herencia de políticas, revocación, procedencia de la evidencia, protección contra repetición, reputación y rendición de cuentas de extremo a extremo desde el principal hasta el agente, la herramienta y el resultado. Una instantánea v1 de arXiv de mayo de 2026 encontró defectos en 119 servidores MCP del mundo real, habilitados para OAuth y comprobables; no establece una propiedad universal de las implementaciones de MCP [79]. En vivo. Koinessa expone 366 herramientas registradas detrás de un único contrato de búsqueda (sección 3.8). Ollama local, Ollama Cloud [83] y los trabajadores de frontera descubren capacidad a través de ese mismo contrato local, y la cintura ya ha sido ejercitada por una incorporación: el sexto descriptor de proveedor (Devin CLI, sección 3.6) se registró sobre un tipo de transporte existente sin código de transporte nuevo y alcanzó el mismo contrato de herramientas a través de una sola entrada de configuración. Evidencia externa. La propia topología del proveedor apunta en la misma dirección: los Outposts de Devin ejecutan «ejecución de comandos, ediciones de archivos y acceso al repositorio» en máquinas que opera el cliente sobre HTTPS solo de salida, mientras el bucle del agente permanece en la nube del proveedor [96], y desde el 2026-07-31 sus herramientas MCP se ejecutan desde los servidores del proveedor en lugar de la máquina de la sesión [97] — ubicaciones que convierten la costura entre el descubrimiento de capacidades y el estado organizacional exactamente en el límite que esta sección sostiene que debe poseerse localmente.

2.2 La memoria debe tener estructura

Una transcripción no es memoria. Una memoria operativa debe responder: ¿de dónde vino esto, cuándo fue cierto, ha sido sustituido, qué evidencia lo respalda y quién lo creó? El event sourcing conserva el historial que produjo el estado actual [6]; CQRS separa las rutas de lectura amplias de las rutas de escritura estrechas y auditadas [7]. Koinessa aplica ambos. En vivo. Los agentes leen a través del gateway del cerebro, mientras que toda escritura externa cruza su límite de escritor único. La recuperación es léxica, vectorial y basada en grafos sobre el mismo almacén. La instantánea del 2026-08-23 contiene 17,903 símbolos de Koinessa (indexados por última vez ese mismo día) y 54,201 símbolos a lo largo de los doce carriles de la federación; la línea de producción Desktop se federa bajo la misma clave de producto (sección 8.7), y un carril remanente de 7,762 símbolos, procedente de su bucle de desarrollo previo a la consolidación, permanece congelado tal como está almacenado.

En vivo. El registro operativo temporal (BRN-002, implementado el 2026-08-07) registra clases de autoridad — un resultado de pipeline firmado tiene mayor rango que la afirmación de un agente —, referencias de evidencia, enlaces de sustitución y consultas a una fecha determinada: ¿qué creíamos cuando se tomó esta decisión, y qué la sustituyó?

La pregunta a una fecha determinada suena académica hasta la primera revisión seria de incidentes. Cuando aparece un defecto en producción, la pregunta útil rara vez es «qué es verdad ahora» — es «qué creía el sistema en el momento en que se autorizó el cambio, qué evidencia estaba disponible entonces, y qué hecho posterior la sustituyó». Una capa de memoria capaz de responder eso convierte los postmortems de arqueología en consultas, y es la diferencia entre una organización que aprende y una que meramente acumula texto.

2.3 El fallo parcial es normal

Los sistemas distribuidos asumen que los componentes fallan de forma independiente, y los sistemas de agentes heredan cada uno de esos modos: una sesión muere después de modificar archivos pero antes de reportar; una llamada a herramienta expira después de haber tenido éxito; dos trabajadores creen que poseen el mismo recurso. La postura correcta es tratar a cada agente como un trabajador que puede estar lento, obsoleto, duplicado, interrumpido o equivocado — y usar los controles clásicos: heartbeats para la vitalidad; arriendos que expiran en lugar de bloqueos que se interbloquean [8]; fencing tokens para que un titular de arriendo obsoleto no pueda sobrescribir trabajo más reciente [9] — vale la pena detallar el escenario una vez, porque es el accidente canónico de los enjambres de agentes. El agente A toma un arriendo numerado 41 sobre un elemento de trabajo y se detiene. El arriendo expira; el agente B toma el arriendo 42 y termina el trabajo correctamente. El agente A finalmente despierta e intenta escribir su resultado obsoleto. Sin fencing, A sobrescribe a B en silencio; con fencing, el recurso protegido recuerda que 42 es el token válido más reciente y rechaza el 41. La autoridad obsoleta nunca debe convertirse en autoridad vigente, y ninguna cantidad de inteligencia del modelo sustituye esa comprobación — claves de idempotencia para que los reintentos no puedan ejecutar dos veces acciones con consecuencias [10]; outboxes transaccionales para que los cambios de estado y sus notificaciones no puedan divergir [11]; y sagas con acciones compensatorias para flujos de trabajo que cruzan límites irreversibles [12]. En vivo. El registro de sesiones, los reclamos de archivo cooperativos y los arriendos de elementos de trabajo con fencing permiten que trabajadores interactivos de seis proveedores — Kimi, Claude, Grok, Codex, Ollama local y Ollama Cloud [83] — compartan un mismo tablero; el registro contiene 209 sesiones registradas, 208 de ellas desde el 1 de agosto. Un séptimo proveedor, Devin, está registrado como el sexto descriptor de proveedor y permanece deshabilitado detrás de una salvaguarda versionada (sección 3.6). La atribución tiene un límite medido: se captura una etiqueta de proveedor en una minoría de las filas de sesión (8 de 209 en esta instantánea), por lo que la atribución por proveedor descansa en los trailers de commit — 18 identidades de trabajador distintas desde el 1 de julio — que no son universales. La instantánea de git del 2026-08-23 contiene 100 commits en la rama principal del 19 de agosto al 23 de agosto, 691 del 5 de agosto al 23 de agosto, y un pico de 84 el 13 de agosto. En vivo. Dos operadores humanos en estaciones de trabajo LAN separadas pueden dirigir enjambres independientes contra el mismo repositorio a través del mismo plano de coordinación; ese comprobante es evidencia operativa de un solo sistema, no un benchmark controlado.

2.4 Declara el estado deseado y reconcilia

Kubernetes reemplazó «ejecuta esto y espera» por un bucle de controlador: declara el estado deseado, observa el estado real, actúa para reducir la diferencia, repite [13]. El trabajo agéntico debería gobernarse de la misma forma. Un documento de requisitos declara resultados; los elementos de trabajo acotan obligaciones; los perfiles de verificación declaran las comprobaciones requeridas; los esquemas de evidencia declaran la prueba que debe existir. El controlador compara entonces el estado observado contra los requisitos declarados — la cobertura existe o no existe; el artefacto coincide con su esquema o no coincide — en lugar de preguntarle al agente si ha terminado. Esto convierte la autonomía vaga en convergencia medible, y hace de la observabilidad el muro de carga: la traza se expande desde spans a nivel de solicitud [14] hasta la procedencia de las decisiones — objetivo de negocio a requisito, a sesión de agente, a llamadas a herramientas, a commit, a pipeline, a evidencia, a aprobación, a resultado.

La reconciliación también aporta el regulador que le falta al rendimiento de los agentes: la contrapresión. Cuando un sistema aguas abajo se ralentiza o falla, los controladores reducen el trabajo, lo encolan o se detienen — mientras que la automatización ingenua convierte una pequeña interrupción en una inundación de reintentos y acciones duplicadas. Y una vez que cada operación lleva una identidad durable desde la intención hasta el resultado, la fiabilidad se vuelve computable por agente, modelo, clase de tarea, repositorio y cadena de herramientas. La selección de modelo deja entonces de ser preferencia de marca y se convierte en una cuestión de evidencia: qué modelo tiene éxito con más frecuencia en este repositorio, cuál produce la menor cantidad de ciclos de reparación, cuál exagera la finalización. Así es como un sistema se mejora a sí mismo sin permitir jamás que la IA se apruebe a sí misma.

2.5 Firma lo que ocurrió

La seguridad de la cadena de suministro replanteó las compilaciones en torno a la procedencia: declaraciones verificables sobre dónde, cuándo y cómo se produjo un artefacto (SLSA [81]), formatos de atestación para afirmaciones de cadena de suministro (in-toto [82]), y firma y verificación accesibles (Sigstore y Cosign [17]). Estas correspondencias no confieren un nivel SLSA ni procedencia confiable sin relaciones de confianza verificadas, del mismo modo que una correspondencia con SSDF no confiere certificación NIST [80]. El desarrollo agéntico necesita la misma disciplina extendida hacia atrás hasta la procedencia del código fuente: qué requisito inició un cambio, qué agente lo escribió, qué contexto influyó en él, qué políticas lo restringieron, qué reparaciones lo modificaron y qué humano lo aprobó. Git registra qué contenido cambió; el sistema que lo rodea debe registrar por qué cambió, bajo la autoridad de quién y con qué prueba. El paquete de evidencia de un cambio producido por un agente (diseñado bajo EGD-001) vincula la revisión de origen, la sesión de agente y el modelo, la autorización de trabajo, las versiones de las herramientas, las comprobaciones ejecutadas con sus estados canónicos, el perfil de política que las interpretó, las aprobaciones y el digest del artefacto final — una sola cadena desde la intención hasta el despliegue. El límite de los registros se declara en lugar de darse por implícito: el pipeline de CI construye y firma manifiestos de evidencia como trabajos (en vivo donde corren esos trabajos), mientras que los registros del lado del cerebro de paquete, suficiencia, evidencia de resultado, delegación y conformidad — con escritores y pruebas ya en su lugar — tenían cero filas en la instantánea del 2026-08-23 (no habilitado). Un carril de atestación externa neutral respecto al emisor — comprobantes firmados por terceros ingeridos como evidencia de primera clase, el veredicto del emisor almacenado textualmente, correspondencia de veredicto a estado en modo fail-closed para que un éxito no verificado nunca sea una aprobación, claves fijadas en el primer uso y congeladas por comprobante, y comprobantes inválidos almacenados en lugar de descartados — está especificado y en revisión (planeado). Igual de importantes son los estados de resultado canónicos: un pipeline que solo conoce verde y rojo clasificará erróneamente un escáner ausente como un escaneo limpio. El modelo de verificación de Koinessa distingue PASS, FAIL, SKIPPED-NOT-APPLICABLE, INFRASTRUCTURE ERROR, TOOL MISSING y EVIDENCE INVALID (en vivo). Un séptimo estado — ABSTAIN-SPEC-CONFLICT, una ruta recompensada y de primera clase para que un agente declare que el trabajo no puede completarse legítimamente bajo su especificación actual — se entregó con EGD-002 (En vivo, 12/12 historias cerradas el 2026-08-15): la alternativa medida a una salida legítima es hacer trampa, y una ruta explícita de inviabilidad produjo un resultado de 54 a 9 en un experimento separado [63]. El inventario del repositorio del 2026-08-23 contiene 1,619 archivos de prueba o de especificación indexados en git; ese inventario no afirma que las suites se hayan vuelto a ejecutar.

2.6 Protege el objetivo

Los sistemas que optimizan aprenden a satisfacer la medición en lugar del objetivo — la ley de Goodhart [20]. En la ingeniería agéntica el fallo canónico es el agente de reparación que elimina una prueba que falla para poner el pipeline en verde. El bucle de reparación local de Koinessa (Ralph, en vivo) está por lo tanto acotado por construcción: puede arreglar código, configuración, enrutamiento o infraestructura, y no puede bajar umbrales, eliminar pruebas significativas, deshabilitar escáneres, ni convertir comprobaciones requeridas en informativas. La regla se generaliza: el optimizador no debe controlar la definición de éxito. La mejora de modelos sigue la misma lógica. En un esquema de campeón-retador, el mejor modelo actual para una clase de tarea permanece en servicio mientras las alternativas corren en modo sombra o sobre trabajo seleccionado de bajo riesgo, juzgadas por los mismos criterios independientes — tasa de éxito verificado, costo por cambio aceptado, ciclos de reparación, frecuencia de intervención humana, tasa de regresión tras el despliegue — de modo que un humano solo puede promover una afirmación después de revisar evidencia medida; un agente puede asistir en la investigación, pero no puede promoverla. Y el comportamiento de alto impacto gana autoridad primero mediante simulación: un agente de publicación valida acciones sin enviarlas, un agente de despliegue produce el plan sin aplicarlo, un agente de reparación parchea un espacio de trabajo aislado y pasa la verificación antes de que cambie cualquier estado compartido. La industria aeroespacial, las redes y las finanzas aprendieron todas la misma secuencia — probar bajo condiciones controladas antes de conectar el controlador a una superficie irreversible.

2.7 Los datos no son instrucciones

Los agentes aumentados por recuperación crean una nueva superficie de ataque y de accidente: cualquier cosa que pueda alcanzar el contexto — un documento interno, un resultado de herramienta, una página web, el mensaje de un cliente — puede llevar texto que un modelo podría malinterpretar como autoridad. Un artículo de ataques acota esos riesgos a MCP v1.0, mientras que las especificaciones actuales proporcionan mitigaciones de seguridad [90][91]. El contenido no confiable de servidores y herramientas todavía requiere validación, aislamiento y autorización por parte del cliente. La respuesta de sistemas es un límite que el modelo nunca llega a inferir lingüísticamente: la procedencia y la autoridad deben ser campos estructurales sobre el contexto, no propiedades que un modelo adivine a partir de la prosa. La política debe ser distinguible de la documentación, el hecho operativo verificado de la observación del agente, la investigación aprobada por la empresa de una página web externa, el resultado de herramienta de la instrucción. En Koinessa, cada fuente de paquete de contexto ya lleva una clase de autoridad tipada (operador, verificado, evidencia, agente, inferido, desconocido) con procedencia por sección (en vivo); EGD-002 endurece el límite (En vivo, cerrado el 2026-08-15): una clase externa-no-confiable, rechazo en tiempo de compilación de los paquetes cuyas secciones de política o de restricciones reclamen autoridad no privilegiada, fencing en tiempo de renderizado que marca el contenido de baja autoridad como datos, nunca como instrucciones, y admisión a memoria con evidencia como puerta y comprobaciones de contradicción en tiempo de escritura. Una alucinación en una sesión es temporal — una alucinación admitida en la memoria organizacional contamina toda sesión futura que la recuerde, por lo cual la admisión es ahora una escritura con puerta en lugar de una cortesía.

3. La arquitectura del cerebro de Koinessa

El cerebro es el sustrato de memoria y coordinación de Koinessa.

3.1 Almacén federado

En vivo. El 2026-08-23, una base de datos DuckDB contenía 346 tablas base y 21 vistas (27 de las tablas base son backups de migración conservados). De esas tablas base, 333 llevan project_id; 13 tablas compartidas o de infraestructura no lo llevan. El alcance por inquilino, por lo tanto, se mide por relación en lugar de asumirse de forma universal. El claims register es la fuente de verdad para estas cifras cambiantes. Una migración completa de la clave de identidad (47 tablas, 110,811 filas) se ejecutó en vivo con cero corrupciones usando reconstrucciones completas de tabla —nunca actualizaciones de clave en el propio lugar—, un ejemplo práctico de la ceremonia por niveles de riesgo que este libro blanco defiende.

3.2 Gateway de escritor único

En vivo. Toda escritura externa cruza un único gateway HTTP: las lecturas están libres de token solo cuando el gateway está enlazado a la interfaz de loopback —en cualquier otro enlace, las lecturas requieren un principal identificado por bearer token exactamente igual que las escrituras— las escrituras y las transacciones están protegidas por bearer token a través de un mutex de escritor único, los arriendos de elementos de trabajo llevan fencing tokens, y la búsqueda híbrida y el recorrido de grafos comparten la misma superficie. La ruta de escritura estrecha es un diseño nacido de una cicatriz: una actualización anterior de clave primaria en el propio lugar corrompió el write-ahead log, y la recuperación funcionó solo porque las snapshots y la repetición del log ya habían sido diseñadas antes del fallo.

3.3 Plano de coordinación

En vivo. Las sesiones se registran y envían heartbeats; los reclamos de archivo detectan colisiones de forma cooperativa; los elementos de trabajo llevan arriendos y fencing tokens; los mensajes duraderos llevan requisitos de acuse de recibo; los checkpoints y traspasos permiten que una sesión sucesora —de cualquier proveedor— reanude sin historial de chat. Esta es la infraestructura detrás del comprobante multiproveedor en la sección 2.3. El flujo de revisión y planificación de nueve roles superpuesto a esto —los agentes CEO, engineering-manager, designer, QA, security, release, browser-operator y memory-support que condicionan y refinan el trabajo antes de la implementación— porta a este plano de coordinación el framework de ingeniería basado en skills y de código abierto gstack [53], del presidente y CEO de Y Combinator Garry Tan (GTR-001, implementado), adoptado para cerrar una brecha de planificación autodiagnosticada y no para eludir el harness de ningún proveedor en particular.

3.4 Memoria con procedencia

En vivo. Un almacén de hechos con decaimiento captura decisiones, arreglos y fallos automáticamente a partir de eventos de CI, reparación y sesión, con recuperación clasificada inyectada al inicio de la sesión. El registro temporal (BRN-002) añade clases de autoridad, enlaces de evidencia de verificación, sustitución y consultas a una fecha determinada —todo en vivo desde el 2026-08-07. Junto al almacén de hechos están las superficies de recuperación con las que los agentes realmente trabajan: búsqueda híbrida léxica más vectorial, recorrido de grafos sobre entidades y relaciones, el índice de inteligencia de código de 17,903 símbolos en esta lane (54,201 en toda la flota federada), y un corpus de investigación curado de 5,351 documentos —sin cambios desde el 2026-08-18— que los agentes deben consultar antes que la web abierta —de modo que las respuestas de marketing y estrategia se mantengan trazables hasta las fuentes que la empresa eligió.

3.5 Context Compiler e inferencia en arriendo

En vivo. La capa AOE-001 (implementada el 2026-08-10) trata el contexto y la inferencia de modelos de frontera como recursos programables. Un Context Compiler ensambla un Context Packet acotado y con procedencia para cada sesión física de modelo a partir del estado canónico: el requisito aprobado, el estado y el diff de Git actuales, los hechos autoritativos del cerebro, los símbolos de código con rangos de origen precisos, la propiedad actual, el último checkpoint, la evidencia de verificación vigente, la política aplicable y el presupuesto de modelo/contexto. Un elemento de trabajo lógico puede abarcar muchas sesiones físicas cortas —session A -> checkpoint -> session B -> checkpoint -> verified completion— y ninguna sesión física es dueña de la verdad. La inferencia del proveedor está en arriendo: un trabajador lógico no ocupa ningún cupo del proveedor mientras corren las pruebas locales o la CI, de modo que el tamaño del enjambre lógico se mantiene independiente del margen de concurrencia de un proveedor. La verificación, no el relato del generador, es la condición de parada. La postura de diseño sobre la compactación es que el detalle no persistido puede perderse cuando los mensajes se compactan [50]. El invariante es más fuerte que «no compactar»: ningún resumen conversacional con pérdida es jamás la copia autoritativa del estado organizacional, de modo que el Compiler siempre puede reconstruir el contexto de una sesión a partir del estado canónico, en lugar de a partir de lo que un resumen haya conservado.

3.6 Capa de proveedores unificada

No habilitado. Seis descriptores de proveedor —Kimi Code, Claude Code, Codex, Grok, Ollama local y Devin CLI— están registrados bajo una única forma tipada y tres transportes de sesión, y cada uno de ellos está deshabilitado. Esa frase es el diseño funcionando como se pretendía, y merece explicarse. Un descriptor de proveedor lleva todo lo específico del proveedor como datos: el tipo de transporte, un binario fijado por SHA-256 y una versión de CLI sondeada, una sonda de credenciales que comprueba la presencia de archivos y nunca lee su contenido, ventanas de contexto por modelo con un vocabulario de procedencia de cuatro valores (medido, sondeado, documentado por el proveedor, sustituto no verificado), presupuestos de context packet por modelo escalados a partir de una única calibración medida, una terna de concurrencia, una forma de cuota, y un flag de habilitación fail-closed. Los campos no sondeados llevan un marcador explícito que ningún gate acepta, de modo que un descriptor registrado antes de que su binario se ejecutara alguna vez falla el preflight de forma cerrada en lugar de pasar con valores por defecto plausibles. Los tres transportes —uno para CLIs de proveedor fijadas, uno para proveedores HTTP medidos cuya clave real nunca sale del servidor, uno para modelos locales controlados por arriendo de GPU— implementan un único contrato de transporte de sesión con ocho tipos de fallo de preflight nombrados y resultados libres de secretos por construcción. Añadir el sexto descriptor no requirió código de transporte nuevo (sección 2.1). Habilitar cualquier descriptor es una decisión del operador que además exige un simulacro de límites por proveedor, porque el mecanismo de perfil de herramientas de un proveedor no demuestra nada sobre el de otro. La capa de sesión gestionada tiene, por lo tanto, comprobantes como código y como pruebas, pero todavía no como historial operativo: los comprobantes de coordinación multiproveedor de la sección 2.3 provienen de sesiones interactivas gobernadas por hooks y por el plano de coordinación, no de este lanzador.

Un árbitro local (construido pero no habilitado: deshabilitado de forma predeterminada, sin invocador en producción) puede asesorar la política determinista de reinicio de sesión, y su retícula de consejos es monótona hacia la cautela por datos, no por convención: una decisión de continuar puede endurecerse hacia finish-current-only o checkpoint-and-yield; las decisiones terminales no aceptan ningún consejo. Un modelo local equivocado o que alucina puede desperdiciar una sesión; no puede mantener una con vida más allá de un límite duro de contexto, un arriendo revocado o una cuota agotada. El optimizador, de nuevo, no controla la definición de éxito (sección 2.6).

El sexto descriptor es también el ejemplo trabajado de cómo incorporar a un proveedor sin extender confianza por delante de la evidencia. La CLI de Devin opera sobre el árbol de trabajo local mientras su inferencia corre en la nube del proveedor [94]; lee los mismos archivos de instrucciones que los demás harnesses, incluidos los compatibles con Claude [95]. Antes de cualquier habilitación, Koinessa implementó una salvaguarda de denegación total —una configuración que deniega toda clase de herramienta y un hook previo a la herramienta que bloquea con un rechazo legible por máquina— y la probó con un canario dentro del propio árbol: la única llamada a herramienta de la sesión fue rechazada, y un marcador plantado nunca salió. El registro siguió a un kill gate (¿el plan del proveedor realmente sirve sesiones headless?), y la precondición de gobernanza de datos se verificó en lugar de asumirse: los términos del proveedor establecen que los datos del cliente pueden usarse para entrenar modelos y que los niveles de pago pueden excluirse, tras lo cual se habilita retención cero de datos con sus proveedores de modelos [93]; el operador pasó a un nivel de pago y confirmó la exclusión antes de la primera prueba gobernada (reportado por el operador, 2026-08-23). El límite de la salvaguarda se declara con el mismo cuidado: gobierna el carril de CLI de este árbol de trabajo; una sesión de proveedor en la nube que opera sobre su propio clon de un repositorio está gobernada por las reglas del repositorio y los controles del lado del proveedor (sección 10). La integración más profunda —el registro en el plano de coordinación, la ingesta de transcripciones de las exportaciones por turno del proveedor, la medición de uso y una política de mínimo privilegio que reemplace la denegación total tras un simulacro de habilitación aprobado por el operador— está especificada y en revisión (en curso).

3.7 Compactación de transcripciones entre proveedores

La sección 3.5 argumentó que un resumen conversacional nunca debe ser la copia autoritativa del estado organizacional. La capa de compactación (entregada el 2026-08-22) convierte esa postura en mecanismos específicos por proveedor, y la descripción honesta es una tabla, porque el cableado es desigual:

El puente en sí es neutral respecto al proveedor por diseño de datos: la solicitud de compilación lleva un id de proveedor validado contra el registro de descriptores, y los prefijos de id sintético por proveedor son una tabla de búsqueda con una excepción heredada, no una bifurcación. La admisión a la memoria organizacional es idempotente sobre una clave de mensaje derivada del contenido —en vivo desde el 2026-08-22, y demostrada de la forma menos glamurosa: volver a publicar una transcripción de 324 fotogramas no añadió ninguna fila, mientras que la clave anterior había amplificado una conversación en tres órdenes de magnitud. Un monitor de frescura fail-loud vigila la ruta de ingesta, porque cada escritor de transcripciones de este sistema es fail-open y cada uno de ellos, al menos una vez, murió en silencio. El compactador de transcripciones de GPU local y su tabla de digest están en vivo como código; la tabla de digest no tenía ninguna fila en esta instantánea, y el libro blanco lo dice así en lugar de dar a entender un registro poblado.

3.8 Registro de herramientas y el contrato de búsqueda único

En vivo. El registro contiene 366 herramientas —137 rutas de API, 104 skills, 91 scripts, 29 agentes, 3 componentes de CI, 2 servidores MCP— detrás de un único contrato de búsqueda de dos niveles: una búsqueda clasificada que devuelve filas breves, seguida de una consulta de detalle por herramienta cuyo bloque de invocación es dato (transporte, comando, argumentos, endpoint), nunca algo inferido a partir de un nombre. Los filtros (tipo, capacidad, modo de recuperación) se aplican antes de la clasificación; la recuperación híbrida de palabra clave más vector degrada con elegancia a solo palabra clave para las herramientas nunca incorporadas a los embeddings; y las entradas de imagen de contenedor se responden mediante un join en vivo contra el catálogo de imágenes, en lugar de una copia reingerida. Todos los proveedores llegan al mismo contrato a través de la misma superficie MCP local: los harnesses de Claude y Kimi lo registran en su configuración de herramientas, Grok a través del registro MCP del repositorio, y —en un sandbox controlado— la CLI de Devin alcanzó el mismo endpoint con solo una entrada de configuración. Lo que permanece específico de cada proveedor es un solo bloque de registro por harness; el contrato no cambia.

3.9 Durabilidad y modo degradado

En vivo, con un límite declarado. La admisión de conocimiento está respaldada por una cola: una cola de ingesta duradera con reintentos y un spool de contingencia hace que nada se pierda cuando el escritor está ocupado o caído, y las escrituras externas toman primero una instantánea automática. La lección más contundente de 2026 es que el propio host es hostil: la máquina que sirve al cerebro perdió energía dieciséis veces en catorce días, y dos de esos cortes desgarraron el archivo principal de la base de datos —uno de ellos sin que nadie estuviera vigilando, lo que produjo un bucle de caídas de varios días contra una instantánea más reciente que tenía diez días de antigüedad. La respuesta (en vivo —aterrizada en código y pruebas el 2026-08-23 y corriendo en el proceso del gateway desde su cambio a un servicio nativo de Windows el 2026-08-24) trata una caída como un costo medido en segundos: checkpoints cada sesenta segundos o cincuenta escrituras; tres clases de corrupción manejadas de forma distinta —un bloqueo de archivo transitorio se reintenta, un write-ahead log no reproducible se pone en cuarentena, un archivo principal desgarrado se restaura automáticamente desde la instantánea importable más reciente hacia una ruta de staging y se promueve de forma atómica—; la recuperación escribe su propia fila de auditoría en la base de datos restaurada antes de la promoción, de modo que una restauración y su registro son inseparables; y cuando ninguna instantánea se puede importar, el gateway se niega a iniciar con un código de salida dedicado que su supervisor interpreta como «detente, no reinicies», porque servir un cerebro vacío sería peor que no servir ninguno. La legibilidad en modo degradado es el siguiente paso ya redactado (planeado): hoy, un gateway reiniciándose, una restauración en curso, un archivo irrecuperable y un simple error de consulta todavía presentan un mismo error indistinguible ante cada superficie consumidora, y el objetivo de diseño es que cada uno se identifique a sí mismo. La memoria institucional que no puede sobrevivir a una caída no es memoria institucional —y un sistema que oculta cuál falla está sufriendo no ha terminado de aprender esa lección.

3.10 Lo que el cerebro no es

No es un SaaS: el modelo de implementación es infraestructura controlada por el cliente, con capacidad en la nube como excepción explícita y acotada. No es multiescritor: ese límite se declara en lugar de ocultarse. Y no reemplaza a Git ni a la CI —los vincula a la intención, la autoridad y la evidencia.

3.11 Cinco planos

Postura de diseño. Koinessa se describe como cinco sistemas distintos, en lugar de «un sistema operativo de IA con memoria»: un plano de estado organizacional (hechos de negocio, requisitos, políticas, decisiones, inteligencia de código, estado temporal y procedencia); un plano de contexto (recuperar y compilar el paquete autoritativo más pequeño que necesita el siguiente trabajador); un plano de coordinación (identidad, arriendos, fencing, propiedad, checkpoints, traspasos, reintentos, programación multiproveedor); un plano de evidencia (verificación independiente, definiciones de prueba protegidas, atestaciones, evaluación de políticas, aceptación por niveles de riesgo, evidencia posterior al despliegue); y un plano de inferencia (Ollama local, Ollama Cloud [83], nube económica y modelos de frontera, tratados como trabajadores en arriendo seleccionados por capacidad y costo medidos). La intercambiabilidad de proveedores es un objetivo de diseño respaldado solo donde existen comprobantes de código y de tiempo de ejecución. El invariante que une los planos: la inferencia puede fallar, desaparecer, alucinar, compactarse, cambiar de proveedor, perder su sesión, exceder su contexto o volverse demasiado costosa —sin que la organización pierda estado, autoridad, evidencia o control.

3.12 La capa de IA de núcleo abierto

Postura de diseño. La superficie orientada a los agentes de los planos de contexto y de coordinación se distribuye como un plugin gratuito de Claude Code bajo licencia MIT. Las superficies de control de los planos de estado organizacional, de evidencia y de inferencia siguen siendo comerciales: el gateway, el pipeline de verificación y evidencia, y las superficies del operador. La línea sigue a la arquitectura y no a una lista de precios. Lo que resulta útil en una sola máquina se regala; lo que solo significa algo a través de muchas máquinas es lo que se vende.

En vivo, medido el 2026-09-07: tres paquetes (ai-layer-core, ai-layer-marketing y ai-layer-infra) que reúnen 88 skills y 25 agentes, 283 archivos exportados en la versión 0.9.0, publicados bajo la licencia MIT [98].

Alguien ajeno al proyecto lo instala con tres comandos:

/plugin marketplace add https://gitlab.com/kriscodes2-claude-plugins/ai-layer.git
/plugin install ai-layer-core@kriscodes2-claude-plugins
/ai-layer:doctor --fix

Un único resolvedor elige entonces uno de tres modos del cerebro. gateway se elige cuando se resuelve un token de gateway, y el servidor de cerebro del plugin reenvía al Brain Gateway. local se elige cuando no se resuelve ningún token y el binding de DuckDB está instalado, y el cerebro es un único archivo DuckDB en el disco del propio lector. setup se elige cuando no se cumple ninguno de los dos, y cada servidor ofrece una sola herramienta de estado que nombra el único comando que lo arregla. El modo local acumula sesiones, transcripciones y un índice de símbolos, y responde consultas de memoria y de símbolos sobre ellos, con el servidor de lenguaje usando el propio TypeScript del proyecto que lo consume. Es de una sola máquina y de escritor único por construcción, así que no tiene búsqueda híbrida, ni recorrido de grafos, ni coordinación entre dos agentes en un mismo repositorio.

El límite se publica en lugar de insinuarse: Gratis y con licencia MIT: los paquetes (skills, agentes, reglas, hooks, plantillas), ambos servidores MCP y un cerebro local de una sola máquina. No se incluyen: el Brain Gateway (el cerebro compartido multisesión, el plano de coordinación, la búsqueda híbrida y de grafos, y la ingesta a escala de flota), el centro de mando de Koinessa, el pipeline de verificación y evidencia, Koinessa Desktop, los componentes del catálogo de CI/CD y Autopilot. Una skill que necesita el gateway no se degrada en silencio: imprime una línea que nombra lo que falta, y se detiene.

4. Evidence-Gated Agentic Development

Evidence-Gated Agentic Development (EGAD) es un modelo de entrega de software en el que los agentes de IA producen e integran cambios pequeños en la rama principal, mientras que la autoridad de commit, push, promoción y release permanece limitada por verificación determinista, evidencia firmada, gates de política y excepciones controladas por humanos.

El bucle operativo tiene diez etapas, y cada una existe para eliminar un modo de fallo específico: observar el estado actual del sistema y del negocio (ningún trabajo parte de supuestos obsoletos); recordar decisiones, arreglos y fallos previos desde el cerebro (sin volver a derivar lo que la organización ya pagó por aprender); planificar trabajo acotado con requisitos de verificación declarados; reclamar la propiedad mediante arriendos y reclamos de archivo (sin colisiones silenciosas); compilar contexto — construir el paquete de contexto acotado a partir del estado canónico (ninguna sesión hereda una transcripción como su memoria); ejecutar dentro del límite reclamado; verificar con herramientas deterministas que emiten estados de resultado canónicos; aprobar las transiciones con consecuencias según la política, dejando las excepciones en manos humanas; enviar y observar el resultado desplegado, no solo el merge; y aprender — escribir el resultado verificado de vuelta en la memoria, donde lo encontrará el recall de la siguiente sesión. Tres propiedades distinguen el bucle de la «programación autónoma»:

1. La autoridad se deriva del estado, no de la confianza. Que un agente reporte que el trabajo está completo no cambia nada; el paquete de evidencia adjunto al commit actual sí lo hace.
2. Las capacidades son peldaños, no un interruptor. Generate, stage, commit, push, merge, promote y deploy son capacidades delegables separadas, que se amplían por clase de tarea a partir del historial verificado — los lotes pequeños basados en la rama principal [19] hacen que cada peldaño sea barato de comprobar.
3. La verificación es independiente de la generación. Herramientas deterministas, modelos separados o humanos evalúan; el generador nunca califica su propio trabajo (sección 2.6), y la política — codificada como reglas versionadas y comprobables en lugar de texto de prompt — decide si la evidencia satisface el perfil [4][5]. OPA es una fuente del patrón general de política como código [18]; Koinessa no afirma incorporar a OPA.

En vivo. El bucle es adaptativo al riesgo de extremo a extremo (AAV-001, implementado el 2026-08-12). Cada elemento de trabajo lleva un nivel de riesgo legible por máquina (R0-R3) que deriva de forma determinista su perfil de verificación y su política de aprobación. El trabajo R2/R3 ni siquiera se puede reclamar sin un brief de tarea válido según el esquema — el gate de conversación-a-contrato, aplicado dentro del compare-and-set del reclamo — de modo que la conversación exploratoria nunca puede deslizarse hacia una implementación de alto riesgo. El manifiesto de evidencia acepta evidencia conectable por dominio, con firmware/hardware (simulación, comprobaciones formales, HIL, cadena de herramientas e identidad de placa) como la primera extensión más allá del CI de software, bajo la regla de que compilar no es demostrar. Y la deuda de verificación se mide a sí misma: las métricas de fuga de defectos, carga de revisión, retrabajo y lead time caen en el mismo warehouse que cualquier otro comprobante. Koinessa se alinea con varios principios de control de proceso articulados por Agentic Agile-V [86]: la conversación descubre la intención, los artefactos estructurados impulsan la implementación, y la evidencia condiciona la aceptación. Esto es alineación, no una equivalencia o convergencia demostrada de forma independiente.

5. Autonomía por niveles de riesgo

La autonomía debe expandirse demostrando qué clases de acción se pueden delegar bajo qué controles — nunca declarando que un sistema es autónomo. La plataforma lleva dos ejes de nivel legibles por máquina, y miden cosas distintas. Cada elemento de trabajo lleva un nivel de verificación R0-R3 (AAV-001, en vivo) que deriva de forma determinista sus gates requeridos, su requisito de brief y su política de aprobación; cada clase de acción lleva un nivel de acción 1-4 (EGA-001, en vivo) que califica el radio de impacto de reversible a irreversible, evaluado en modo fail-closed por una política versionada. Son dos ejes de una misma disciplina — cuánto rigor le debe este elemento de trabajo frente a cuán peligrosa es esta clase de acción. Los niveles en prosa a continuación son el eje de acción, con la correspondencia nominal de elemento de trabajo entre paréntesis; EGD-002 elimina la colisión residual de nombres de tipo en el código y fija la correspondencia como un módulo probado.

• Nivel de acción 1 (R0) — reversible, de bajo impacto (documentación, índices generados, formateo, investigación): automatización amplia una vez que la evidencia está completa.
• Nivel de acción 2 (R1) — cambios de ingeniería acotados (cambios pequeños de código, actualizaciones de dependencias, refactorizaciones internas, generación de pruebas): gates deterministas, revisión humana en límites seleccionados.
• Nivel de acción 3 (R2) — acciones externas con consecuencias (despliegue a producción, eliminación de datos, medios pagados, comunicación con clientes, transacciones financieras): credenciales limitadas, aprobaciones explícitas, ejecución idempotente, rollback probado.
• Nivel de acción 4 (R3) — acciones irreversibles o críticas para la seguridad: autorizado por humanos, potencialmente con revisión independiente, simulación o análisis formal.

Los límites de nivel solo son creíbles cuando cruzarlos cuesta ceremonia. Un ejemplo real de este sistema: renombrar la clave de identidad estampada en cada fila del cerebro — parte de la clave primaria en muchas tablas — no se ejecutó como una sola sentencia UPDATE, sino como cuarenta y siete reconstrucciones secuenciales de tabla completa (build, inserción masiva, renombrado atómico, checkpoint, verificación), con 110,811 filas reclasificadas en vivo y cero corrupciones, precisamente porque una actualización de clave in situ anterior había corrompido la base de datos. La ceremonia no es sobrecarga; es la razón por la que el sistema sigue funcionando. La promoción entre niveles debería, del mismo modo, ganarse con criterios medidos — tasas de colisión, tasas de trabajadores obsoletos, tasas de éxito verificado, frecuencia de intervención humana, efectividad del rollback — registrados por cada activación, nunca concedidos porque el sistema haya estado tranquilo últimamente.

La ruta de Autopilot de Koinessa — la maquinaria que lleva un documento de requisitos aprobado, a través de la implementación, hasta un pipeline verde verificado — está etiquetada como No habilitado: ha corrido simulacros en vivo supervisados de principio a fin, y su postura, bloqueada por decisión, es fail-closed, con el rearme como una acción explícita del operador. Consideramos que esa postura es una virtud. Los sistemas deberían ganar autoridad a partir de su historial operativo, y el proceso de ganársela debería ser aburrido.

6. Valor de negocio I — ventaja de costos: local-first por arquitectura

La primera ventaja de costos es estructural, no negociada: Koinessa corre sobre infraestructura que el operador ya posee.

6.1 Ejecución local-first

En vivo. El cerebro es un archivo DuckDB local detrás de un gateway local. El motor de verificación corre en un clúster k3s local con un registro de imágenes Zot local — más de 69 trabajos deterministas se ejecutan sin comprar minutos de CI en la nube. Los modelos locales (alojados en Ollama, por ejemplo un modelo de instrucción/codificación de 27B en la GPU del operador) realizan trabajo acotado — compilación de contexto, redacción de borradores, reducción de logs, clasificación de fallos — a costo marginal cero de proveedor. Ollama Cloud [83] es el siguiente peldaño de la misma escalera: Ollama afirma que la ejecución del modelo se descarga automáticamente a su servicio en la nube, mientras quienes llaman pueden seguir usando las interfaces de Ollama. Los modelos de frontera en la nube (Claude, Grok, Codex, Kimi — con Devin registrado y deshabilitado, sección 3.6) permanecen como capacidad arrendada para el trabajo que justifica esa inteligencia, no como la ruta predeterminada para todo. La medición externa ahora respalda que esto sea un principio de primer orden y no un truco de costos. AgentFloor es un benchmark determinista de 30 tareas, sintético y de solo lectura sobre uso de herramientas; sus resultados no demuestran que las ediciones de repositorio o las operaciones de producción sean seguras [68]. E2B significa parámetros efectivos: Gemma 4 E2B anuncia pesos base móviles de menos de 2GB, mientras que Gemma 3n E2B reporta una carga de memoria efectiva de aproximadamente 1.91B [88][89]. La regla de diseño es la siguiente: no construyas un reemplazo local para un modelo de frontera — descompón la carga de trabajo hasta que solo una fracción pequeña requiera inteligencia de frontera, y escala a lo largo de la escalera (micromodelo, modelo local pequeño, modelo local más grande, nube económica, frontera) según la capacidad demostrada, nunca según la marca.

6.2 El cómputo local se encarga de la gestión del contexto

En vivo. La regla de diseño de AOE-001 es que el modelo en la nube tiene memoria de trabajo, mientras que Koinessa tiene memoria del proyecto. Reductores deterministas e inferencia local ensamblan, comprimen y formatean el contexto antes de que un modelo de frontera lo vea siquiera. La carga de trabajo medida del operador durante 30 días (del 2026-07-11 al 2026-08-09) muestra por qué esto importa: de 18,284,233,434 tokens totales, 17,088,709,895 — el 93.46% — fueron lecturas de caché: historial que se vuelve a cargar, no trabajo nuevo que se esté haciendo. A precio de lista, esa ventana se estima en $13,910.58. Cada token de contexto ensamblado o reducido localmente es un token que el proveedor de frontera no factura.

6.3 Retrieval first

En vivo. Los agentes no comienzan explorando el código base con grep, sed, y lecturas de archivo hechas con la esperanza de encontrar algo. El índice de inteligencia de código (alimentado por Doxygen, 17,903 símbolos solo para este proyecto en la instantánea del 2026-08-23, indexado por última vez el mismo día) responde «qué archivo, qué líneas, qué firma exacta, qué archivos dependen de él» como una sola consulta de DuckDB — milisegundos, con un resultado lo bastante pequeño como para pegarlo en un paquete de contexto. Lo mismo es válido para el conocimiento institucional: los PRD, requisitos, políticas, decisiones y registros de procedencia son tablas y documentos en el cerebro, recuperables mediante SQL y búsqueda híbrida, en lugar de tener que volver a derivarse del historial de chat o de estar dispersos en una wiki. La regla permanente para los agentes es retrieval-first: índice de símbolos y LSP para el código, consulta al cerebro para el conocimiento, grep solo como respaldo declarado — y la regla ahora se aplica mecánicamente, no de forma aspiracional: un hook previo a la herramienta rechaza las búsquedas de identificadores por texto en los harnesses de Claude y Kimi, y responde a ese rechazo con la consulta exacta del índice que hay que ejecutar en su lugar (en vivo). El índice también tiene un comprobante de un harness que Koinessa no controla: en una prueba de sandbox controlada (comprobante de repositorio, 2026-08-23, una pregunta en una sesión de nivel pagado), el Devin CLI respondió una pregunta de ubicación de símbolo a través del índice de símbolos del cerebro en cuatro segundos — 44,496 tokens de prompt, 42,752 de ellos lecturas de caché, 329 tokens de finalización, once pasos, sin búsqueda de texto y sin lectura de fuente — mientras que la misma pregunta, enrutada a través de herramientas de language server, costó 171,317 tokens de prompt en dieciséis pasos, aproximadamente cuatro veces el costo en tokens. Una pregunta, un harness, un día; se cita como un comprobante, no como un benchmark.

La medición externa acota esta decisión desde ambos lados. En un estudio de control de calidad sobre un repositorio de Python de solo lectura, la recuperación semántica costó $0.32 por respuesta correcta frente a $0.74 para Deep; Deep resultó unas 2.3 veces más caro y lo semántico, un 57% más barato. La brecha de tokens más grande, 22.4 veces, se dio específicamente con Qwen3-235B [73]. Un sistema estructural de grafo de código distinto reportó una calidad de 83% frente a 92%, cerca de diez veces menos tokens y 2.1 veces menos llamadas a herramientas, conservando la exploración como respaldo [74]. La contraposición es real y vale la pena decirla con claridad: Anthropic probó un índice de recuperación dentro de las primeras versiones de Claude Code y lo eliminó en favor de la búsqueda agéntica, citando obsolescencia, privacidad y fiabilidad. Esas son objeciones arquitectónicas, y esta arquitectura las responde — el índice es exclusivamente local, nunca sale de la máquina, y se actualiza en cada commit mediante los mismos hooks que mantienen la evidencia al día; grep sigue siendo el respaldo declarado, no una herramienta prohibida. Retrieval-first es un primer salto barato, no una doctrina de que el índice reemplaza a la búsqueda.

7. Valor de negocio II — recuperación medida y economía del contexto

No existe un resultado observado de tarea completa ni de 70 veces. Los estudios externos y los comprobantes internos miden componentes no equivalentes, así que no se multiplican entre sí. Cualquier proyección interna futura debe declarar sus supuestos y usar, ya sea un factor secuencial medido, ya sea una ecuación ponderada. Sigue siendo un cálculo de diseño condicional, nunca un benchmark.

Los límites actuales son útiles sin necesidad de un titular compuesto:

En vivo. El Context Compiler y la ruta retrieval-first buscan reducir el arrastre repetido de contexto y la exploración. La telemetría identifica dónde se acumuló el costo; no demuestra cuánto habría gastado un flujo de trabajo contrafactual. El KPI de control es el trabajo verificado por dólar, atribuido por elemento de trabajo e interpretado manteniendo intactos la calidad de la tarea, la aceptación y el costo de revisión humana.

Los mensajes compactados permanecen en el contexto activo solo en forma resumida, y son recuperables por completo únicamente cuando se han persistido por separado. La pérdida de información es una inferencia sobre el detalle no persistido, no una afirmación de que se destruya todo registro durable [87]. Los resultados específicos del benchmark de NoLiMa — 11 de 13 — y los resultados de GPT-4o de 99.3 a 69.7 aportan otra razón acotada para mantener el estado canónico fuera de la ventana del modelo [72].

8. Valor de negocio III — mejor y más rápido

El costo es el piso; el control es el multiplicador.

8.1 Procedencia y gobernanza

En vivo. Cada acción consecuente lleva una cadena desde la intención hasta el resultado: requisito, elemento de trabajo, principal, sesión de agente, modelo, archivos, commit, pipeline, evidencia, decisión de política, aprobación, despliegue, resultado operativo (secciones 2.4–2.5). El libro mayor temporal responde «qué creíamos cuando esto se autorizó» como una consulta. La gobernanza no es una presentación de diapositivas; es una tabla que puedes auditar.

8.2 Política de tipo IAM, confianza cero internamente

En vivo. La identidad se separa de la misma forma en que la separan los sistemas IAM maduros: identidad de principal (quién está operando), identidad de inquilino/proyecto (de quién son los recursos en alcance), identidad de agente/sesión (qué trabajador está actuando), autoridad de trabajo (qué tarea acotada posee), autoridad de capacidad (qué clases de acción puede realizar), identidad de proveedor e identidad de evidencia. El segmento de identidad pasó de diseño a código en agosto: las sesiones llevan un principal, los permisos se evalúan contra una política versionada con decisiones persistidas [18] en lugar de texto de prompt, las cuotas del gateway y los alcances de escritura se asignan por principal y por tabla, los libros mayores de auditoría y de eventos estampan el principal actuante, y el gateway puede exigir un principal sin excepción. La presencia en la red no es autoridad — una conexión LAN no otorga confianza implícita, según la doctrina de confianza cero [5]; las lecturas mismas están identificadas por bearer token en cualquier enlace que no sea loopback (sección 3.2). Un trabajador puede ser capaz de alcanzar un recurso aunque le falte la autoridad de política para usarlo, y ambos hechos se comprueban.

8.3 Diseño multiinquilino — tres propiedades separadas

El alcance del almacenamiento, los operadores concurrentes y la elección de proveedor de inferencia tienen límites de evidencia distintos.

1. Tenencia de datos (En curso). De 346 tablas base, 333 llevan project_id y 13 tablas compartidas o de infraestructura no lo llevan. Cada escritura externa atraviesa el gateway de escritor único, donde se hacen cumplir la identidad y el alcance, pero este libro blanco no infiere aislamiento universal de inquilinos a partir de una propiedad parcial del esquema. TEN-001 está en curso al 78% y MTC-001 al 81% en revisión; el endurecimiento de principales externos sigue incompleto.

2. Tenencia de operadores concurrentes (En vivo). Dos personas —el fundador y un segundo operador— trabajan habitualmente al mismo tiempo en el mismo repositorio, desde dos PC distintas en la misma red de área local, cada una dirigiendo sus propios enjambres de agentes. La PC principal sirve el gateway del cerebro y el daemon local de Ollama; la segunda estación de trabajo es un cliente LAN de primera clase de ese host, no una copia de la base de datos. Los reclamos de archivo, las concesiones de elementos de trabajo y los fencing tokens son lo que hace que eso sea seguro: al plano de coordinación no le importa qué humano, qué proveedor o qué caja física ocupa el trabajador. Esta es una propiedad operativa que usa un equipo de dos personas. También es la propiedad que compra un equipo más grande cuando compra el plano de control — no la promesa de que se puedan tener abiertas dos ventanas de chat, sino el hecho demostrado de que dos humanos más muchos enjambres de proveedores pueden compartir una rama principal sin colisionar.

3. Portabilidad de la capa de inferencia (En vivo donde hay comprobante; neutralidad más amplia con estado Planeado). El mismo tablero, las mismas concesiones y las mismas puertas de evidencia aceptan trabajadores interactivos de Kimi, Claude, Grok, Codex, modelos locales personalizados de Ollama, y Ollama Cloud [83]; un séptimo proveedor, Devin, está registrado como descriptor y deshabilitado (sección 3.6). Los comprobantes de ejecución actuales provienen de esos carriles interactivos; la capa de transporte gestionada que convertiría un cambio de proveedor en algo puramente de configuración está construida pero no habilitada, sin ningún descriptor activo. Un cambio de proveedor es una meta de diseño interna, no una neutralidad probada externamente ni una promesa de que cada proveedor sea solo de configuración.

La consecuencia para los compradores: el aislamiento de inquilinos, la seguridad de operadores concurrentes y la neutralidad de modelos se verifican de la misma manera que el código —como evidencia, según el modelo de resultados de seis estados— y no como una promesa contractual.

8.4 Operación del plano de control sin conexión

No habilitado. El plano de control local está diseñado para permanecer disponible si un proveedor de modelos cambia los términos, internet no está disponible, o el trabajo debe ejecutarse en un entorno cerrado: el cerebro, el gateway, el plano de coordinación, el motor de verificación, el registro de imágenes y los runners de CI son locales, y los modelos locales pueden continuar con trabajo acotado. La aceptación en máquina limpia y la aceptación específica de proveedor siguen rigiendo las afirmaciones de producción.

8.5 Qué mide el cerebro

Comprobante con estado En vivo, instantánea del 2026-08-23. No se afirma ningún multiplicador de productividad de tarea completa. El cerebro, el tablero y el repositorio indexado proporcionan los siguientes conteos directos (cada contador mutable lleva su instante de instantánea en el Apéndice A, y la instantánea necesariamente precede a la publicación que la cambia):

• Telemetría de tokens (27 días registrados hasta el 2026-08-16; ningún día posterior ingerido a partir del 2026-08-23): 22,696,191,284 tokens en total, de los cuales 20,918,082,610 —92.17%— fueron lecturas de caché. A precio de lista, esa ventana es de $12,027.14. Es telemetría a precio de lista, no gasto realizado.
• Tablero de entrega: 258 tarjetas; 145 completadas / 74 en progreso / 34 en el backlog / 4 en revisión / 1 bloqueada; 68.6% de finalización promedio de historias; 143 tarjetas al 100%. Eso es todo el portafolio, incluido el trabajo de marketing y generación de leads exclusivo del operador, que no está en el escritorio distribuible. Los cinco planos que describe este libro blanco están en vivo. Hacia la producción, la épica de cierre de Desktop (instalador, ruta de descarga pública, licencia de evaluación, bloqueo KEEP/DROP) se cerró el 2026-08-19 con la aceptación del operador; el instalador permanece sin firmar y la validación de humo en máquina limpia no se ha ejecutado (sección 8.7).
• Comprobantes de coordinación: 1,733 reclamos de archivo y ocho enjambres registrados; 100 commits en la rama principal desde el 2026-08-19 hasta el 2026-08-23, 691 desde el 2026-08-05 hasta el 2026-08-23, y un pico de 84 el 2026-08-13.
• Tamaños de índice: 17,903 símbolos de Koinessa, 54,201 federados; 366 herramientas y 5,351 documentos curados (ambos sin cambios desde el 2026-08-18); 1,619 archivos de prueba/spec indexados en git en este árbol.

Postura de diseño. La memoria durable debería reducir la re-derivación; retrieval-first debería reducir la exploración innecesaria; la coordinación explícita debería reducir las colisiones; y las puertas de evidencia deberían hacer que la aceptación sea más revisable. Los comprobantes anteriores muestran el estado operativo, no efectos causales controlados.

8.6 Ejecución paralela de modelos

En vivo. Trabajadores interactivos de Kimi, Claude, Grok, Codex, modelos locales personalizados de Ollama y Ollama Cloud [83] trabajan el mismo tablero simultáneamente, separados por reclamos de archivo, concesiones de trabajo y fencing tokens, y no por cortesía. Dos operadores humanos en dos PC de LAN pueden —y de hecho lo hacen— dirigir esos enjambres al mismo tiempo; eso es tenencia de operadores concurrentes, no una segunda copia del cerebro. Un comprobante de repositorio registra que el 2026-08-12 una única sesión orquestadora (a) escaneó el entonces tablero de trabajo de 266 tarjetas, (b) ejecutó dos agentes exploradores en paralelo para mapear dos costuras de código, (c) hizo que un modelo local de 27B redactara el documento de requisitos a partir de sus reportes, (d) ejecutó dos agentes programadores en paralelo sobre flujos de trabajo disjuntos implementando cuatro historias, y (e) volvió a ejecutar de forma independiente la suite de verificación completa —11,271 pruebas en verde— antes de que se aceptara el trabajo. El contexto de ninguna sesión contenía el proyecto; el cerebro sí. La medición externa proporciona una comparación acotada: el 0.5% de los pares co-activos involucró a agentes distintos, no el 0.5% de los pull requests. En una muestra de reproducción, los conflictos textuales de Git fueron del 41.7% frente al 19.8%; esos son conflictos textuales, no conflictos semánticos [69].

8.7 Vehículo de producción y el modelo de dos ramas

Koinessa se desarrolla en dos líneas de larga duración, y este libro blanco describe el arreglo como deriva medida en lugar de paridad implícita. El centro de comando del operador —el sistema operado por el fundador cuyos comprobantes llenan este libro blanco— conserva todas las superficies, incluidos los carriles de automatización de marketing, generación de leads, social y arte: esos no son el producto; son evidencia de validación permanente de que el plano de control se generaliza más allá del código, ejercitada a diario contra el estado real del negocio. Koinessa Desktop es el corte de producción: una distribución de Electron con su propio historial de repositorio desde el 2026-08-12, un conjunto de funciones reducido, y las superficies de confianza que necesita un tercero — claves de licencia sin conexión con niveles de asientos, flujos de compra, proveedores de identidad (LDAP, OIDC, SAML, SCIM, con Kerberos enviado apagado, pendiente de validación con un directorio real), y adaptadores para cuatro proveedores de CI. Su documento de requisitos rector se cerró con la aceptación del operador el 2026-08-19.

La deriva se cuenta en ambas direcciones. Desde la separación: 441 commits en la rama principal en el centro de comando frente a 110 en la línea de Desktop hasta el 2026-08-23. La capa de proveedor unificada de la sección 3.6 —descriptores, transportes, árbitro, el puente de compactación, el registro de herramientas, la cadena de evidencia, los niveles de riesgo, el libro mayor temporal y el plano de coordinación— se portó a Desktop el 2026-08-17; el descriptor y la salvaguarda de Devin, la compactación de transcripciones, la conformidad de proveedores y la ruta de auto-restauración del cerebro aún no han cruzado. El instalador de Desktop es una compilación de Windows que permanece sin firmar; la validación de humo en máquina limpia no se ha ejecutado; los paquetes de macOS y Linux están bloqueados; y el carril de actualización automática está construido contra un feed de marcador de posición (cada uno un comprobante de repositorio, verificado el 2026-08-23). Las funciones se prueban primero en el centro de comando con todo el sistema en ejecución, y luego se portan; los dos historiales se reconcilian mediante un proceso de transferencia explícito, y no mediante merges.

8.8 Para quién está construido esto

Koinessa está construido para los equipos de plataforma, experiencia de desarrollador y seguridad que son dueños de la entrega agéntica en organizaciones que ya ejecutan varios agentes de codificación con IA contra un CI/CD maduro — los equipos a los que se les pregunta, después del hecho, qué se hizo, por cuál trabajador, bajo la autoridad de quién, y con qué prueba. Los controles de este libro blanco —alcance por inquilino con autoridad y auditoría por principal, separación de identidad de grado IAM, política como código versionado, cadenas de procedencia desde la intención hasta el despliegue, y paquetes de evidencia que se corresponden con las expectativas de garantía de estilo SSDF [21][22]— existen para que un equipo así pueda elevar los niveles de autonomía a través de muchos desarrolladores sin perder esa respuesta. La propia operación de los fundadores —tres pequeños negocios que corren sobre una sola configuración de agentes— es el origen del diseño y su terreno de prueba diario, no su escala prevista. Una evaluación deliberadamente escéptica y fundamentada en evidencia externa (2026-08-13, insumo de diseño) aplicó la propia disciplina de este libro blanco a sus afirmaciones —citas externas verificadas, supuestos de planeación etiquetados como supuestos, ningún multiplicador de productividad de tarea completa— y encontró que el problema subyacente era real y cada vez más medido externamente, desde el «impuesto de verificación» de DORA [25] hasta los pull requests agénticos que sustituyen la revisión en lugar de escalarla [29]. Dejó una condición que la plataforma aún no había cumplido: terminar el sustrato de confianza antes de pedirles a las organizaciones sensibles a la confianza que confíen en él. EGD-002 cerró ese sustrato (sección 2.7), y sus sucesores (secciones 3.9 y 10) se sostienen al mismo estándar.

9. Hoja de ruta

Once direcciones, etiquetadas con honestidad. Cada una lleva criterios de aceptación binarios en el PRD del producto, porque un elemento de hoja de ruta sin una condición de salida falsable es marketing. El estado es una instantánea del 2026-08-23 del tablero de trabajo en vivo, salvo que se nombre un comprobante del repositorio:

1. Contratos de identidad unificados entre herramientas, agentes, runners, trabajo y evidencia (En curso — TEN-001 está al 78% y MTC-001 está al 81% en revisión; los principales de sesión, la evaluación de permisos contra política versionada, las cuotas de gateway y los alcances de escritura por principal, y la auditoría estampada por principal se entregan como comprobante del repositorio; el endurecimiento de principales externos, no).
2. Registro operacional temporal: clases de autoridad, vínculos de evidencia, consultas a una fecha determinada (En vivo — BRN-002 está terminado al 100%).
3. Perfiles de capacidad de agentes verificados: enrutar el trabajo según capacidad demostrada y verificada (En vivo — EGA-001 está terminado al 100%, 16/16; AAV-001 está terminado al 100%, 8/8).
4. Verificación agnóstica de lenguaje: un solo sobre de evidencia canónico por ecosistema — Node/TypeScript es lo más sólido hoy, los componentes de Java y C++ están construidos, los perfiles de conformidad de C y Ada, solo como especificación, están disponibles; las imágenes de la flota de CI de Python, Go y Rust se construyeron y catalogaron con autopruebas integradas en la imagen el 2026-08-19 (comprobante del repositorio), mientras que sus perfiles de conformidad siguen sin construirse (con estado En curso donde está implementado; los perfiles restantes con estado Planeado).
5. Puesta en escena supervisada de Autopilot, con criterios de entrada y salida medibles (No habilitado; la continuación de APX-001 está En curso al 74%, mientras que la tarjeta base de APX-001 está terminada).
6. Autoridad de Git en capas, ganada por clase de tarea (Planeado).
7. Maduración del bucle de reparación: taxonomía, confianza calibrada, reverificación independiente (bucle con estado En vivo; maduración con estado Planeado).
8. Bucles de acción comercial cerrados, con ejecución idempotente y aprendizaje de resultados (En curso).
9. Superficies de confianza empresarial: RBAC, tenencia, recuperación, exportación de auditoría (En curso — TEN-001 al 78%). La tenencia concurrente de operadores está En vivo; el endurecimiento de principales externos permanece incompleto.
10. Gobernanza de red de agentes por encima de MCP/A2A: membresía, delegación, revocación, repetición (sustrato local con estado En vivo — EGD-002 está terminado al 100%, 12/12 y aprobado en revisión; la membresía entre redes permanece con estado Planeado).
11. Incorporación de proveedores como pipeline gobernado y repetible: registrar el descriptor deshabilitado, hacer commit de una salvaguarda de denegar-todo, pasar una puerta de bloqueo, ejecutar la conformidad y, luego, un simulacro de habilitación con control del operador (ejemplo funcional con estado En vivo — el sexto descriptor llegó exactamente a través de esta secuencia el 2026-08-23; la generalización está En curso, en revisión).

Comprobante de tablero en vivo. BRN-002, EGA-001, AAV-001, EGD-001, EGD-002, AOE-001 y XFR-001 están terminados al 100%. DSK-001 está al 63% en el tablero, pero quedó reemplazado como el vehículo de salida al mercado; tanto el propio documento de requisitos de la línea Desktop como su épica de cierre de producción se cerraron con aceptación del operador el 2026-08-19 (comprobante del repositorio — el analizador del registro todavía no los ha ingerido). El instalador sigue sin firmar y la validación de humo en máquina limpia no se ha ejecutado (sección 8.7). Esto no es una aceptación de producción completada.

10. Limitaciones y estado

Koinessa está en prelanzamiento y operado por su fundador; no ha sido auditado de forma independiente, y ninguna afirmación aquí debe leerse como certificación o cumplimiento — los marcos son orientación, un control es comportamiento implementado, la evidencia demuestra que el comportamiento ocurrió [21][22], y la certificación es una determinación aparte. 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 es desigual entre lenguajes (sección 9, elemento 4). Autopilot se mantiene fail-closed por norma. No se afirma ningún multiplicador de rendimiento de tarea completa. El 85.6% de participación del lado de entrada es una derivación de un ejemplo de trabajo publicado, no una estadística impresa por un proveedor; las lecturas de caché por sí solas representan alrededor del 51% en ese ejemplo.

Límites específicos de esta edición, expresados como medidos. La capa de proveedores de sesión gestionada está construida pero no habilitada: seis descriptores, cero habilitados, y el árbitro no tiene quién lo invoque — los comprobantes multiproveedor de este libro blanco provienen de sesiones interactivas (sección 3.6). La compactación de transcripciones está integrada de forma desigual entre proveedores (sección 3.7), y el registro de digests de transcripciones tenía cero filas en esta instantánea. Los registros de evidencia y conformidad del lado del Cerebro tenían cero filas en esta instantánea; los manifiestos y la firma del lado de CI son la vía operativa (sección 2.5). El 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 este árbol de trabajo — una sesión en la nube de un proveedor que opera sobre su propio clon de un repositorio se rige por las reglas del repositorio y los controles del lado del proveedor, no por los hooks de este árbol. Ningún pipeline de CI completo de la rama principal se había completado en verde de extremo a extremo al 2026-08-23; los trabajos de verificación se ejecutan localmente y por trabajo, y el primer pipeline verde de la rama principal está en curso. Dos corrupciones del archivo principal del Cerebro ocurrieron en la semana previa a esta edición; 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, y la legibilidad en modo degradado es un borrador (sección 3.9). La ingesta de telemetría de uso, documentos curados y del registro de herramientas no produjo filas nuevas entre sus lecturas del 2026-08-16/18 y esta instantánea, por lo que este libro blanco reporta esos recuentos como sin cambios, y no como un crecimiento vuelto a medir. El modelo de producción de dos ramas (sección 8.7) implica que la línea de Desktop va por detrás del centro de mando del operador en capacidades medidas en una fecha dada; la brecha se indica por capacidad y nunca se asume cerrada. Y debido a que la publicación de este propio libro blanco escribe en el sistema que mide — sus filas de revisión, hechos, reclamos de archivo, y el commit que lo transporta todo, aterrizan en el Cerebro y en el historial de git — cada contador mutable aquí es un instante de instantánea fijado que necesariamente precede a la publicación que lo modifica.

El límite de núcleo abierto se expresa como medido. La capa de IA reutilizable está marcada como En vivo en la v0.9.0 al 2026-09-07, publicada bajo la licencia MIT e instalable por cualquiera (sección 3.12). Su modo local es de una sola máquina y de escritor único: las lecturas abren el cerebro en modo de solo lectura en cada llamada, y toda escritura pasa por un único proceso escritor. El Brain Gateway no forma parte de la capa gratuita, y tampoco lo son el centro de mando de Koinessa, el pipeline de verificación y evidencia, Koinessa Desktop, los componentes del catálogo de CI/CD ni Autopilot. La etiqueta de afirmación de koinessa.com para la capa quedó marcada como En vivo en esa misma fecha.

Los demás comprobantes citados en este libro blanco (recuentos de commits, recuentos de archivos de prueba, tamaños de índice, recuentos de tablas, telemetría de tokens, columnas del tablero) se verificaron contra el sistema en vivo, el historial de git y el tablero de trabajo para la instantánea del 2026-08-23, y cambiarán con el tiempo; el registro de afirmaciones es su fuente de verdad. El vehículo de producción es Koinessa Desktop; su evidencia de repositorio y este centro de mando del operador son carriles de evidencia separados. Las estadísticas externas de la sección 1.1 se reproducen con fechas y etiquetas de procedencia en el digest de investigación de EGD-001; cuando una cifra en circulación es telemetría de proveedor, está en disputa, o es metodológicamente débil (la afirmación «el 95% de los pilotos de IA fracasan», por ejemplo), el digest lo indica así, y este libro blanco la omite o la matiza. La sonda automática de afirmaciones externas comprueba que el digest versionado permanezca rastreado; comprueba la integridad del rastro de evidencia, no la recuperación en vivo de URLs. Las 22 filas externas permanecen en disputa para su reutilización automatizada u operativa. Esta edición aprobada por el operador las presenta únicamente como evidencia externa explícitamente citada y acotada por población; ninguna fila se promueve a live. La revisión humana de fuentes primarias y la promoción explícita siguen siendo necesarias antes de que el registro de afirmaciones trate una fila como evidencia aprobada reutilizable. Un agente puede asistir en la investigación, pero no puede promover una afirmación. El PDF maquetado archivado sigue siendo una instantánea histórica, y no el artículo canónico. Finalmente, el resultado de coordinación multiproveedor es evidencia operativa de un solo sistema, no un estudio controlado — lo publicamos como un comprobante, no como un benchmark.

Apéndice A — Comprobantes operativos respaldados por el Cerebro (2026-08-23)

Estas cifras se leyeron del Cerebro, de repositorios indexados, del historial de git o del tablero Kanban en un único instante de instantánea — 2026-08-23 22:28 ET, el momento en que se congeló el código fuente de esta edición para su renderizado, después de que aterrizara la última fila de revisión de su propio pipeline de publicación — salvo donde una fila indique su propio instante. Cambiarán con el tiempo; la propia publicación de este libro blanco mueve varias de ellas, y el registro de afirmaciones es la fuente de verdad. Los recuentos extraídos de ventanas de git se miden por fecha de confirmación (git rev-list --count --since --until HEAD) en el commit c0af7fd3; debido a que este árbol reescribe el historial durante barridos automatizados, un commit puede moverse entre días, por lo que una ventana corta es una medida de esa ventana en el instante indicado, y no un hecho histórico fijo.

Los autobenchmarks preregistrados de EGD-001 (US-017) siguen siendo el camino declarado hacia mediciones de productividad reproducibles y ajustadas a la tarea. Hasta que estos existan, este libro blanco no inventará un multiplicador.

Lecturas adicionales

• Cognition. "Agent Trace: Capturing the Context Graph of Code," 2026-01-29.