Agentes de IA coordinados dentro de tu repositorio: cómo Squad está cambiando las reglas del juego
Los agentes de IA se convirtieron en compañeros de código para mucha gente, pero quienes ya los usaron saben cómo funciona la cosa en la práctica.
Escribís un prompt, el modelo entiende la mitad, refinás, ajustás, y al final terminás pasando más tiempo conduciendo a la IA que realmente construyendo software. Parece productivo al principio, pero a medida que el proyecto crece, esa dinámica empieza a pesar. Cada ajuste manual que hacés es tiempo que podrías estar dedicando a decisiones más estratégicas, a arquitectura, a experiencia de usuario, a calidad real de entrega.
Eso funciona hasta cierto punto, pero cuando el proyecto empieza a escalar, la pregunta cambia. Ya no es cómo escribo un buen prompt, sino cómo logro coordinar diseño, implementación, pruebas y revisión sin perder el hilo en el camino. El problema deja de ser técnico y pasa a ser organizacional, y es exactamente ahí donde la mayoría de las herramientas actuales muestra sus limitaciones.
La orquestación multi-agente aparece como una respuesta natural a ese problema, solo que siempre vino con un precio alto: horas de configuración, capas de infraestructura, bases de datos vectoriales, frameworks complejos, todo eso antes de delegar una sola tarea. Quien ya intentó montar un sistema así sabe que la fricción es real y que muchas veces el esfuerzo de setup supera el beneficio que esperabas tener desde el inicio.
Es ahí donde Squad entra con una propuesta diferente. El proyecto es open source, corre sobre GitHub Copilot y pone un equipo de IA especializado dentro de tu repositorio, sin necesidad de montar nada pesado por debajo. Dos comandos y ya tenés un equipo formado por un agente líder, un desarrollador frontend, uno backend y un tester listos para trabajar junto con vos. Así de simple. 🚀
Qué es Squad y cómo funciona en la práctica
Squad es un framework open source de desarrollo colaborativo con agentes de IA que fue pensado para eliminar la complejidad de entrada que normalmente asusta a quienes quieren experimentar con orquestación multi-agente. En lugar de exigir que configures pipelines, instales dependencias pesadas o entiendas a fondo cómo conectar diferentes modelos entre sí, Squad funciona directamente en el entorno que ya usás: GitHub Copilot dentro de VS Code o del entorno compatible.
La instalación es absurdamente directa. Ejecutás npm install -g @bradygaster/squad-cli una única vez de forma global y después corrés squad init dentro del repositorio donde querés usarlo. Listo. Sin docker compose, sin variables de entorno interminables, sin base de datos vectorial que configurar. El equipo de agentes se inicializa ahí mismo, en el contexto de tu proyecto.
La idea central es que cada agente tiene una especialidad clara y bien definida. Existe un agente líder responsable de coordinar el flujo general, interpretar la tarea mayor y distribuir el trabajo entre los demás. Existe el agente de frontend, enfocado en componentes visuales, interfaces y experiencia de usuario. El agente de backend se encarga de la lógica, las APIs y la estructura de datos. Y el agente de pruebas garantiza que lo que se produjo realmente funcione antes de llegar a tus manos. Cada uno de esos roles existe de forma independiente, pero todos trabajan conectados dentro del mismo repositorio, lo que mantiene el contexto del proyecto preservado a lo largo de toda la ejecución.
En la práctica, el flujo empieza con vos describiendo lo que necesitás, ya sea una feature nueva, una corrección o una tarea más amplia de refactorización. El agente líder interpreta el pedido, lo divide en partes menores y delega a los especialistas correctos. Cada agente ejecuta su parte con acceso al contexto del repositorio, lo que significa que no trabajan en el vacío. Entienden la estructura del proyecto, respetan patrones ya existentes y producen código que encaja con lo que ya tenés construido, en vez de generar algo genérico que vas a necesitar adaptar manualmente después.
Cómo Squad coordina el trabajo entre los agentes
Describís el trabajo en lenguaje natural. A partir de ahí, el agente coordinador dentro de Squad entiende el ruteo necesario, carga el contexto del repositorio y activa a los especialistas con instrucciones específicas para cada tarea.
Vamos a un ejemplo concreto. Imaginá que escribís algo como: Equipo, necesito autenticación JWT con refresh tokens y bcrypt. A partir de ese pedido, Squad pone a los agentes a correr en paralelo. El especialista de backend asume la implementación de la lógica de autenticación. El agente de pruebas empieza a escribir la suite de tests correspondiente. Un especialista de documentación abre un pull request con la información relevante. En minutos, archivos se escriben y branches se crean.
Lo más interesante es que esos especialistas ya conocen las convenciones de nomenclatura de tu proyecto y saben lo que se decidió sobre conexiones de base de datos días atrás. No porque lo hayas puesto en el prompt, sino porque los agentes cargan decisiones compartidas del equipo y sus propios archivos de historial de proyecto que están commiteados en el repositorio.
Revisión independiente entre agentes
En lugar de forzarte a probar manualmente la salida y conducir al modelo por varias rondas de correcciones, Squad maneja la iteración internamente. Cuando el especialista de backend termina la implementación inicial, el agente de pruebas ejecuta su suite contra el código. Si las pruebas fallan, el tester rechaza el código.
Acá viene un detalle que hace toda la diferencia: el protocolo de revisión de Squad impide que el agente original revise su propio trabajo. Un agente diferente necesita asumir la corrección. Esto fuerza una revisión genuinamente independiente, con una ventana de contexto separada y una perspectiva fresca, en vez de pedirle a la misma IA que revise sus propios errores. En los flujos donde la automatización de revisión está habilitada, revisás el pull request que sobrevivió a ese ciclo interno, y no cada intento intermedio.
Es importante dejar claro: esto no es piloto automático. Los agentes van a hacer preguntas de aclaración y, a veces, hacer suposiciones razonables pero incorrectas. Vos seguís revisando y haciendo merge de cada pull request. Es orquestación colaborativa, no ejecución autónoma.
Por qué la orquestación multi-agente cambia las reglas del juego
Cuando trabajás con un único agente de IA, el contexto siempre es limitado. El modelo necesita entender el problema, planificar la solución, escribir el código, pensar en las pruebas y además mantener coherencia con el resto del proyecto, todo al mismo tiempo. Esto crea un cuello de botella natural, porque cualquier modelo tiene límites de atención y de profundidad. El resultado suele ser un código que funciona de forma aislada pero que no conversa bien con el resto de la base, o pruebas superficiales que no cubren los casos que realmente importan.
La orquestación multi-agente resuelve esto dividiendo las responsabilidades de forma que cada agente pueda enfocarse en una sola cosa y hacerlo muy bien. Es el mismo principio que hace funcionar a los equipos humanos: un diseñador no necesita saber escribir migraciones de base de datos, y un DBA no necesita conocer cada detalle de accesibilidad en interfaces. La especialización aumenta la calidad y la velocidad al mismo tiempo, porque cada parte del problema recibe atención dedicada de quien fue hecho para lidiar con ella.
Lo que Squad trae de nuevo en este escenario es justamente la accesibilidad de este enfoque. Antes, implementar un sistema multi-agente funcional exigía elegir un framework como AutoGen, CrewAI o LangGraph, entender cómo orquestar llamadas entre agentes, definir memoria compartida, manejar fallas y reintentos, y además integrar todo eso con tu entorno de desarrollo. Era viable, pero claramente estaba fuera del alcance de quien simplemente quería ser más productivo en el día a día. Squad comprime todo eso en una experiencia que cabe en dos comandos en la terminal.
Patrones de arquitectura detrás de la orquestación nativa de repositorio
Ya sea usando Squad o construyendo tus propios flujos multi-agente, existen algunos patrones arquitectónicos que surgieron durante el desarrollo de la orquestación nativa de repositorio. Estos patrones alejan la arquitectura del comportamiento de caja negra y la llevan hacia algo inspeccionable y predecible a nivel de repositorio.
El patrón Drop-box para memoria compartida
La mayoría de las orquestaciones de IA depende de chat en tiempo real o búsquedas complejas en bases de datos vectoriales para mantener a los agentes sincronizados. En la práctica, esto suele ser demasiado frágil. Sincronizar estado entre agentes activos en tiempo real es una tarea ingrata.
Squad usa un enfoque diferente llamado patrón drop-box. Cada decisión arquitectónica, como elegir una biblioteca específica o una convención de nomenclatura, se agrega como un bloque estructurado a un archivo decisions.md versionado en el repositorio. La apuesta es que compartir conocimiento de forma asíncrona dentro del repositorio escala mejor que la sincronización en tiempo real.
Al tratar un archivo markdown como el cerebro compartido del equipo, ganás persistencia, legibilidad y una pista de auditoría perfecta de cada decisión tomada. Como esa memoria vive en los archivos del proyecto y no en una sesión activa, el equipo también puede recuperar contexto después de desconexiones o reinicios y continuar desde donde quedó.
Replicación de contexto en lugar de división de contexto
Uno de los mayores obstáculos en el desarrollo con IA es el límite de la ventana de contexto. Cuando un único agente intenta hacer todo, la memoria de trabajo se llena con meta-gestión, lo que lleva a alucinaciones y respuestas inconsistentes.
Squad resuelve esto garantizando que el agente coordinador funcione como un router liviano. No hace el trabajo en sí, solo activa a los especialistas. Como cada especialista corre como una llamada de inferencia separada con su propia ventana de contexto amplia (hasta 200K tokens en modelos compatibles), no estás dividiendo un contexto entre cuatro agentes. Estás replicando el contexto del repositorio entre ellos.
Correr múltiples especialistas en paralelo te da múltiples contextos de razonamiento independientes operando simultáneamente. Esto permite que cada agente vea las partes relevantes del repositorio sin competir por espacio con los pensamientos de los otros agentes. En la práctica, es como tener cuatro personas mirando el mismo proyecto, cada una con foco total en su área de responsabilidad.
Memoria explícita en el prompt versus memoria implícita en los pesos
La memoria de un equipo de IA necesita ser legible y versionada. No deberías tener que adivinar lo que un agente sabe sobre tu proyecto.
En Squad, la identidad de cada agente se construye principalmente a partir de dos archivos en el repositorio: un charter (quién es) y un history (qué hizo), además de las decisiones compartidas del equipo. Estos archivos son texto puro y quedan en la carpeta .squad/ del proyecto.
Porque esa memoria vive en el repositorio junto con el código, se versiona al lado de todo lo demás. Cuando clonás un repo que usa Squad, no estás recibiendo solo el código. Estás recibiendo un equipo de IA ya integrado al proyecto, porque su memoria vive directamente en el repositorio. Es como si el onboarding de los agentes viniera incluido en el git clone. 🧠
Desarrollo colaborativo con IA dentro del repositorio
Uno de los puntos más interesantes de Squad es el hecho de que toda la colaboración sucede dentro del repositorio. Esto puede parecer un detalle técnico, pero hace una diferencia enorme en la calidad del resultado. Cuando los agentes de IA tienen acceso real a la estructura de archivos, al historial de cambios y a las convenciones ya establecidas en el proyecto, consiguen tomar decisiones mucho más alineadas con lo que realmente necesitás, en lugar de entregar soluciones genéricas desconectadas del contexto.
Este modelo de desarrollo colaborativo también cambia la relación entre el desarrollador y la IA. En vez de ser el operador que ajusta prompts hasta conseguir algo utilizable, pasás a ser el responsable de la dirección estratégica del proyecto mientras el equipo de agentes se encarga de la ejecución coordinada. Vos decidís qué construir, definís prioridades, revisás lo que se entregó y validás la calidad. Los agentes hacen el trabajo pesado de implementación, pruebas e integración. Esa división es mucho más cercana a cómo funciona un equipo humano real que el modelo tradicional de IA asistiva.
Otro aspecto relevante es que, al ser open source, Squad permite que la comunidad contribuya con nuevos agentes especializados, ajuste los comportamientos existentes y adapte el framework para contextos específicos. Esto significa que el proyecto tiene potencial de crecer en direcciones que ni los creadores originales previeron, especialmente considerando el ritmo acelerado con que el área de agentes de IA está evolucionando. Para equipos que trabajan con stacks específicos o dominios más de nicho, esa flexibilidad puede ser el diferencial que transforme a Squad de una herramienta interesante en una pieza central del flujo de trabajo.
Reduciendo la barrera de entrada para flujos multi-agente
El mayor logro de Squad hasta ahora es hacer fácil para cualquier persona empezar con desarrollo agéntico de una manera simple y sin ceremonias. La propuesta es que no deberías necesitar gastar horas peleando con infraestructura, aprendiendo ingeniería de prompts compleja o gestionando interacciones complicadas de CLI solo para tener un equipo de IA ayudándote a escribir código.
Esa accesibilidad es especialmente importante cuando consideramos que muchos desarrolladores todavía no tuvieron contacto con sistemas multi-agente. Squad funciona como una puerta de entrada práctica a ese universo, permitiéndote ver la orquestación ocurriendo en tiempo real dentro de un entorno que ya conocés. Es aprender haciendo, sin necesitar un curso sobre arquitecturas de agentes antes de dar el primer paso.
Qué esperar de un proyecto en esta etapa
Squad todavía es un proyecto joven, y es importante tener esa expectativa bien calibrada antes de salir a usarlo en producción. Como cualquier herramienta open source al inicio de su ciclo de vida, es posible encontrar comportamientos inesperados, limitaciones en los casos de uso más complejos y una documentación que todavía se está construyendo a ritmo acelerado. Esto no es un defecto, es la naturaleza del desarrollo abierto, y forma parte de lo que hace a este tipo de proyecto interesante de seguir.
Para quienes están evaluando si vale la pena explorar ahora, la respuesta más honesta es: depende del contexto. Si tenés proyectos personales, estudios o pruebas de concepto donde podés experimentar sin presión, Squad ofrece una ventana muy accesible para entender cómo la orquestación multi-agente funciona en la práctica. Vas a aprender mucho solo con observar cómo el agente líder delega tareas, cómo responden los especialistas y dónde el sistema todavía tropieza. Ese aprendizaje tiene valor independientemente de que adoptes la herramienta a largo plazo o no.
Para uso en proyectos profesionales con deadlines y stakeholders involucrados, el camino más seguro es probar en paralelo, mantener un ojo en el repositorio oficial para seguir el ritmo de actualizaciones y evaluar en base a resultados concretos en tu contexto específico. El potencial está claramente ahí. La cuestión es cuándo la madurez de la herramienta va a alcanzar la ambición de la propuesta, y todo indica que ese camino se está recorriendo bastante rápido. ⚡
Squad fue creado por Brady Gaster, Principal PM Architect en el área de CoreAI Apps y Agents de Microsoft, y está disponible públicamente en GitHub para quien quiera probarlo, contribuir o simplemente seguir la evolución del proyecto.
