Solid purple cover graphic for the prompt chains pillar guide

The Complete Guide to Prompt Chains in 2026

July 31, 2026

A prompt chain links multiple prompt or AI-processing steps into a single ordered workflow, passing each step's output forward as input to the next step. You need one whenever a task requires more structure than a single prompt can hold — multiple stages, conditional branching, or work that depends on the result of an earlier step. This guide covers the three chain topologies PromptHub supports, the guardrails that keep a chain from running away, what a chain costs to run, and how to build your first one.

What a Prompt Chain Is (and What It Is Not)

A prompt chain is not just a longer prompt. A single prompt asks a model to do everything in one pass — draft, critique, and rewrite all bundled into one instruction block, with no way to inspect or act on an intermediate result before the model produces its final answer. A chain breaks that same work into discrete nodes, each with its own instruction and (for most node types) its own AI call, and the boundary between nodes is a real seam: you can log a step's output, branch execution on it, or hand it to a human before continuing to the next node.

A prompt chain is also not an Agent. A chain's structure — which node runs after which — is fixed by the chain's author at design time; the same input always traverses the same graph of nodes in the same order, modulo whichever branch a condition node selects. An Agent, by contrast, decides its own next action at runtime: it chooses which tool to call, up to five tool calls per turn on PromptHub, based on the model's own reasoning about the conversation so far. A chain is deterministic in its shape; an Agent's shape is bounded but not fixed in advance.

That distinction matters for when you reach for each one. If you already know the steps a task needs and the order they run in, a chain gives you that structure explicitly and makes every step inspectable. If you don't know in advance how many steps a task will take or which tool it will need next, an Agent's runtime decision-making is the better fit — at the cost of the model choosing, rather than you.

The Three Chain Topologies

PromptHub's chain builder offers node types that combine into three structural connection patterns, plus a fourth option — Composite Steps — that changes what a single node carries rather than how nodes connect to each other.

Sequential

The simplest topology: each node's outgoing connection wires it directly to exactly one next node, and the chain runs from its input node through to its output node in a straight line. A node's output becomes available to every node that runs after it, through the chain's shared variable scope — the mechanism the next section covers in detail.

Parallel

A parallel_start node forks execution into multiple branches that can run independently; a parallel_end node is the corresponding join point, where the fork's branches converge and their combined outputs are merged into the shared scope as one entry. Parallel topology is how you fan work out — run several independent steps side by side — and then fan it back in before continuing.

Conditional

A condition node evaluates a rule (or, for advanced cases, an expression) against the chain's current variable scope and routes execution down one of two labelled outgoing connections — conditional_true or conditional_false — based on the result. PromptHub's condition evaluator supports comparison operators (equals, greater_than, less_than_or_equals, and their siblings), string operators (contains, starts_with, ends_with, matches_regex), existence checks (is_empty, is_not_null, and so on), and boolean and collection checks, all evaluated against live values pulled from the chain's variable scope at the moment the condition node runs. A condition node left with no rules configured at all is treated as always-true by the evaluator — a deliberate design choice so an unconfigured condition doesn't silently break the chain by routing nowhere.

The fourth option: Composite Steps

Instead of wiring a dedicated Skill node ahead of an AI-calling node, a single prompt, component, custom, ai_process, or agent node can carry an attached Skill directly — and, specifically on an Agent node, a Prompt as well. Under the hood, PromptHub's chain-node schema carries skillId and agentId as independent optional fields alongside the pre-existing promptId and componentId, so a single node can compose a Prompt's content, a Skill's system-level instructions, and — for the Agent case — an Agent's own tool access, without wiring three separate nodes and threading variables between them by hand.

Passing Data Between Steps

Every chain run carries a single shared variable scope for its whole lifetime: the original input, each node's own output keyed by that node's ID, and a pointer to whichever node ran immediately before the current one. A node's content is resolved against that scope right before it executes, so referencing an earlier step's result is a matter of naming it correctly, not passing it through explicitly as a parameter.

The addressable reference forms are:

{{input.fieldName}} — a field from the chain's original input, unchanged since the run started
{{nodeId.output}} — a specific earlier node's full output, addressed by that node's own ID
{{nodeId.output.fieldName}} — a nested field inside that node's output, when the output is an object
{{previousNode.output}} — whatever the immediately preceding node produced, without needing to know its ID

In practice, a later node's content might look like this before it's resolved:

{{input.customerName}}          -> a field from the chain's original input
{{draft.output}}                -> the "draft" node's full output
{{draft.output.summary}}        -> a nested field on that output
{{previousNode.output}}         -> whatever ran immediately before this node

An unresolved reference — a typo'd node ID, or a field that doesn't exist on that node's output — is left in the string unchanged rather than throwing an error. That means a broken variable reference fails visibly, as literal {{...}} text sitting in your output, instead of crashing the entire run partway through.

Guardrails: What Stops a Chain Running Away

A chain is validated before it ever starts running, and bounded again while it runs.

Before execution starts:

A chain with more than 50 nodes is rejected outright, checked before a ChainExecution row is even created.
Every chain is checked for cycles ahead of time. A chain containing a cycle is rejected with a cycle_detected error naming the cycle path, rather than being allowed to loop.
A user can have at most 3 chain executions running concurrently; a fourth attempt is rejected with a concurrency_limit error.
Nesting depth — the case where a Chain's Agent node calls back into another Chain, which could itself contain another Agent node — is capped at 3 levels, checked before any database read.

While execution runs:

