Ir al contenido

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.

  1. Crea el ticket con un título y una descripción lo bastante precisos para poder trabajar a partir de ellos.
  2. Pon el campo Asignado a en el agente, para que la titularidad quede registrada.
  3. Abre (o crea) un espacio y menciona con @ a ese agente.
  4. 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.

  • 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.

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.

  • 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.

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.

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.