Hoja de ruta de Koinessa: once direcciones, etiquetadas con honestidad

2026-08-30 · Desarrollo de producto ·

Si diriges una empresa AI-first, la matemática de escalar deja de funcionar mucho antes que la matemática de los ingresos. Los agentes generan trabajo más rápido cada trimestre, pero cada decisión de criterio — ¿esto está verificado?, ¿esto está listo?, ¿quién lo aprobó?, ¿qué pasa después? — sigue pasando por la misma una o dos personas. Escalar la producción sin escalar la plantilla significa que el fundador se convierte en el cuello de botella de cada decisión que los agentes no pueden tomar de forma segura. La salida no es más automatización en abstracto. Es una hoja de ruta donde a cada elemento se le permite eliminar un criterio humano específico solo después de haber demostrado, en términos binarios, que puede reemplazar ese criterio. Cualquier cosa menos honesta que eso es una presentación de diapositivas.

Por qué la mayoría de las hojas de ruta son marketing

La sección 9 del libro blanco de Koinessa se abre con una afirmación que no vamos a suavizar: un elemento de hoja de ruta sin una condición de salida falsable es marketing. Por eso las once direcciones de la hoja de ruta llevan criterios de aceptación binarios en el PRD del producto. Cada una tiene una prueba que puede fallar. Si falla, el elemento no está terminado, sin importar cuánto código exista.

La segunda disciplina son las etiquetas de estado. A cada elemento se le marca con una de cuatro cosas:

Todo lo que sigue es una instantánea del 2026-08-23 del tablero de trabajo en vivo, salvo que se nombre un comprobante del repositorio. Esa fecha importa. Una etiqueta de estado sin una fecha de referencia es cómo funciones a medio construir se convierten calladamente en «lanzadas» en textos de marketing. El argumento completo, con el extracto del tablero, está en la sección de hoja de ruta del libro blanco.

Qué está en vivo: el sustrato de coordinación

Tres de los once elementos ya son estructurales.

Ledger operacional temporal (en vivo). BRN-002 está terminado al 100%. Esta es la memoria de registro del cerebro: clases de autoridad, vínculos de evidencia y consultas a una fecha determinada. El significado práctico es que el sistema puede responder «qué sabíamos, y quién tenía permiso para decidir, a fecha del martes pasado» — no solo cuál es el estado más reciente. Para un fundador, esta es la diferencia entre un enjambre de agentes con memoria institucional y uno que vuelve a litigar decisiones ya tomadas en cada sesión.

Perfiles de capacidad de agentes verificados (en vivo). EGA-001 está terminado al 100%, 16/16, y AAV-001 está terminado al 100%, 8/8. El trabajo se enruta según capacidad demostrada y verificada, no según qué agente estaba libre en ese momento. Esta es la capa de enrutamiento que permite que agentes especializados — modelos locales, modelos en la nube, harnesses distintos — compartan una sola cola sin que el más débil termine tomando calladamente la tarea más difícil.

Gobernanza de red de agentes (en vivo localmente). EGD-002 está terminado al 100%, 12/12 y aprobado en revisión. La membresía, la delegación, la revocación y la repetición se gobiernan por encima de la instalación de tuberías cruda de MCP/A2A. El calificador honesto: esto es el sustrato local. La membresía entre redes — los agentes de una organización delegando en la red de otra bajo contrato — permanece con estado Planeado, y la etiquetamos así porque no está construida.

Sobre esos tres se apoya el 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%. Siete elementos en el tablero, cada uno con prueba binaria detrás.

Qué está en curso: identidad, lenguajes, confianza

Contratos de identidad unificados (en curso). Un solo modelo de principal a través de herramientas, agentes, runners, trabajo y evidencia. TEN-001 está al 78% y MTC-001 está al 81% en revisión. Lo que ya está entregado como comprobante del repositorio: principales de sesión, evaluación de permisos contra política versionada, cuotas de gateway y alcances de escritura por principal, y auditoría estampada por principal. Lo que no está entregado: el endurecimiento de principales externos. La etiqueta permanece En curso hasta que se pueda admitir y contener a un principal externo con el mismo rigor que a uno interno.

Verificación agnóstica de lenguaje (en curso donde está implementada, planeada donde no). El objetivo es un solo sobre de evidencia canónico por ecosistema, de modo que «pipeline verificado en verde» signifique la misma evidencia firmada, ya sea que el cambio venga de un servicio en Node o de un binario en Rust. Hoy Node/TypeScript es lo más sólido, los componentes de Java y C++ están construidos, y los perfiles de conformidad de C y Ada existen solo como especificación. El 2026-08-19 se construyeron y catalogaron las imágenes de la flota de CI de Python, Go y Rust, con autopruebas integradas en la imagen — un comprobante del repositorio — pero sus perfiles de conformidad siguen sin construirse. Las imágenes construidas no son perfiles verificados, y la hoja de ruta lo dice así.

