Sub-pipelines

A partir de cierto punto, copiar la misma secuencia de nodos en diez pipelines se convierte en deuda técnica. Los sub-pipelines permiten que un pipeline llame a otro como una función: define una pieza de lógica una vez, reutilízala en todas partes — incluso entre organizaciones.

Dos bloques de construcción simétricos:

• pipeline_callable (un receiver, declarado en el nodo Start) expone un pipeline detrás de una URL, con un contrato de entrada y salida tipado.
• pipeline_call (un nodo) llama a ese pipeline: mapea sus entradas desde el contexto actual y almacena el resultado en una clave de salida.

Exponer un pipeline (pipeline_callable)

En el pipeline «servicio», añades un receiver pipeline_callable que declara:

• Entradas — la lista de parámetros esperados (nombre, tipo, obligatorio u opcional).
• Salidas — las claves del resultado devuelto.
• Clave de respuesta — qué valor del contexto constituye la respuesta.
• Presupuesto de tiempo — tiempo máximo de ejecución (30 s por defecto, 300 s máximo).

El pipeline recibe entonces una URL pública (con un token) para compartir con el pipeline que llama. El token es rotatable en cualquier momento para revocar el acceso.

Llamar a un pipeline (pipeline_call)

En el pipeline «consumidor», el nodo pipeline_call se configura con:

• La URL del pipeline de destino.
• Un mapeo de entradas — para cada parámetro esperado, el selector de contexto que lo suministra.
• La clave de salida donde se almacena el resultado.

En caso de fallo (timeout, error, respuesta malformada), el pipeline continúa: la clave de salida recibe null y una clave ._error describe lo ocurrido. Es responsabilidad de tu pipeline orquestar el fallback (rama de reserva, alerta).

Llamadas entre organizaciones: opt-in y auditadas

Un sub-pipeline puede ser llamado por una organización diferente — este es el fundamento para compartir capacidades entre entidades. El modelo sigue siendo estricto:

• Rechazado por defecto. Las llamadas entre organizaciones solo son posibles si el administrador del pipeline expuesto las autoriza explícitamente (allow_cross_org).
• Firma HMAC recomendada. Una vez abierta una llamada entre organizaciones, se activa un secreto compartido: cada petición se firma, y el receiver rechaza cualquier firma ausente o inválida.
• Todo se traza. Cada invocación escribe un registro de auditoría (organización que llama, nodo, profundidad, latencia, estado) — antes de la ejecución, de modo que exista una traza incluso en caso de incidente. Ambas partes pueden consultar sus propios registros (lado del que llama y lado del llamado), conforme a los derechos de acceso del RGPD.

Prevención de bucles

Un pipeline que se llamara a sí mismo, directamente o a través de una cadena, consumiría créditos indefinidamente. Dos protecciones:

• Detección estática en el registro (dentro de una organización): el editor se niega a publicar un ciclo directo (A → A) o un ciclo indirecto (A → B → C → A), citando la cadena infractora.
• Guarda en tiempo de ejecución (entre organizaciones, donde la visibilidad estática es imposible): cada llamada propaga su profundidad; más allá de un techo configurado, la llamada se corta.

Modos de ejecución

• Síncrono — el nodo espera la respuesta completa. Adecuado para operaciones de corta duración.
• Streaming — para un sub-pipeline de larga duración (razonamiento LLM, procesamiento por lotes), el progreso se transmite en tiempo real sin timeout fijo. El pipeline que llama puede mostrar este progreso en una interfaz.

Cuándo usarlo

• Factorizar una secuencia reutilizada por varios pipelines (resumir un hilo, cualificar un lead, verificar un documento).
• Compartir una capacidad entre organizaciones — una entidad expone «validar una factura contra el ERP», otra la consume, con una traza de auditoría en ambos lados.
• Paralelizar un fan-out de subtareas independientes a partir de un bucle.