Single Block

When to reach for this

Reach for single-block ONLY after decomposition confirms there is nothing to decompose:

• Input is a single object. No array, no batch, no list of items requiring per-item logic.
• One reasoning task. The block does ONE thing — classify, transform, summarize. If you can name two distinct reasoning tasks (e.g. "extract sense AND generate examples"), this is the wrong pattern.
• No deterministic post-processing. If you need to assemble, slot, validate, or reformat after the LLM call, a follow-up code block is cheaper and more reliable than asking the LLM to do shape work.
• Output schema is small. If the schema has more than ~5 top-level fields, the LLM is likely doing multiple jobs in one call.

If any of those checks fail, decompose further before scaffolding. Default-to-single-block is the most common anti-pattern — see Best Practices → Anti-patterns.

The simplest flow possible. Use it when one prompt can do the whole job.

Flow: "Sentiment Classifier"
└── Block: "Classify" (llm)
      Output: { sentiment: "positive" | "neutral" | "negative" }

When to use: the task is a single act of reasoning — classification, a one-shot transformation, a short generation.

Common mistake: splitting a single coherent task into multiple blocks "for clarity." Each extra block costs latency and tokens, and adds a serialization boundary the model has to round-trip through. If two prompts would share most of their context anyway, keep them as one block.