pipeline-architecture-selector

Pipeline Architecture Selector

Overview

Production tasks have variable complexity. A research query about a well-documented topic needs simple sequential processing; an ambiguous query exploring cutting-edge developments needs parallel hypothesis exploration with iterative refinement. Committing to one pipeline shape means simple tasks pay the parallel-coordination tax and hard tasks get under-served.

The chapter's answer: make architecture selection a routing decision inside a meta-pipeline. Run one cheap analysis pass over the task — complexity and uncertainty — then route:

if complexity < SIMPLE and uncertainty < LOW:   sequential
elif uncertainty > HIGH:                         tree (explore hypotheses)
else:                                            loop (iterative refinement)

Then wrap that with runtime-constraint checks so the agent delivers results within constraints rather than failing or timing out (Example 5-11):

• ideal=tree but free memory < threshold -> sequential_fallback
• ideal=loop but time budget < one iteration -> single_pass_best_effort

Per the chapter: "Build these fallback paths explicitly rather than relying on exception handling — graceful degradation is a feature, not an error case."

In the DevOps latency investigation (account 123456789012), "what is the checkout error rate?" routes sequential; "why did checkout latency spike from 200ms to 2.5s?" scores high uncertainty and routes to a tree of parallel hypothesis tests — unless memory is tight, in which case it degrades to sequential testing of the same hypotheses.

When to Use

• One agent handling a stream of tasks with genuinely variable complexity
• You observe simple tasks paying parallel-coordination overhead, or hard tasks failing under a too-simple pipeline
• You need an explicit, auditable record of WHY a task took a given path

Phrases: "route to the right pipeline", "dynamic architecture selection", "sequential vs tree vs loop", "graceful degradation", "resource-aware routing".