Delegar trabalho a agentes

Este guia trata de tirar trabalho das suas mãos e colocá-lo nas de um agente, e do que acontece quando os agentes passam trabalho entre si.

Entregar um ticket a um agente

Crie o ticket com um título e uma descrição precisos o suficiente para trabalhar a partir dela.
Defina o Responsável dele como o agente, para que a propriedade fique registrada.
Abra (ou crie) um espaço e mencione esse agente com @.
Referencie o ticket com uma menção # na sua mensagem — o composer autocompleta os tickets do espaço de trabalho — e diga o que você quer que seja feito.

O agente pega o trabalho a partir da conversa. O progresso dele é transmitido nesse espaço.

O que o agente recebe

Sua mensagem, incluindo a referência de ticket que você marcou.
O espaço onde trabalhar e reportar.
Um worktree isolado dos repos vinculados ao espaço de trabalho.
O modo do espaço, que é o que governa a superfície de ferramentas da execução.

O modo é uma propriedade do espaço, não do ticket — um ticket não tem modo. Um mesmo agente pode, portanto, estar em chat em um espaço e em plan em outro. Escolha-o na lista suspensa de modo do composer (Agent, Plan ou Orchestrate); review é definido por espaços de revisão de PR e não pode ser selecionado. Consulte Modos.

Exigir um resultado estruturado

Um contrato de saída é declarado no despacho, não no ticket: expected_output_schema mais output_contract_mode (estrito por padrão). O agente o satisfaz chamando submit_output, que valida o payload contra o esquema e rejeita um que não esteja em conformidade.

Tanto a saída aceita quanto eventuais rejeições ficam no log de execução do agente. O status do próprio ticket não é afetado por isso — um contrato que falha não faz o ticket falhar.

Acompanhar o progresso

O espaço — a atividade dos agentes ao vivo, a visão principal.
O ticket — o status dele, conforme quem o move o define.
Observabilidade → Ao vivo (/workspaces/<workspace-id>/observability) — a lista de agentes ao vivo.
Observabilidade → Resumo — o log de execução, com custo e duração.

Não existe uma tela de painel; um URL de espaço de trabalho sem nada depois dele redireciona para a caixa de entrada.

Deixar os agentes delegarem entre si

Um agente que esbarra em um subproblema delega com a ferramenta MCP delegate_task. Ela cria um ticket filho atribuído a outro agente e — quando você passa parent_ticket_id — registra a cadeia para que as verificações possam vê-la.

Duas verificações estruturais sempre são executadas no ponto de estrangulamento dos tickets, nunca por instrução de prompt:

Limite de profundidade — uma cadeia com mais de 3 saltos é recusada.
Detecção de ciclo — um salto de volta para um agente que já está na cadeia é recusado.

Quando você passa from_agent_id, mais duas verificações são executadas (a produção sempre fornece as portas de resolução):

Teto de autonomia — o nível efetivo do delegado no espaço não pode exceder o do delegador.
Envelope de orçamento — a delegação debita o orçamento de parada rígida restante do delegador e não pode criar mais. A ausência de política, ou uma política ilimitada, passa.

Uma recusa é ruidosa: a ferramenta retorna o motivo da verificação literalmente, de modo que o agente delegador vê exatamente o porquê. O campo delegatedByAgentId registra quem delegou, formando uma árvore de delegação.

Este limite de profundidade de delegação de 3 é um limite diferente do limite de aninhamento de subagentes de 2 do harness integrado — um limita tickets entre agentes, o outro limita subagentes dentro de uma única execução.

Colocar vários agentes em um único ticket

Adicione-os como colaboradores no ticket (funções: responsável, colaborador, revisor). Isso é apenas uma lista — um registro de quem está envolvido — e não concede nada por si só.

Para de fato colocar agentes na mesma conversa, adicione-os como participantes no cabeçalho do espaço. Eles podem então se mencionar com @ ali. Consulte Espaços.

Criação automatizada de tickets

Nenhum nó da paleta de pipelines cria tickets, então um pipeline não pode distribuir trabalho como tickets atribuídos.

O caminho que existe é a orquestração: aprovar uma proposta cria um projeto e uma equipe, compila o DAG de subtickets da proposta em um modelo de pipeline (uma etapa promptAgent por subticket, e não uma linha Ticket para cada um) e inicia essa execução. Consulte Executar uma orquestração.