Blocks

Blocks are the cards you drop on the canvas to build a workflow. Scrydon ships two kinds:

Core blocks (this page) — built-in workflow primitives that are always available: Agent, API, Function, Condition, Router, Evaluator, Response, plus the control-flow blocks Loop and Workflow.
Integration blocks — vendor-provided blocks that come from installed integrations. Each integration's product contributes one or more blocks (e.g. Gmail → "Send mail", Sheets → "Read range"). See Vendors for the catalog and Integrations for how blocks are defined.

Core blocks

Processing

Agent — call an LLM. Models resolve through the integration registry — never hardcoded.
Function — run sandboxed JavaScript / TypeScript.
API — make an HTTP request to anything reachable from the workflow runtime.

Logic

Condition — branch on a boolean expression.
Router — let an LLM pick which downstream branch to take.
Evaluator — score / classify content with an LLM.

Control flow

Loop — iterate over a list or until a condition is met.
Workflow — invoke another workflow as a sub-workflow.

Output

Response — format and return the final result.

Agent

Create powerful AI agents using any LLM provider with customizable system prompts and tool integrations.

API

Connect to any external API with support for all standard HTTP methods and customizable request parameters.

Condition

Add a condition to the workflow to branch the execution path based on a boolean expression.

Function

Execute custom JavaScript or TypeScript code within your workflow to transform data or implement complex logic.

Router

Intelligently direct workflow execution to different paths based on input analysis.

Evaluator

Assess content using customizable evaluation metrics and scoring criteria across multiple dimensions.

Response

Send a response back to the caller with customizable data, status, and headers.

Where integration blocks come from

Integration blocks are never hand-rolled in workflow YAML. They are contributed by vendor products and resolved through the platform's integration registry:

Vendor (e.g. google)
  └── Product (e.g. gmail)
        ├── Block         ← "Gmail" card on the canvas
        ├── Tools         ← send-mail, list-messages, get-message, …
        └── Capabilities  ← (LLM/STT/TTS/Embedding/etc., when applicable)

So a "Send Gmail" block isn't a separate top-level concept — it's the workflow surface of google → gmail → block, with google → gmail → tools.send-mail doing the actual work. Switching the integration off (org policy, missing credential) removes the block from the canvas without touching workflow code.

The Agent, Router, and Evaluator blocks all resolve their model through the integration registry too — they pick whichever LLM-capable vendor (OpenAI, Anthropic, Mistral, Bedrock, vLLM, …) is installed and selected by org policy. There is no model: "gpt-5.4" constant in the block; the block names a capability and the registry resolves it.

How a block works

Each block has three layers:

Inputs — data flowing in from connected blocks Configuration — fields the author fills in (subBlocks: model picker, system prompt, headers, …) Outputs — typed data the block produces, available to downstream blocks via connections

Receive input — from upstream blocks or the workflow trigger

Process — apply configuration and run the block's logic. For integration blocks this dispatches to vendor → product → tool.execute() inside the sandbox.

Emit output — typed JSON that downstream blocks reference

Trigger → Agent → Function → Response

Conditional branching

Trigger → Router → Agent A (questions)
                 → Agent B (commands)

Quality gate

Agent → Evaluator → Condition → Response (if good)
                               → Agent (retry if not)

Configuration cheat sheet

Block class	Common config
All	timeout, error-handling branch
LLM-using (Agent, Router, Evaluator)	capability selector (LLM model resolves via registry), system prompt, temperature, tool allowlist
Logic (Condition, Function)	expression / code, sandbox env vars
Network (API)	URL, headers, auth, request body, response parsing
Control flow (Loop, Workflow)	iteration source, target workflow id
Integration blocks	provided by the vendor product — see Vendors