El costo es el piso, el control es el multiplicador

2026-08-30 · Práctica de ingeniería · Kris Christopher

Llevas dos productos en marcha, tres repositorios de profundidad, y el número de agentes sigue subiendo. Hay una cola de PRD en una máquina, un enjambre explorador en otra, y una rama de migración que nadie recuerda haber autorizado. La pregunta difícil ya no es si los agentes pueden escribir el código. Es si puedes responder, bajo demanda y con prueba: qué se hizo, qué trabajador lo hizo, bajo la autoridad de quién, y por qué se permitió. Gestionar múltiples productos, repositorios, agentes y PRD se ha vuelto operativamente abrumador — y ese agobio no es un fallo de disciplina personal. Así se siente, desde adentro, el rendimiento sin gobernanza.

Este artículo amplía la sección 8 del libro blanco del cerebro de Koinessa, Valor de negocio III — mejor y más rápido, que expresa la tesis del argumento en una línea: el costo es el piso; el control es el multiplicador.

El costo es el piso, el control es el multiplicador

El argumento de costos a favor de la entrega agéntica local-first es real — telemetría de tokens con predominio de lecturas de caché, cómputo controlado por el cliente, sin caseta de peaje de SaaS por asiento sobre tu inferencia — y un artículo hermano, la ventaja de costos de la entrega local-first, recorre esos números. Pero los tokens más baratos son solo la apuesta mínima para entrar al juego. Una operación 30% más barata que no puedes rastrear sigue siendo una operación que no puedes rastrear. Lo que multiplica el valor de la velocidad agéntica es el control: la capacidad de aumentar cuánto trabajo hacen los agentes de forma autónoma sin perder la respuesta a «qué pasó, y quién lo permitió». La sección 8 del libro blanco descompone ese control en propiedades concretas y verificables individualmente. Esto es lo que cada una realmente es.

Procedencia: una cadena desde la intención hasta el despliegue

La primera propiedad ya está en vivo hoy: cada acción consecuente en el sistema lleva una cadena de procedencia 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. Un libro mayor temporal hace que «qué creíamos cuando esto se autorizó» sea respondible como una consulta, no como un proyecto de arqueología.

Esto importa porque el agobio del párrafo inicial es, en su mayor parte, un problema de registros faltantes. Cuando un cliente, un inversionista o un revisor de seguridad pregunta por qué se lanzó un cambio, la respuesta honesta en la mayoría de las configuraciones agénticas es «alguien tendría que reconstruir eso a partir de transcripciones de chat». La postura del libro blanco es que la gobernanza no es una presentación de diapositivas; es una tabla que puedes auditar. La procedencia es lo que convierte «confía en mí, los agentes son cuidadosos» en evidencia firmada con un historial consultable — lo cual también es la base sobre la que se construye el modelo de autonomía por niveles de riesgo: no puedes elevar con seguridad un nivel de autonomía si primero no puedes probar qué hizo el nivel inferior.

Identidad, separada de la misma forma en que la separa IAM

La segunda propiedad, también en vivo, es la identidad. Koinessa separa la identidad de la misma forma en que lo hacen 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. Los permisos se evalúan contra una política versionada con decisiones persistidas, no contra texto de prompt; las cuotas y los alcances de escritura se asignan por principal y por tabla; y los libros mayores de auditoría y de eventos estampan el principal actuante en cada entrada.

Dos anclas externas explican por qué este diseño es como es. El modelo de políticas sigue a Open Policy Agent, el motor de políticas de propósito general graduado por la CNCF cuya idea central es desacoplar la decisión de política del software que la hace cumplir, de modo que la política sea código versionado y revisable en lugar de comportamiento disperso entre manejadores. El modelo de confianza sigue NIST SP 800-207, Zero Trust Architecture (Rose, Borchert, Mitchell, Connelly, agosto de 2020), que define la confianza cero como no otorgar confianza implícita a activos o cuentas según la ubicación de red o la propiedad — la autenticación y la autorización son funciones discretas que se realizan antes de que se establezca cualquier sesión. Koinessa aplica esa doctrina internamente, a su propia LAN: una conexión de red no otorga confianza implícita, las lecturas mismas quedan identificadas por portador en cualquier enlace que no sea loopback, y un trabajador puede ser capaz de alcanzar un recurso aunque le falte la autoridad de política para usarlo. Ambos hechos se comprueban por separado.

Para un fundador, la traducción práctica es que «lo hizo el agente» deja de ser una explicación válida para cualquier cosa. Cada actor — humano, sesión de agente, proveedor — es un principal distinto con autoridad distinta, y cada permiso otorgado es una decisión persistida que puedes revisar después del hecho.

Tres propiedades de tenencia, tres límites de evidencia

«Multiinquilino» normalmente se comercializa como una sola promesa. La sección 8.3 del libro blanco lo divide en tres propiedades con límites de evidencia distintos, y mantiene honestas sus etiquetas de capacidad:

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 un gateway de escritor único donde se hacen cumplir la identidad y el alcance. Pero el paper explícitamente no infiere aislamiento universal de inquilinos a partir de una propiedad parcial del esquema: los elementos de trabajo de endurecimiento de inquilinos TEN-001 y MTC-001 están en 78% (en curso) y 81% (en revisión) respectivamente, y el endurecimiento de principales externos sigue incompleto. Ese matiz es precisamente el punto — la afirmación es exactamente tan fuerte como la evidencia.

