Orquestación de agentes de IA

Antes de las pruebas en paralelo, instala las dependencias en cada checkout y asigna archivos ignorados, puertos y bases de datos de prueba distintos. Sigue la receta reproducible de preparación de los worktrees. Si un recurso debe seguir siendo compartido, secuencia los tickets con una dependencia.

Un MCP es una interfaz de herramientas que la IA puede invocar durante una misión. La pasarela interna de Singularity le permite leer el contexto de los tickets, publicar su actividad, consultar archivos adjuntos, preparar un worktree, seguir a sus hijos y registrar su resultado. Estas operaciones actualizan el seguimiento visible en la aplicación.

Los plugins activos pueden añadir herramientas especializadas. El catálogo orchestration_list_available_mcps indica los servidores disponibles; el tipo y las etiquetas del ticket pueden hacer accesibles las herramientas pertinentes desde el inicio. Instalar un plugin no significa que todas sus capacidades estén activas en cada workspace.

Ejemplo: para diagnosticar un fallo de CI, el agente puede consultar los registros con las herramientas del plugin Pipelines y después preparar una corrección y su informe. Las herramientas disponibles siguen sujetas a los permisos y a las instrucciones de la misión. El acceso a una herramienta no constituye una autorización de publicación ni de ejecución remota.

Para comprender las superficies implicadas, consulta los tickets, el Marketplace y Pipelines.

El ticket es la misión del agente: su título, su descripción, sus archivos adjuntos y su contexto se convierten en el pliego de condiciones de la ejecución. Cuando el aislamiento por worktree está activado, Singularity crea una copia Git dedicada en una rama propia. Así, el agente puede leer, modificar, probar y hacer commits sin alterar tu directorio de trabajo.

Al final, los commits se recolocan sobre la rama base mediante rebase. El historial sigue siendo lineal y varios agentes pueden avanzar en paralelo sin compartir los mismos archivos de trabajo.

Puedes iniciar una ejecución desde una tarjeta del tablero o desde el detalle del ticket. Selecciona el proveedor de IA y el modelo adecuados para la misión y lanza el agente. El proveedor corresponde al CLI instalado y autenticado en tu equipo; el modelo determina las capacidades y el coste de la sesión.

El planificador también puede tomar automáticamente el siguiente ticket listo, según las dependencias, la prioridad y el límite de agentes simultáneos. Los tickets que no están listos permanecen en su sitio.

El terminal del agente muestra su flujo en directo: comandos, herramientas y resultados. En Mission Control, la etiqueta de actividad de la tarjeta resume la fase actual —lectura, escritura, tests, commit o espera— sin necesidad de abrir el terminal.

La indicación Worked on (proyectos afectados) se actualiza durante la misión. Muestra de inmediato qué repositorios ha leído o modificado el agente.

Una pregunta bloqueante pone el ticket en espera e indica que se necesita una acción por tu parte. Responde en el detalle del ticket: la respuesta se transmite a la misma sesión y el agente continúa con todo su contexto.

También puedes enviar un mensaje durante una ejecución, detener el proceso si la dirección ya no es la correcta y después reiniciar o relanzar el ticket. La detención es explícita: no se confunde con un fallo técnico.

Al final de su misión, el agente registra un informe detallado y una resolución breve visible en la tarjeta. El estado distingue claramente los desenlaces:

• Done: el trabajo está terminado y validado por el flujo elegido.
• Failed: la ejecución se ha detenido por un error; puede relanzarse.
• Pending: la ejecución está en pausa, por ejemplo a la espera de una respuesta, de hijos o de la cola de commits.
• User action: una intervención que no se puede automatizar se asigna a una persona.

El ajuste de fusión automática decide la última etapa. Cuando está activado, Singularity reintegra el worktree tras el éxito de la ejecución. Cuando está desactivado, el resultado queda aparcado para su inspección: puedes leer el informe, examinar los cambios y elegir aprobarlos o pedir una corrección.

Consulta la revisión de código de los runs para conocer el recorrido de validación completo.

Cada sesión dispone de un servidor MCP local y temporal, autenticado solo para esa ejecución. Es el canal por el que el agente dialoga con Singularity: puede leer el ticket y sus dependencias, registrar los proyectos afectados, publicar su fase de actividad, plantear una pregunta, adjuntar un documento o crear un ticket de seguimiento.

La pasarela caduca con la sesión. Por tanto, el agente no recibe un acceso general y permanente a la aplicación.

El sandbox opcional rodea el proceso del agente de restricciones del sistema: Seatbelt en macOS y Landlock en Linux. Según el proveedor y la configuración del proyecto, limita en particular el acceso al sistema de archivos y a la red para que los comandos del agente permanezcan dentro del alcance previsto.

Esta protección complementa el aislamiento Git del worktree: el worktree separa los cambios de código, mientras que el sandbox restringe el proceso que los produce.

Las ejecuciones, los intentos y las salidas del terminal se registran sobre la marcha. Si la aplicación se cierra, Singularity comprueba en el siguiente arranque qué sesiones le pertenecían y si su proceso sigue existiendo, sin interrumpir los agentes de otra instancia.

Una sesión todavía válida puede volver a vincularse o reanudarse de forma nativa cuando el proveedor lo permite, en particular con Claude. De lo contrario, el ticket se coloca en un estado recuperable y explícito en lugar de considerarse terminado de forma silenciosa.