Mixed Tree

When to reach for this

Reach for mixed-tree when the natural decomposition spans multiple structural shapes:

• One arm is sequential, another is parallel. E.g. preprocessing (sequential), then several independent analyses (parallel), then assembly (sequential).
• A loop contains its own sub-tree. A per-item flow that itself has multiple LLM blocks + a code-assembly step is a sub-tree under a loop.
• The shape was derived bottom-up. You arrived at mixed-tree because your decomposition produced it — not because you wanted "the most flexible shape."

Anti-pattern: reaching for mixed-tree first because it's the most general. Start from atomic decomposition. If the decomposition naturally fits single-block, sequential, parallel, or loop, use that. Mixed-tree is the answer when those are insufficient — never as a default.

Sequential, parallel, and loops composed together for realistic pipelines.

Flow: "Article Repurposer"
├── Block: "Extract Metadata" (llm)
│     Output: { title, audience, key_points }
├── Container (parallel)
│     ├── Block: "Tweet Draft" (llm)
│     ├── Block: "LinkedIn Draft" (llm)
│     └── Block: "Newsletter Blurb" (llm)
└── Block: "Package Output" (code)
      Output: { tweet, linkedin, newsletter, source_title }

When to use: real workflows almost always look like this — one or two preparation steps, a fan-out for independent generations, then a deterministic aggregation.

Common mistake: using an llm block as the final aggregator when a code block would do. The shape of the output object is determined by the upstream block names; you don't need a model to assemble a struct.