Orquestração de agentes de IA

Antes dos testes em paralelo, instala as dependências em cada checkout e atribui ficheiros ignorados, portas e bases de dados de teste distintos. Segue a receita reprodutível de preparação dos worktrees. Se um recurso tiver de continuar partilhado, sequencia os tickets com uma dependência.

Um MCP é uma interface de ferramentas que a IA pode chamar durante uma missão. O gateway interno do Singularity permite-lhe ler o contexto dos tickets, publicar a sua atividade, consultar anexos, preparar um worktree, acompanhar os filhos e registar o resultado. Estas operações atualizam o acompanhamento visível na aplicação.

Os plugins ativos podem adicionar ferramentas especializadas. O catálogo orchestration_list_available_mcps indica os servidores disponíveis; o tipo e as etiquetas do ticket podem tornar as ferramentas pertinentes acessíveis desde o início. Instalar um plugin não significa que todas as suas capacidades estejam ativas em cada workspace.

Exemplo: para diagnosticar uma falha de CI, o agente pode consultar os registos com as ferramentas do plugin Pipelines e, em seguida, preparar uma correção e o respetivo relatório. As ferramentas disponíveis continuam sujeitas às permissões e às instruções da missão. O acesso a uma ferramenta não constitui uma autorização de publicação nem de execução remota.

Para compreender as superfícies envolvidas, consulta os tickets, o Marketplace e Pipelines.

O ticket é a missão do agente: o título, a descrição, os anexos e o contexto tornam-se o caderno de encargos da execução. Quando o isolamento por worktree está ativado, o Singularity cria uma cópia Git dedicada numa branch própria. Assim, o agente pode ler, alterar, testar e fazer commits sem perturbar o teu diretório de trabalho.

No fim, os commits são recolocados na branch base por rebase. O histórico mantém-se linear e vários agentes podem avançar em paralelo sem partilhar os mesmos ficheiros de trabalho.

Podes iniciar uma execução a partir de um cartão do quadro ou do detalhe do ticket. Seleciona o fornecedor de IA e o modelo adequados à missão e lança o agente. O fornecedor corresponde ao CLI instalado e autenticado no teu computador; o modelo determina as capacidades e o custo da sessão.

O planeador também pode pegar automaticamente no próximo ticket pronto, de acordo com as dependências, a prioridade e o limite de agentes em simultâneo. Os tickets que não estão prontos permanecem no seu lugar.

O terminal do agente mostra o seu fluxo em direto: comandos, ferramentas e resultados. No Mission Control, a etiqueta de atividade do cartão resume a fase atual — leitura, escrita, testes, commit ou espera — sem teres de abrir o terminal.

A indicação Worked on (projetos afetados) é atualizada durante a missão. Mostra de imediato que repositórios foram lidos ou alterados pelo agente.

Uma pergunta bloqueante coloca o ticket em espera e indica que é necessária uma ação da tua parte. Responde no detalhe do ticket: a resposta é transmitida à mesma sessão e o agente retoma com todo o seu contexto.

Também podes enviar uma mensagem durante uma execução, parar o processo se a direção deixar de ser a certa e depois reiniciar ou relançar o ticket. A paragem é explícita: não se confunde com uma falha técnica.

No fim da missão, o agente regista um relatório detalhado e uma resolução curta visível no cartão. O estado distingue claramente os desfechos:

• Done: o trabalho está concluído e validado pelo fluxo escolhido.
• Failed: a execução parou devido a um erro; pode ser relançada.
• Pending: a execução está em pausa, por exemplo à espera de uma resposta, de filhos ou da fila de commits.
• User action: uma intervenção que não pode ser automatizada é atribuída a uma pessoa.

A definição de merge automático decide a última etapa. Quando está ativada, o Singularity reintegra o worktree após o sucesso da execução. Quando está desativada, o resultado fica estacionado para inspeção: podes ler o relatório, examinar as alterações e optar por aprová-las ou pedir uma correção.

Consulta a revisão de código dos runs para conhecer o percurso de validação completo.

Cada sessão dispõe de um servidor MCP local e temporário, autenticado apenas para essa execução. É o canal através do qual o agente dialoga com o Singularity: pode ler o ticket e as respetivas dependências, registar os projetos afetados, publicar a sua fase de atividade, fazer uma pergunta, anexar um documento ou criar um ticket de seguimento.

O gateway expira com a sessão. Por isso, o agente não recebe um acesso geral e permanente à aplicação.

O sandbox opcional envolve o processo do agente em restrições do sistema: Seatbelt no macOS e Landlock no Linux. Consoante o fornecedor e a configuração do projeto, limita nomeadamente o acesso ao sistema de ficheiros e à rede, para que os comandos do agente permaneçam dentro do âmbito previsto.

Esta proteção complementa o isolamento Git do worktree: o worktree separa as alterações de código, enquanto o sandbox restringe o processo que as produz.

As execuções, as tentativas e as saídas do terminal são registadas à medida que acontecem. Se a aplicação fechar, o Singularity verifica no arranque seguinte que sessões lhe pertenciam e se o respetivo processo ainda existe, sem interromper os agentes de outra instância.

Uma sessão ainda válida pode ser reassociada ou retomada nativamente quando o fornecedor o permite, nomeadamente com o Claude. Caso contrário, o ticket é colocado num estado recuperável e explícito, em vez de ser silenciosamente considerado concluído.