A defense-in-depth execution-count backstop caps any single run at 1,000 total node executions and 10 executions of the same node — a ceiling that today's upfront cycle detection and node-count cap should make unreachable for a well-formed chain, kept as a second line of defence rather than a primary one.
An Agent node's own internal tool-call rounds count against that same total: a chain can't hide unbounded work inside a single Agent node's tool-calling loop and evade the cap that way.
Every run carries a wall-clock execution budget — 4 minutes by default. A run that exceeds it doesn't fail outright; it detaches into a background continuation on the same server process and keeps writing results until it finishes or hits a hard failure.
If a chain is edited or auto-saved while it's still executing, the in-flight run's node references go stale. The engine detects that specific case and fails with a stale_chain_state error asking you to run the chain again, rather than surfacing a raw database error.

Every guard failure carries a structured code — not_found, forbidden, invalid_chain, cycle_detected, execution_limit, insufficient_tokens, concurrency_limit, stale_chain_state — so a calling client, whether that's the dashboard or an MCP tool caller, can handle each case distinctly instead of parsing a free-text error string.

What a Chain Costs

PromptHub bills token-consuming actions — prompt improvement, chain execution, and agent execution alike — against your account's token balance, tracked per plan with configurable feature limits, alongside Stripe, PayPal, and Paddle for top-ups and subscriptions. A chain's node types split into two cost classes: AI-calling nodes (prompt, component, custom, ai_process, agent) spend tokens for their model call, while structural nodes (input, output, condition, transform, parallel_start, parallel_end) cost nothing to execute, and a skill node is pure context injection with no model call of its own — also zero cost.

Before a run starts, PromptHub estimates roughly 500 tokens per AI-calling node in the chain and checks that estimate against your balance; a chain whose estimated cost exceeds your balance is rejected with an insufficient_tokens error before any node executes, not partway through a run you've already started paying for.

An Agent node's cost is billed separately, under the same billing operation its standalone chat turns use, so its tokens are never double-counted into the chain's own per-node total — the node simply reads back an already-completed, already-billed turn result.

Exact per-model rates change as providers update their pricing, so this post won't restate a number that will be stale by the time you read it — see LLM Pricing Compared for the current figures instead.

Single Prompt vs. Prompt Chain vs. Agent

Axis	Single Prompt	Prompt Chain	Agent
Control flow	Fixed — one call, one instruction	Fixed at design time — the chain author sets node order and branches	Decided at runtime — the model chooses its next tool call, up to 5 per turn
Data passing between steps	None — no intermediate state to pass	Explicit shared variable scope every node can read via `{{nodeId.output}}`	Internal to the model's own reasoning within a single turn
Failure containment	The whole call succeeds or fails as one unit	A node can fail without necessarily aborting the run; bounded by cycle detection, execution caps, and a wall-clock budget	A turn fails as a whole once its tool-call cap or budget is hit
Tool access	None	Only its own wired nodes — Prompts, Components, Skills, Agents, sub-chains	Up to 5 tool calls per turn, drawn from Prompts, Chains, Skills, and PlugIn versions
Cost model	Per-call token cost	Per-node token cost, estimated pre-flight and checked against your balance	Per-turn token cost billed separately, composed into the chain's own execution cap when run from an Agent node

As a rule of thumb: reach for a single prompt when one instruction fully specifies the task. Reach for a chain when the task has a fixed number of stages, each of which benefits from its own instruction, its own inspection point, or a branch based on an earlier result. Reach for an Agent when the number and order of steps genuinely can't be known in advance, and the task benefits from letting the model choose its own next action within a bounded tool-call budget.

Building Your First Chain in PromptHub

Open the chain builder and drag an Input node onto the canvas — this is where the chain receives whatever input it's run with.
Drag the node types your workflow needs from the palette: Prompt to reuse a saved prompt, Component to reuse a prompt component, Custom to write inline content, AI Process for an AI call with ad hoc instructions, Skill to inject reusable instructions, Agent to hand a step off to a bounded tool-calling turn, or Condition / Transform / Parallel Start / Parallel End for structural control flow.
Wire connections between nodes to set execution order. For a Condition node specifically, label each outgoing connection as its true or false branch so the router knows which one to follow once the condition evaluates.
Reference an earlier step's output in a later node's content with {{nodeId.output}} — or a nested field on it — so data flows forward automatically instead of being copied by hand between nodes.
Drag an Output node onto the canvas as the chain's exit point, then save. The chain is ready to run from that point on — either from the dashboard or as an MCP tool call, both routed through the same execution engine described above.

When Not to Use a Chain

A chain adds structure a task doesn't always need. Skip it when:

The task is genuinely one step — a single well-written prompt already produces the result you want, and adding nodes only adds places for something to fail.
Latency matters more than structure. Each AI-calling node in a chain is its own model call; a five-node chain is, at minimum, five round trips, not one.
You don't yet know the right structure. Prototype the task as a single prompt first, and split it into a chain only once you can name the actual seams — the points where you'd genuinely want to inspect, branch, or hand off an intermediate result.

A chain that exists because a template offered it, not because the task needed the structure, is harder to maintain than the single prompt it replaced.

A pillar post that only tells you when to add structure isn't giving you the whole picture. Knowing when not to is the other half of using chains well.

If your team runs the same multi-step workflow by hand more than a few times, it's a strong chain candidate — create a free account and build one on your own prompts. For agencies repeating the same client workflow across every engagement, chains are especially high-leverage; see how repeatable chains fit an agency's day-to-day work on the agencies solutions page.