2. Tenencia de operadores concurrentes — En vivo. Dos personas trabajan habitualmente al mismo tiempo en el mismo repositorio desde dos PC distintas en la misma red 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 lo hace seguro — al plano de coordinación no le importa qué humano, qué proveedor o qué caja física ocupa un trabajador. Si eres el fundador sobrecargado del párrafo inicial, esta es la propiedad que compra un equipo más grande cuando compra el plano de control: no la promesa de que se pueden 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, con neutralidad más amplia en 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 — el modelo documentado de Ollama para delegar la ejecución a su servicio en la nube mientras quienes lo invocan siguen usando las interfaces de Ollama, con un modo solo local disponible. Un séptimo proveedor, Devin, está registrado como descriptor y deshabilitado. 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 no está habilitada, sin ningún descriptor activo. Un cambio de proveedor es una meta de diseño interna, no una neutralidad probada externamente.

La consecuencia de cara al comprador: 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 bajo un modelo de resultados de seis estados — y no se afirman como una promesa contractual.

El comprobante del 2026-08-12: un día en un tablero de 266 tarjetas

Las afirmaciones de control necesitan comprobantes. El más claro del libro blanco es un comprobante de un solo repositorio del 2026-08-12: una sesión orquestadora escaneó el entonces tablero de trabajo de 266 tarjetas, ejecutó dos agentes exploradores en paralelo para mapear dos costuras de código, hizo que un modelo local de 27B redactara el documento de requisitos a partir de sus reportes, ejecutó dos agentes programadores en paralelo sobre flujos de trabajo disjuntos implementando cuatro historias, y luego 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í. Eso es la memoria compartida persistente haciendo el trabajo de coordinación, y es un comprobante, no un benchmark: un día registrado de una operación, presentado como prueba de existencia y no como un multiplicador de productividad.

La medición externa le da a esto una comparación acotada. Un estudio de 2026 sobre pull requests redactados por agentes (arXiv:2607.04697, usando el conjunto de datos AIDev-pop de 33,596 PR en 2,807 repositorios) encontró que solo el 0.5% de los pares co-activos — pares de PR de agentes abiertos al mismo tiempo, no el 0.5% de todos los pull requests — involucraban a dos agentes distintos, y en una muestra de reproducción de 747 pares, los conflictos textuales de Git llegaron al 41.7% en los pares entre agentes distintos frente al 19.8% en los pares del mismo agente. Esos son conflictos textuales, no semánticos, y la muestra es de un par por repositorio — pero la dirección es inequívoca: en el momento en que más de un proveedor de agentes trabaja el mismo repo, el riesgo de colisión aproximadamente se duplica. La concurrencia entre agentes distintos es exactamente el escenario que los reclamos, las concesiones y los fencing tokens de Koinessa existen para gobernar.

Por qué el mercado está pidiendo esto ahora

Dos fuentes externas más enmarcan el lado de la demanda. El programa de investigación de DORA — el informe 2025 State of AI-assisted Software Development y su seguimiento de ROI de 2026 — enmarca la IA como un amplificador de la organización que la rodea y le da al costo de una amplificación débil el nombre «impuesto de verificación»: la salida llega más rápido de lo que la organización puede confirmarla. Y Duma et al., en «These Aren't the Reviews You're Looking For» (EASE 2026), encontraron que los pull requests agénticos tienden a sustituir la revisión humana en lugar de escalarla — los revisores cambian lo que hacen cuando el autor es un agente, de maneras que no añaden escrutinio proporcionalmente. Juntando todo: la velocidad de generación no es el cuello de botella, la capacidad de revisión no se estira para cubrirla, y la brecha cae sobre quien sea dueño del release. Esa persona eres tú.

Para quién está construido esto

La sección 8.8 es directa sobre el cliente al que apunta: 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, qué trabajador lo hizo, bajo la autoridad de quién, y con qué prueba. Los controles existen para que un equipo así pueda elevar los niveles de autonomía a través de muchos desarrolladores sin perder esa respuesta, y para que los paquetes de evidencia correspondan con las expectativas de garantía ya establecidas: el NIST AI Risk Management Framework y su Generative AI Profile (AI RMF 1.0 y AI 600-1), y el Secure Software Development Framework (SP 800-218 v1.1 más SP 800-218A, el perfil comunitario de IA generativa, final de 2024). Estos son marcos voluntarios, no certificaciones — la afirmación es que la procedencia, la política como código y la auditoría por principal producen el tipo de artefactos que esos marcos piden, no que se haya ganado alguna insignia.

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. Y el paper se sostiene a sí mismo según su propio estándar: una evaluación externa deliberadamente escéptica del 2026-08-13 verificó las citas, etiquetó los supuestos de planeación como supuestos, rechazó cualquier multiplicador de productividad de tarea completa, y encontró que el problema de fondo era real — dejando, eso sí, una condición sin cumplir: terminar el sustrato de confianza antes de pedirles a las organizaciones sensibles a la confianza que confíen en él. Ese sustrato desde entonces se cerró, y sus sucesores se sostienen al mismo estándar.

La conclusión

El agobio de gestionar muchos productos, repositorios, agentes y PRD no se resuelve con agentes más rápidos ni tokens más baratos — se resuelve haciendo que cada acción sea atribuible, cada autoridad sea explícita, cada afirmación de tenencia esté evidenciada, y cada puerta de aceptación sea fail-closed. El costo es el piso; el control es el multiplicador, y el control solo es real cuando es consultable. La postura de Koinessa es que nunca deberías tener que aceptar nada de eso por fe: la cadena de procedencia, el modelo de identidad y los comprobantes de enjambre son hechos operativos con fechas de instantánea y matices adjuntos. El argumento completo, con cada número, matiz y cita en contexto, está en el libro blanco del cerebro de Koinessa — la sección 8 es donde vive el caso de negocio para el control.