Actualidad tecnológica · Revisión: 25 de octubre de 2026
Microsoft ha abierto el código de Agensh, un sistema de investigación para coordinar equipos de agentes de inteligencia artificial sin un director central. El repositorio fecha la apertura el 24 de octubre, una novedad distinta del preprint publicado en septiembre. El número que más llama la atención es 1.024 agentes, pero el interés del trabajo está en cómo reparten tareas, comparten hallazgos y combinan cambios. Sus resultados no significan que multiplicar agentes multiplique automáticamente la calidad.
La novedad es la apertura del sistema
La publicación permite examinar la infraestructura, los lanzadores de experimentos y una guía de reproducción. No es simplemente un vídeo con muchos asistentes trabajando. El valor de abrir una investigación es que otros equipos pueden revisar sus condiciones, identificar dependencias y comprobar qué parte de los resultados logran reproducir. El código se presenta con licencia MIT.
El punto de partida sigue siendo experimental. Un repositorio público no implica que exista una aplicación lista para cualquier empresa, ni que se pueda ejecutar un equipo de ese tamaño en un ordenador corriente. Antes de pensar en adopción hay que entender sus requisitos, el coste de los modelos y los servicios auxiliares que necesita la coordinación.
Qué hace un agente y qué hace el equipo
Un agente de programación recibe contexto, propone acciones, utiliza herramientas y comprueba resultados. Si varios trabajan sobre el mismo objetivo, aparece un problema adicional: dos pueden modificar el mismo archivo, resolver la misma tarea o interpretar de forma incompatible una decisión previa. La capacidad individual del modelo no elimina esas dificultades de organización.
Agensh estudia una cooperación asíncrona. Cada trabajador descubre o reclama subtareas, comparte información y aporta cambios al trabajo común. El sistema busca que la especialización y la coordinación emerjan de la interacción del grupo, en lugar de depender de un único coordinador que asigne y supervise todo. Esa arquitectura distribuye decisiones, pero también hace necesario mantener un estado compartido comprensible.
Un repositorio y una conversación como infraestructura
El proyecto conecta un espacio de trabajo compartido, mensajería y mecanismos de contexto. Utiliza Gitea para el trabajo sobre código y Mattermost para los intercambios entre agentes. La idea resulta cercana a un equipo humano: un lugar donde viven los cambios y otro donde se discuten problemas, acuerdos y hallazgos.
La comparación tiene límites. Un programa puede producir mensajes con rapidez, pero eso no garantiza que otro los lea en el momento adecuado o que los interprete correctamente. También puede comunicar una conclusión antes de haberla verificado. Por eso el diseño de un equipo de agentes necesita algo más que abrir muchos canales: debe hacer que la información útil llegue y que el progreso tenga pruebas.
Cómo leer las cifras sin confundir los experimentos
El repositorio describe evaluaciones con presupuesto de seis horas y sin acceso a internet. En una de sus comparaciones, la media de pruebas superadas en cinco tareas pasa de 19,31 % con un agente a 28,78 % con 128. La diferencia es 9,47 puntos porcentuales; el incremento relativo se aproxima al 49 %. Ambas formas describen la misma comparación, pero no comunican lo mismo.
Para la tarea Pandoc se publican otras configuraciones, incluidas pruebas con equipos de 1.024 agentes. Esos resultados no deben mezclarse con las medias de cinco tareas ni con los de modelos diferentes. Un titular que reúna el mayor equipo, la mejor cifra y el modelo más reciente podría construir una comparación que el estudio no realizó.
Las métricas cuentan pruebas superadas dentro de un banco de evaluación concreto. No equivalen a un porcentaje universal de tareas profesionales resueltas, ni miden por sí solas mantenibilidad, seguridad o satisfacción de un usuario. La forma responsable de leerlas es conservar juntas la tarea, el modelo, el número de agentes y el tiempo concedido.
Por qué más trabajadores pueden ayudar
En programación existen actividades que admiten exploración paralela. Distintos agentes podrían investigar módulos separados, formular hipótesis sobre un error o crear pruebas complementarias. Si esas ramas de trabajo terminan aportando información independiente y útil, el equipo puede encontrar una solución antes o cubrir más casos dentro de un plazo limitado.
Ese beneficio depende del problema. Dividir un trabajo mal entendido puede multiplicar suposiciones equivocadas. También es posible que varios agentes se apoyen en la misma interpretación incorrecta y produzcan resultados parecidos. El paralelismo resulta más útil cuando hay objetivos comprobables, interfaces claras y una forma de contrastar las aportaciones antes de integrarlas.
El coste que una cifra de agentes no muestra
La cantidad de trabajadores no basta para calcular cuánto cuesta una ejecución. Importan la duración, el modelo, las llamadas a herramientas, el contexto que cada uno procesa y el tiempo dedicado a corregir conflictos. Una tarea puede resolverse más deprisa en tiempo de reloj y, aun así, consumir más recursos totales.
Para una organización, la pregunta útil sería cuánto cuesta obtener un resultado aceptado. Ese resultado debe incluir pruebas y revisión, no solo un cambio de código. Si un grupo genera diez propuestas que después deben descartarse, el número de propuestas no es una medida suficiente de productividad. La investigación abre una vía para estudiar esos compromisos; no elimina la necesidad de medirlos en cada caso.
Coordinar también significa evitar interferencias
Un espacio de trabajo compartido puede ser una ventaja y una fuente de errores. Si un agente cambia una interfaz mientras otro escribe contra la versión anterior, ambos pueden avanzar individualmente y terminar con un conjunto que no funciona. La integración exige comprobar el resultado combinado, algo distinto de verificar cada contribución por separado.
En una prueba pequeña, una persona podría detectar el desacuerdo al revisar unos pocos archivos. En un grupo grande, la cantidad de comunicaciones y cambios vuelve esa revisión mucho más difícil. El diseño del sistema debe ayudar a reconocer tareas duplicadas, decisiones obsoletas y dependencias que cambian. Este tipo de trabajo organizativo es parte central del problema, no un detalle que se resuelva añadiendo más potencia.
La seguridad depende de los permisos efectivos
Un equipo descentralizado no debería recibir acceso ilimitado solo porque sus miembros compartan un objetivo. Los permisos sobre archivos, servicios y credenciales siguen siendo relevantes. El hecho de que los experimentos descritos no tengan acceso a internet es una condición importante: no se puede trasladar el resultado directamente a agentes conectados a herramientas empresariales y sistemas externos.
En una evaluación real convendría separar acciones de lectura, cambios reversibles y operaciones con efectos externos. También registrar qué hizo cada trabajador y qué evidencia justificó la integración de su resultado. Estas son consideraciones de despliegue, no afirmaciones de que Agensh haya resuelto por completo todos esos controles. Un buen resultado en programación no certifica por sí mismo la seguridad operativa.
Qué puede aprender quien no vaya a usar 1.024 agentes
La noticia también sirve para equipos que trabajan con pocos asistentes. Un objetivo claro, una lista compartida de tareas y pruebas reproducibles pueden aportar más que aumentar indiscriminadamente el número de participantes. Antes de crear otro agente, merece la pena identificar qué incertidumbre concreta resolverá y cómo se comprobará su contribución.
Un ejemplo sería separar la investigación de un fallo de la revisión del parche. Son trabajos relacionados, pero pueden beneficiarse de perspectivas distintas si ambos tienen acceso al contexto necesario. En cambio, pedir a varios asistentes que editen simultáneamente el mismo archivo sin acuerdo sobre la interfaz puede aumentar el trabajo de integración.
Lo que habrá que comprobar después
La apertura facilita que aparezcan reproducciones independientes, comparaciones de coste y experiencias con tareas distintas. Esas pruebas permitirán saber cuánto dependen los resultados del banco utilizado y qué partes del sistema son transferibles. También será importante comprobar cómo cambia el comportamiento al sustituir el modelo o reducir el presupuesto.
Por ahora, la aportación es una plataforma abierta para estudiar organización entre agentes y un conjunto de resultados bajo condiciones identificables. El número 1.024 demuestra la escala que los autores han explorado; la utilidad fuera de ese experimento tendrá que establecerse con resultados completos, costes y revisión de calidad.
Fuentes y comprobación
Texto original. Los hechos del anuncio se distinguen del contexto y la interpretación editorial. Ilustración conceptual propia generada con IA; no es una fotografía del suceso.