Delegar trabajo a agentes

Esta guía trata de cómo quitarte trabajo de encima y ponérselo a un agente, y de qué ocurre cuando los agentes se pasan trabajo entre ellos.

Entregar un ticket a un agente

Crea el ticket con un título y una descripción lo bastante precisos para poder trabajar con ellos.
Establece su Asignado a en el agente, para que la titularidad quede registrada.
Abre (o crea) un espacio y menciona a ese agente con @.
Haz referencia al ticket con una mención # en tu mensaje —el compositor autocompleta los tickets del espacio de trabajo— y di qué quieres que se haga.

El agente retoma el trabajo desde la conversación. Su progreso se transmite en ese espacio.

Qué recibe el agente

Tu mensaje, incluida la referencia al ticket que etiquetaste.
El espacio en el que trabajar y reportar.
Un worktree aislado de los repos vinculados al espacio de trabajo.
El modo del espacio, que es lo que rige la superficie de herramientas de la ejecución.

El modo es una propiedad del espacio, no del ticket: un ticket no tiene modo. Por eso un agente puede estar en chat en un espacio y en plan en otro. Elígelo en el desplegable de modo del compositor (Agent, Plan o Orchestrate); review lo establecen los espacios de revisión de PR y no se puede seleccionar. Consulta Modos.

Exigir un resultado estructurado

El contrato de salida se declara en el despacho, no en el ticket: expected_output_schema más output_contract_mode (estricto de forma predeterminada). El agente lo cumple llamando a submit_output, que valida la carga útil contra el esquema y rechaza la que no se ajusta a él.

Tanto la salida aceptada como los rechazos quedan en el registro de ejecución del agente. El estado del propio ticket no se toca por esto: un contrato incumplido no hace fallar el ticket.

Monitorear el progreso

El espacio — actividad del agente en vivo, la vista principal.
El ticket — su estado, tal como lo establezca quien lo mueva.
Observabilidad → En vivo (/workspaces/<workspace-id>/observability) — la lista de agentes en vivo.
Observabilidad → Resumen — el registro de ejecución, con costo y duración.

No hay ninguna pantalla de panel; una URL de espacio de trabajo sin más redirige a la bandeja de entrada.

Dejar que los agentes se deleguen trabajo entre sí

Un agente que se topa con un subproblema delega con la herramienta MCP delegate_task. Esta crea un ticket hijo asignado a otro agente y —cuando pasas parent_ticket_id— registra la cadena para que las protecciones puedan verla.

Dos protecciones estructurales se ejecutan siempre en el punto de paso de los tickets, nunca por instrucción del prompt:

Límite de profundidad — se rechaza una cadena con más de 3 saltos.
Detección de ciclos — se rechaza un salto de vuelta a un agente que ya está en la cadena.

Cuando pasas from_agent_id, se ejecutan dos protecciones más (producción siempre aporta los puertos de resolución):

Techo de autonomía — el nivel efectivo del delegado en el espacio no debe superar el del delegador.
Envolvente de presupuesto — la delegación imputa el presupuesto de parada estricta restante del delegador y no puede acuñar más. Sin política, o con una política ilimitada, pasa.

Un rechazo es ruidoso: la herramienta devuelve el motivo de la protección palabra por palabra, de modo que el agente que delega ve exactamente por qué. El campo delegatedByAgentId registra quién delegó, lo que forma un árbol de delegación.

Este límite de profundidad de delegación de 3 es un límite distinto del límite de anidamiento de subagentes del arnés integrado, que es 2: uno acota los tickets entre agentes y el otro acota los subagentes dentro de una sola ejecución.

Poner varios agentes en un mismo ticket

Agrégalos como colaboradores del ticket (roles: assignee, collaborator, reviewer). Eso es una lista —un registro de quién está involucrado— y por sí sola no otorga nada.

Para meter realmente a los agentes en la misma conversación, agrégalos como participantes desde el encabezado del espacio. Entonces podrán mencionarse entre ellos con @ ahí mismo. Consulta Espacios.

Creación automática de tickets

Ningún nodo de la paleta de pipelines crea tickets, así que un pipeline no puede repartir trabajo como tickets asignados.

La vía que sí existe es la orquestación: aprobar una propuesta crea un proyecto y un equipo, compila el DAG de subtickets de la propuesta en una plantilla de pipeline (un paso promptAgent por subticket, no una fila Ticket por cada uno) y arranca esa ejecución. Consulta Ejecutar una orquestación.