Superficies de confianza empresarial (en curso). RBAC, tenencia, recuperación y exportación de auditoría, con seguimiento en TEN-001 al 78%. La tenencia concurrente de operadores está En vivo — hoy varios operadores pueden trabajar contra la misma instalación. El endurecimiento de principales externos es la misma brecha que el elemento uno, indicada dos veces porque bloquea a ambos.

Bucles de acción comercial cerrados (en curso). Ejecución idempotente y aprendizaje de resultados, de modo que una acción comercial — un cambio de campaña, un ajuste de precio — es tan recuperable y auditable como un cambio de código. Aquí es donde la evidencia de ingeniería empieza a conectarse con las decisiones de ingresos, y está deliberadamente por detrás de la capa de verificación en madurez.

Incorporación de proveedores como pipeline gobernado (ejemplo funcional en vivo, generalización en curso). La secuencia es fija: 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. El sexto descriptor de proveedor llegó exactamente a través de esta secuencia el 2026-08-23. Generalizar ese ejemplo funcional en un pipeline repetible está en revisión.

Qué está bloqueado o planeado — y por qué ese es precisamente el punto

Dos elementos les importan más a los lectores escépticos precisamente porque no están en vivo.

Puesta en escena supervisada de autopilot (no habilitado). La tarjeta base APX-001 está terminada; la continuación está En curso al 74%. La capacidad existe pero permanece detrás de criterios de entrada y salida medibles — un humano decide cuándo avanza la puesta en escena, contra números, no contra sensaciones. Esto es autonomía por niveles de riesgo aplicada a la propia hoja de ruta: una capacidad no se habilita porque esté construida; se habilita porque su puerta de control se superó. La automatización con control humano es una característica del diseño, no una confesión.

Autoridad de Git en capas, ganada por clase de tarea (planeado). Un agente gana una autoridad de escritura más amplia demostrándola, clase de tarea por clase de tarea. No hay nada construido, y no vamos a fingir lo contrario — pero su condición de salida falsable ya existe: concesiones de autoridad delimitadas por clase, revocables, con la decisión de concesión misma en el registro de evidencia.

Maduración del bucle de reparación (bucle en vivo, maduración planeada). El bucle de reparación funciona hoy — el bucle de desarrollo con evidencia como puerta ya repara los fallos de CI elegibles sin debilitar las puertas de control. Lo que está planeado es la capa de maduración: una taxonomía de fallos, confianza calibrada en cada reparación, y reverificación independiente para que el sistema que propuso la corrección no sea el sistema que la aprueba.

El comprobante, incluida la parte que no pasó

Un tablero honesto tiene que mostrar el elemento inconcluso junto a los terminados. DSK-001 está al 63% y 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 — un comprobante del repositorio, aunque el analizador del registro todavía no los ha ingerido, así que el tablero sigue mostrando el número antiguo. Y el matiz se mantiene: el instalador sigue sin firmar, y la validación de humo en máquina limpia no se ha ejecutado. Eso no es una aceptación de producción completada, y la hoja de ruta lo dice en el mismo aliento que los siete elementos terminados.

Esta es la misma postura que nuestro informe de limitaciones y estado: la brecha entre «el código existe» y «la puerta de aceptación se superó» es donde la confianza se gana o se pierde. Un proveedor que te muestra un tablero 100% en verde, o está temprano, o está mintiendo.

La conclusión

El dolor planteado al inicio — escalar una empresa AI-first sin escalar la plantilla al mismo ritmo — no se resuelve automatizando más. Se resuelve sabiendo, con prueba binaria, exactamente qué criterios se ha ganado el sistema el derecho de aplicar, y cuáles todavía te pertenecen a ti. La hoja de ruta de Koinessa son once direcciones con condiciones de salida falsables, cuatro etiquetas de estado honestas, una instantánea fechada, y un comprobante de tablero en vivo que muestra siete elementos terminados al 100% junto al que no lo está. Cuando la puesta en escena de autopilot se habilite, cuando los principales externos se endurezcan, cuando la autoridad de Git empiece a ganarse por clase de tarea — cada uno será un evento fechado y binario, no un comunicado de prensa. Lee los once elementos completos, sus criterios de aceptación y el extracto del tablero en el libro blanco del cerebro de Koinessa, y juzga la hoja de ruta de la forma en que fue escrita para ser juzgada: por lo que está dispuesta a fallar.