← Volver al listado de tecnologías ← Índice de Organic Driven Development (ODD)

Disparadores de delegación

5 de noviembre de 2026 Por: Artiko

odddelegacionsubagentesenrutamiento

Disparadores de delegación

Objetivos

Identificar cada disparador y su condición exacta.
Decidir cuándo un writer tiene un motivo válido.
Conocer la evolución de las reglas, para interpretar documentos antiguos del repositorio.

La regla general

Each trigger holds only when its condition truly holds, and only then is it mandatory, not advisory; no trigger holds by default, and when in doubt work inline.

internal/components/agentguidance/routing.go

Esta oración contiene tres afirmaciones:

Un disparador existe solo cuando su condición se cumple de verdad.
Cuando se cumple, es obligatorio. Se detiene y se delega antes de continuar.
Ante la duda, se trabaja inline.

Una vez resuelto el disparador, se reevalúa el tamaño y la tarea sigue pequeña si mantiene los tres criterios.

El mapa de disparadores

flowchart TD
    A["Durante el trabajo"] --> B{"¿Decisión de producto abierta?"}
    B -->|"Sí"| B1["Ask: una pregunta y esperar"]
    A --> C{"¿Comprensión excede el presupuesto?"}
    C -->|"Sí"| C1["Mapping: un explorador"]
    A --> D{"¿Falla la prueba de reanudación?"}
    D -->|"Sí"| D1["Tracking: documento, espejo y commits"]
    A --> E{"¿Motivo de writer?"}
    E -->|"Sí"| E1["Writer: un worker por unidad"]
    A --> F{"¿La línea Risk nombra un punto?"}
    F -->|"Sí"| F1["Verification: verificador independiente"]

Disparador	Condición	Acción
Ask	Decisión de producto o diseño abierta	Una pregunta enfocada, luego detenerse y esperar
Mapping	La comprensión excede el presupuesto inline o necesita más de ~5 búsquedas secuenciales	Un explorador de solo lectura antes de decidir o escribir
Verification	La línea Risk nombra un punto de alto riesgo	Un verificador independiente después de las comprobaciones propias
Tracking	Tarea grande	Documento de feature, espejo y commits por unidad
Writer	Motivo con nombre, ver abajo	Un writer acotado por unidad
Preparation	El Writer trigger delega una escritura	La lectura que la prepara se delega con ella o antes

El Writer trigger en detalle

Es el más restrictivo. Solo existen dos motivos:

Motivo (a): paralelismo

Se necesitan todas estas condiciones:

Dos o más unidades de comportamiento independientes.
Superficies de edición disjuntas.
Cada una requiere varios minutos de trabajo: varios archivos o aproximadamente más de 100 líneas cambiadas.
Se lanzan juntas.

La justificación es de costo: un subagente pasa uno o dos minutos leyendo antes de escribir.

Motivo (b): contexto

El backstop de sesión larga: el parent llegó cerca de ~150k tokens y entrega la siguiente unidad acotada a un worker fresco.

Qué no es un motivo

Situación	¿Justifica un writer?	Explicación
La tarea es grande	No	Recibe seguimiento, y el parent sigue inline con su bitácora
Muchos archivos	No	El número de archivos nunca activa este disparador
Un modelo más barato podría hacerlo	No	La relación de precios está excluida
Separar pruebas, docs y código	No	Una unidad lleva todo eso junto
Unidades de ~100 líneas o menos	No	Siempre inline: escribirlas cuesta menos que arrancar workers
Varias tareas pequeñas independientes	No	Corren inline, una tras otra
Una entrega que depende de otra	No	Las unidades dependientes no son independientes

Qué es una unidad

Una unidad es una pieza de comportamiento independiente con su código, sus pruebas y su documentación. Nunca se divide un comportamiento en writers de pruebas, documentación y código.

flowchart LR
    subgraph N["Sin motivo"]
        N1["Writer de código"] --- N2["Writer de pruebas"] --- N3["Writer de docs"]
    end
    subgraph S["Con motivo"]
        S1["Unidad A<br/>código, pruebas y docs"]
        S2["Unidad B<br/>código, pruebas y docs"]
    end

Los cuatro motivos del README

El README agrupa el conjunto de delegaciones por motivo en una tabla:

Motivo	Cuándo aplica
Exploration	La comprensión necesita más de una tanda inline o más de ~5 búsquedas secuenciales
Parallel writers	Dos o más unidades independientes con superficies disjuntas, cada una de varios minutos
Context backstop	Una sesión larga entrega su siguiente unidad a un worker fresco
Independent verifier	Un cambio que nombra un punto de alto riesgo

Route declaration

Para que la delegación sea observable, en trabajo grande se registra la ruta por tarea y la evidencia del disparador en el documento de feature.

