Sub-pipelines

Beyond a certain point, copying the same sequence of nodes across ten pipelines becomes technical debt. Sub-pipelines allow a pipeline to call another as a function: define a piece of logic once, reuse it everywhere — including across organisations.

Two symmetric building blocks:

• pipeline_callable (a receiver, declared on the Start node) exposes a pipeline behind a URL, with a typed input and output contract.
• pipeline_call (a node) calls that pipeline: it maps its inputs from the current context and stores the result in an output key.

Exposing a pipeline (pipeline_callable)

On the "service" pipeline, you add a pipeline_callable receiver that declares:

• Inputs — the list of expected parameters (name, type, required or optional).
• Outputs — the keys of the returned result.
• Response key — which context value constitutes the response.
• Time budget — maximum execution time (30 s by default, 300 s maximum).

The pipeline then receives a public URL (with a token) to share with the calling pipeline. The token is rotatable at any time to revoke access.

Calling a pipeline (pipeline_call)

On the "consumer" pipeline, the pipeline_call node is configured with:

• The URL of the target pipeline.
• An input mapping — for each expected parameter, the context selector that supplies it.
• The output key where the result is stored.

On failure (timeout, error, malformed response), the pipeline continues: the output key receives null and a ._error key describes what happened. It is your pipeline's responsibility to orchestrate the fallback (fallback branch, alert).

Cross-organisation calls: opt-in and audited

A sub-pipeline can be called by a different organisation — this is the foundation for sharing capabilities between entities. The model remains strict:

• Rejected by default. Cross-organisation calls are only possible if the administrator of the exposed pipeline explicitly authorises it (allow_cross_org).
• HMAC signature recommended. Once a cross-org call is opened, a shared secret is activated: every request is signed, and the receiver rejects any absent or invalid signature.
• Everything is traced. Each invocation writes an audit record (calling organisation, node, depth, latency, status) — before execution, so that a trace exists even in the event of an incident. Both parties can consult their own logs (caller side and callee side), in accordance with GDPR access rights.

Loop prevention

A pipeline that called itself, directly or through a chain, would consume credits indefinitely. Two protections:

• Static detection at registration (within an organisation): the editor refuses to publish a direct cycle (A → A) or indirect cycle (A → B → C → A), citing the offending chain.
• Runtime guard (across organisations, where static visibility is impossible): each call propagates its depth; beyond a configured ceiling, the call is cut.

Execution modes

• Synchronous — the node waits for the complete response. Suited to short-running operations.
• Streaming — for a long-running sub-pipeline (LLM reasoning, batch processing), progress is streamed in real time with no fixed timeout. The calling pipeline can surface this progress in a UI.

When to use it

• Factor out a sequence reused by multiple pipelines (summarise a thread, qualify a lead, verify a document).
• Share a capability between organisations — one entity exposes "validate an invoice against the ERP", another consumes it, with an audit trail on both sides.
• Parallelise a fan-out of independent sub-tasks from a loop.