El instrumental de sistemas distribuidos que heredan los agentes de IA
Añadiste un segundo agente de codificación con IA, y luego un tercero. En una semana tenías el modo de fallo del que nadie te advierte: dos sesiones editando el mismo archivo al mismo tiempo, un agente sobrescribiendo el trabajo terminado de otro, un traspaso que se evaporó cuando una sesión murió a mitad de tarea. Los modelos, individualmente, están bien. El sistema que los rodea no tiene disciplina de coordinación — y la solución no es un modelo más inteligente. Es un instrumental que los ingenieros de sistemas distribuidos ensamblaron entre 1987 y 2016, aplicado exactamente una vez, correctamente, al enjambre.
Este artículo amplía la sección 2 del libro blanco de Koinessa — el argumento, en resumen, de que los sistemas de agentes heredan todos los modos de fallo clásicos de los sistemas distribuidos, y de que los controles clásicos ya existen. Para cada mecanismo, cubrimos lo que el trabajo original realmente estableció, y luego cómo lo aplica Koinessa al trabajo multiagente. Esto es parte de una serie en curso; la introducción de la serie enmarca el problema de verificación que alimenta esta capa de coordinación.
El fallo parcial es la línea base, no la excepción
La postura del libro blanco es directa: trata a cada agente como un trabajador que puede ser lento, estar obsoleto, estar duplicado, ser interrumpido o estar equivocado. Una sesión muere después de modificar archivos pero antes de reportar. Una llamada a una herramienta agota su tiempo de espera después de haber tenido éxito. Dos trabajadores creen genuinamente que son dueños del mismo recurso. Ninguno de estos es un error de modelo — son la física ordinaria de los procesos concurrentes, y ninguna cantidad de inteligencia del modelo sustituye a las comprobaciones estructurales. Seis mecanismos cargan con el peso: concesiones, fencing tokens, claves de idempotencia, buzones de salida transaccionales, sagas y bucles de reconciliación.
Concesiones: autoridad que expira en lugar de generar interbloqueos
Cary Gray y David Cheriton presentaron las concesiones (leases) en SOSP 1989, en «Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency». Su problema era el cacheo distribuido de archivos; su idea se generaliza: otorga autoridad por un tiempo acotado, y un titular caído libera esa autoridad con solo no hacer nada. Un lock en manos de un proceso muerto es un interbloqueo. Una concesión en manos de un proceso muerto es una espera corta.
Aplicado a agentes: un elemento de trabajo en el tablero se mantiene bajo una concesión con latidos para la vivacidad. Si la sesión se estanca — una compactación de contexto que salió mal, una CLI que colapsó, una laptop que se cerró — la concesión expira y el elemento vuelve al tablero para otro trabajador. Nadie abre un ticket para forzar un lock que está en un proceso muerto.
Fencing tokens: la autoridad obsoleta nunca debe convertirse en autoridad vigente
El artículo de 2016 de Martin Kleppmann «How to do distributed locking» — escrito como una crítica al algoritmo Redlock de Redis — convirtió a los fencing tokens en el acompañante estándar de las concesiones. La solución que describe es simple: el servicio de locks emite un token estrictamente creciente con cada adquisición, y el recurso protegido rechaza cualquier escritura cuyo token sea menor que el más alto que ya ha visto. Las concesiones por sí solas no son suficientes, porque un proceso en pausa (su ejemplo es una pausa de GC de tipo stop-the-world, pero una sesión de agente estancada califica de forma idéntica) puede sobrevivir a su propia concesión sin saberlo.
El libro blanco detalla una vez el accidente canónico de enjambre de agentes, porque es el que corrompe el trabajo en silencio. El Agente A toma la concesión número 41 sobre un elemento de trabajo y se estanca. La concesión expira; el Agente B toma la concesión 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. En Koinessa esto es maquinaria en vivo: los reclamos de archivo cooperativos más las concesiones de elementos de trabajo con fencing significan que un agente que despierta tarde descubre que su autoridad caducó en el momento de escribir, no en un conflicto de merge tres commits después.
Claves de idempotencia: reintentos que no pueden ejecutarse por duplicado
Una llamada a una herramienta que agota su tiempo de espera después de haber tenido éxito es la ambigüedad más desagradable en el trabajo agéntico — ¿se registró el cargo, se envió el mensaje, se aplicó la migración? El diseño de solicitudes idempotentes de Stripe es la respuesta de referencia: el cliente adjunta una clave única a una solicitud, y el servidor guarda el código de estado y el cuerpo resultantes de la primera solicitud hecha con esa clave — ya sea que haya tenido éxito o fallado, incluyendo errores 500. Las solicitudes posteriores con la misma clave devuelven el mismo resultado almacenado en lugar de ejecutarse de nuevo. Las claves tienen hasta 255 caracteres, Stripe sugiere UUID V4, y las claves se eliminan una vez que tienen al menos 24 horas de antigüedad.
Para las acciones de agentes, la regla se convierte en: todo lo consecuente lleva una clave de idempotencia duradera generada antes del primer intento. Reintentar después de un tiempo de espera agotado es entonces seguro por construcción — el sistema reproduce el resultado registrado en lugar de realizar la acción dos veces. Esto es lo que convierte «la sesión murió; vuelve a ejecutarla» de un 50/50 en un procedimiento.
El buzón de salida transaccional: intención duradera antes de la ejecución
El patrón de buzón de salida transaccional de Chris Richardson aborda una división más sutil: un servicio debe actualizar su base de datos y emitir un mensaje, y hacer uno sin el otro (fallar después del commit, antes del envío) deja el estado y la notificación permanentemente divergidos. El patrón escribe el mensaje saliente en una tabla de buzón de salida dentro de la misma transacción local que la actualización de la entidad de negocio; un relay separado luego publica desde el buzón de salida. Los mensajes tienen garantizado su envío si y solo si la transacción hace commit — y, como señala Richardson, los consumidores todavía necesitan idempotencia, porque el relay puede entregar más de una vez. Los patrones se componen; no se sustituyen entre sí.
Para los agentes, la correspondencia es directa: registra la intención — el reclamo de archivo, la transición de estado del elemento de trabajo, la escritura de evidencia — en la misma transacción que el cambio de estado que describe. Una sesión que muere después de hacer commit pero antes de anunciarlo no ha perdido el traspaso; el relay lo lleva. La intención es duradera antes de que comience la ejecución.
Sagas: compensación para trabajo que cruza límites irreversibles
Hector Garcia-Molina y Kenneth Salem presentaron las sagas en SIGMOD 1987, en «Sagas». Su observación: las transacciones de larga duración no pueden mantener locks durante toda su duración sin estrangular la concurrencia, así que hay que descomponerlas en una secuencia de transacciones locales, cada una emparejada con una acción compensatoria. Si un paso falla, ejecuta las compensaciones en orden inverso en lugar de abortar un lock global o dejar un estado aplicado a medias.
Las tareas largas de agentes — una ejecución de requisitos multi-historia, una migración que toca decenas de archivos — son exactamente transacciones de larga duración. Cada historia completada es duradera por sí sola; un fallo a mitad de camino dispara la compensación de los pasos que no pueden sostenerse solos, en lugar de dejar varado el repositorio en un estado que ninguna sesión recuerda haber creado.
Controladores: declarar el estado deseado y reconciliar
Kubernetes reemplazó «ejecuta esto y espera lo mejor» con el bucle de control: declara el estado deseado, observa el estado real, actúa para reducir la diferencia, repite. El libro blanco aplica la misma forma al trabajo agéntico. Un documento de requisitos declara resultados; los elementos de trabajo vinculan obligaciones; los perfiles de verificación declaran las comprobaciones requeridas; los esquemas de evidencia declaran la prueba que debe existir. El controlador entonces compara 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 siente que terminó. La autonomía vaga se convierte en convergencia medible, que es también la premisa detrás del bucle de Evidence-Gated Agentic Development en otra parte de esta serie.
La reconciliación también aporta el regulador que faltaba para el rendimiento de los agentes: la contrapresión. Cuando un sistema aguas abajo se ralentiza o falla, los controladores reducen el trabajo, lo ponen en cola o se detienen — mientras que la automatización ingenua convierte una pequeña interrupción en una avalancha de reintentos y acciones duplicadas. Una vez que cada operación lleva una identidad duradera desde la intención hasta el resultado, la confiabilidad se vuelve computable por agente, modelo, clase de tarea y repositorio — y la selección de modelo deja de ser preferencia de marca y se convierte en una pregunta de evidencia.
Lo que Koinessa ejecuta hoy
Estos mecanismos están en vivo, no son aspiracionales. El registro de sesiones, los reclamos de archivo cooperativos y las concesiones de elementos de trabajo con fencing permiten que trabajadores interactivos de seis proveedores — Kimi, Claude, Grok, Codex, Ollama local y Ollama Cloud — compartan un solo tablero. Un séptimo proveedor, Devin, está registrado como el sexto descriptor de proveedor y permanece deshabilitado detrás de una salvaguarda versionada. El registro de sesiones contiene 209 sesiones registradas, 208 de ellas desde el 1 de agosto.
El libro blanco es igual de específico sobre los límites de medición, y estos importan para la credibilidad. Una etiqueta de proveedor se captura solo en una minoría de las filas de sesión — 8 de 209 en esta instantánea — así que la atribución por proveedor descansa en los trailers de commit, que registran 18 identidades de trabajador distintas desde el 1 de julio y no son universales. La instantánea de git del 2026-08-23 contiene 100 commits en la rama principal del 19 al 23 de agosto, 691 del 5 al 23 de agosto, y un pico de 84 el 13 de agosto. Dos operadores humanos en estaciones de trabajo LAN separadas pueden — y de hecho lo hacen — dirigir enjambres independientes contra el mismo repositorio a través del mismo plano de coordinación. Eso es tenencia de operadores concurrentes sobre un solo cerebro compartido, y es evidencia operativa de un sistema, no un benchmark controlado.
El comprobante del 2026-08-12: un enjambre multiproveedor en un solo tablero
Un comprobante de repositorio muestra el instrumental bajo carga. El 2026-08-12, una sola 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í.
La medición externa mantiene esto honesto sobre lo que ocurre sin coordinación: un estudio de 2026 sobre pull requests agénticos encontró que solo el 0.5% de los pares co-activos involucraba a agentes distintos — es decir, el 0.5% de los pares co-activos, no de los pull requests — y en una muestra de reproducción, los conflictos textuales de Git fueron del 41.7% frente al 19.8% para la población entre agentes distintos; esos son conflictos textuales, no semánticos (arXiv). Las colisiones entre trabajadores no coordinados son la norma. Los mecanismos de arriba son cómo un sistema las convierte en la excepción.
Conclusión
El trabajo duplicado, los cambios sobrescritos y los traspasos perdidos no son problemas de IA — son los fallos clásicos de los sistemas distribuidos, y tienen soluciones clásicas. Las concesiones acotan la autoridad en el tiempo. Los fencing tokens aseguran que la autoridad obsoleta nunca se convierta en autoridad vigente. Las claves de idempotencia hacen que los reintentos sean seguros. El buzón de salida hace que la intención sea duradera antes de la ejecución. Las sagas hacen que las tareas largas sean recuperables mediante compensación. Los controladores reconcilian el estado declarado contra el estado observado y aplican contrapresión cuando el sistema aguas abajo se ralentiza. Koinessa ejecuta los seis como maquinaria de coordinación en vivo sobre cómputo controlado por el cliente, así que un enjambre en paralelo produce un pipeline verificado en verde en lugar de un conflicto de merge. El argumento completo — con los datos de instantánea, las etiquetas de capacidad y todas las citas anteriores — está en el libro blanco de Koinessa. Para el marco más amplio sobre por qué se eligieron estas lecciones, ve Siete lecciones de cincuenta años de sistemas.