- [x] T1 (S1-S5) inline · sin motivo de writer · RED→GREEN · 6c66491
- [x] T4 (S3) delegated · paralelismo con T5, superficies disjuntas · f58774f

La idea proviene de un problema real: cuando ODD no exigía declarar la ruta, omitir una delegación resultaba invisible.

Evolución de las reglas

Si exploras odd/tasks/ en el repositorio encontrarás reglas que parecen contradecir lo anterior. Son registros históricos.

timeline
    title Cómo cambió la delegación según las tareas del repositorio
    Delegación como descripción : El parent hacía todo inline : odd-mandatory-delegation detecta el problema
    Disparadores obligatorios : Regla de 4 archivos : Regla de 2 archivos no triviales
    Proporción de gasto : Una segunda edición mecánica no activa la regla : odd-spend-proportionality
    Tamaño de tarea : Comprensión, riesgo y reanudación : task-size-canon
    Delegar por un motivo : Writer solo por paralelismo o contexto : 1731-parity-delegate-for-reason

Documento	Qué regla registra	Estado
`odd-mandatory-delegation.md`	Disparadores obligatorios, regla de archivos, declaración de ruta	La obligatoriedad y la declaración siguen. La regla de archivos, no
`odd-spend-proportionality.md`	Delegación por dos archivos no triviales	Sustituida
`task-size-canon.md`	Tamaño por comprensión, riesgo y reanudación	Vigente
`1731-parity-delegate-for-reason.md`	Writer por motivo, y verificar siempre el código de modelos menores	La primera sigue, la segunda se eliminó del texto actual

El último caso ilustra por qué se debe leer el texto instalado. La especificación S8 de 1731 mencionaba verificación “always on smaller-model code”, mientras que el texto vigente dice que el modelo o esfuerzo del writer nunca agrega un verificador. La bitácora histórica registra lo que se decidió entonces.

Los números detrás de la decisión

El README atribuye estas reglas a mediciones, no a la intuición. En una corrida de un bug de tres líneas, pasar a inline sin subagentes bajó de 335 s a 77 s y de 56 a 10 turnos. El capítulo 22 analiza esa tabla y sus límites: cada celda es una sola ejecución.

Actividad

Para cada caso, decide si hay motivo de writer:

Tres arreglos independientes de 20 líneas cada uno.
Dos servicios sin relación, cada uno con unas 200 líneas y sus pruebas, en carpetas distintas.
Una funcionalidad de 800 líneas en un módulo, sin paralelismo.
Una API y un cliente que depende de esa API.

Una posible solución

No. Unidades de ~100 líneas o menos corren inline, una tras otra.
Sí, por paralelismo: independientes, disjuntas y de varios minutos, siempre que se lancen juntas.
No por tamaño. Se registra si falla la prueba de reanudación y sigue inline, salvo que aparezca el backstop de contexto.
No. Una entrega que depende de otra no es independiente.

Autoevaluación

¿Qué afirma la fuente sobre seguir inline después de activarse un disparador?
- A. Es aceptable si el trabajo sale bien
- B. Es un defecto de enrutamiento aunque tenga éxito
- C. Es la conducta recomendada para ahorrar tokens
- D. Solo importa en tareas grandes
¿Cuáles son los dos motivos válidos para un writer?
- A. Tamaño y número de archivos
- B. Riesgo y costo del modelo
- C. Paralelismo y backstop de contexto
- D. Tareas grandes y pruebas largas
¿Cuál es el motivo de excluir unidades de ~100 líneas o menos?
- A. Las pruebas no se pueden delegar
- B. No caben en un prompt
- C. Lo exige el proveedor
- D. Escribirlas cuesta menos que arrancar workers
¿Para qué sirve Route declaration?
- A. Para que una delegación omitida sea observable
- B. Para que el binario bloquee la tarea
- C. Para calcular la tarifa
- D. Para activar RDD

Respuestas

B. “Executing past a fired trigger inline is a routing defect even if the work succeeds.”
C. Son los motivos (a) y (b).
D. Es la explicación del texto.
A. “So skipped delegation is observable instead of silent.”

Lista de control

Puedo nombrar los seis disparadores y su condición.
Aplico las cuatro condiciones del paralelismo.
Mantengo código, pruebas y documentación en la misma unidad.
Sé que los documentos de odd/tasks/ son historia, no el texto vigente.

Fuentes

internal/components/agentguidance/routing.go, README.md, docs/trigger-rules.md, odd/tasks/odd-mandatory-delegation.md, odd/tasks/odd-spend-proportionality.md, odd/tasks/task-size-canon.md, odd/tasks/1731-parity-delegate-for-reason.md.