Blocks

Blocks are the units of execution in a workflow. Each block takes inputs, does one job, and produces output that downstream blocks can use. Chain them together and you get a workflow that’s easy to read, test and debug.

How a block works

Every block has three parts:

• Inputs — values from the workflow payload or a prior block’s output
• Config — the block’s settings (prompt, URL, condition, etc.)
• Output — a structured result the next block can reference

You reference a prior block’s output using {{block_id.output}}. For example, if you have an LLM block with ID summarize, the next block can read its result as {{summarize.output}}.

A simple three-block chain looks like this:

1. Input block — accepts {{inputs.user_query}} from the caller
2. LLM block (summarize) — uses {{inputs.user_query}} in its prompt
3. Text block — shapes the final response using {{summarize.output}}

See Logic and State for full details on how state moves between blocks.

Block categories

Input and output

• Input — defines the runtime payload fields callers must provide
• Text / JSON — shapes or transforms data into a clean output format
• HTTP — calls external APIs and returns the response

AI processing

• LLM / Reasoning — generates text, answers questions, extracts structure
• Web Search / Scrape — pulls live context from the web
• JavaScript — runs custom logic when built-in block config isn’t enough

If a decision needs to be made dynamically at runtime by an agent, use Agent Code Execution instead of a static block.

Control flow

• Conditional / Continue If / Stop If — branch based on a value or condition
• Delay — adds a time-based pause (useful for rate-limited APIs)
• Reduce — iterates over a list and aggregates results

Data and integrations

• Query Collection Table — retrieves documents from Scout’s internal knowledge base
• Save Document to Table — persists workflow output for later retrieval
• Slack / Discord / Twilio / CRM blocks — push actions into external tools

Choosing the right block

A few common trade-offs:

• LLM vs. JavaScript — Use JavaScript when the logic is deterministic and testable. Use LLM when the input is unstructured or requires judgment.
• HTTP vs. integration blocks — Integration blocks (Slack, Twilio, etc.) handle auth and formatting for you. HTTP is for any other API.
• Conditional vs. Stop If — Stop If ends the workflow immediately. Conditional routes to different branches and keeps going.

Block design rules

• Keep each block focused on one responsibility
• Name blocks by what they do, not the tool they use (e.g., fetch_customer not http_1)
• Add guard conditions before expensive or irreversible actions
• Avoid long implicit chains — keep transformations explicit so they’re easy to trace in the Console

Next steps

• Logic and State: Connect outputs safely across blocks
• Jinja Templates: Build dynamic block inputs
• Console: Inspect each block run in real time