Delegar trabajo a agentes
Esta guía trata de 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
Sección titulada «Entregar un ticket a un agente»- Crea el ticket con un título y una descripción lo bastante precisos para poder trabajar a partir de ellos.
- Pon el campo Asignado a en el agente, para que la titularidad quede registrada.
- Abre (o crea) un espacio y menciona con @ a ese agente.
- 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 recoge el trabajo desde la conversación. Su progreso se transmite a ese espacio.
Qué recibe el agente
Sección titulada «Qué recibe el agente»- Tu mensaje, incluida la referencia al ticket que etiquetaste.
- El espacio en el que trabajar y en el que informar.
- Un worktree aislado a partir de los repos vinculados del 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 mismo agente puede estar en chat en un espacio y en plan en otro.
Elígelo en la lista desplegable de modo del compositor (Agente, Plan o
Orquestación); review lo fijan los espacios de revisión de PR y no se puede
seleccionar. Consulta Modos.
Exigir un resultado estructurado
Sección titulada «Exigir un resultado estructurado»Un 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 satisface 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 acaban en el registro de ejecución del agente. El estado del propio ticket no se ve afectado por ello: un contrato fallido no hace que el ticket falle.
Supervisar el progreso
Sección titulada «Supervisar el progreso»- El espacio — la actividad del agente en vivo, la vista principal.
- El ticket — su estado, tal como lo ponga quien lo mueva.
- Observabilidad → En vivo (
/workspaces/<workspace-id>/observability) — la lista de agentes en vivo. - Observabilidad → Resumen — el registro de ejecución, con coste y duración.
No hay ninguna pantalla de panel; una URL de espacio de trabajo a secas redirige a la bandeja de entrada.
Dejar que los agentes se deleguen trabajo entre sí
Sección titulada «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.
En el punto de paso de los tickets se ejecutan siempre dos protecciones estructurales, nunca por instrucción del prompt:
- Límite de profundidad — se rechaza una cadena de 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 (el cableado de
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 tal
cual, así que el agente que delega ve exactamente por qué. El campo
delegatedByAgentId registra quién delegó y 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 harness integrado, que es 2: uno acota los tickets entre agentes y el otro acota los subagentes dentro de una misma ejecución.
Poner varios agentes en un mismo ticket
Sección titulada «Poner varios agentes en un mismo ticket»Añádelos como colaboradores del ticket (roles: asignado, colaborador, revisor). Eso es una lista de participantes —un registro de quién está implicado— y no concede nada por sí solo.
Para meter de verdad a los agentes en la misma conversación, añádelos como participantes desde el encabezado del espacio. Así podrán mencionarse entre sí con @. Consulta Espacios.
Creación automatizada de tickets
Sección titulada «Creación automatizada de tickets»Ningún nodo de la paleta de pipelines crea tickets, así que un pipeline no puede repartir el 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 tickets hijos de la propuesta en una plantilla de
pipeline (un paso promptAgent por ticket hijo, no una fila Ticket para cada
uno) y arranca esa ejecución. Consulta
Ejecutar una orquestación.
Guías relacionadas
Sección titulada «Guías relacionadas»- Crear y gestionar tickets
- Chatear con un agente
- Ejecutar una orquestación
- Organizar el trabajo con proyectos
- Referencia del ciclo de vida de tickets