Blocks
Built-in workflow primitives — the core surface of every Scrydon workflow
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.
Annotation
- Note — a resizable plain-text or Markdown note on the canvas; never executes.
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.
The LLM Chat and Agent operations inside the Core block use the same model selector. Leave Organization Default selected to follow organization policy, or choose another enabled model for that step.
How a block works
Finding workflows and blocks
The workflow selector searches names and descriptions and lists recently modified workflows first. Create new workflow and search remain above the scrolling results. Deployment badges name each environment where a copy in the same promotion group is actually deployed; promotion alone is not deployment. A loading or unavailable status is not evidence that a workflow is undeployed.
Pin, reorder or hide toolbar blocks to suit your work. These preferences belong to this browser. Existing inventory is treated as known on first use; blocks discovered later show New for the current platform release. The badge retires on the next distinct release, not after a fixed number of days. No release is guessed when version metadata is unavailable.
Saved model selections are preserved while inventory loads or fails. If the selected model is absent from a successful current inventory, the picker applies its default and tells you. Organization Default continues to follow organization policy. For Create Process Instance, select an installed extension before its template; a sole available option is selected automatically, but multiple options require a choice.
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
Connecting blocks
While dragging a block from the toolbar, a dashed outline previews its canvas position, including adjustments to keep it inside a container. Release to place it there, or press Escape to cancel the drag.
On compact nodes, outputs are on the right: the normal output is near the top and the red error output is near the bottom. Start a connection by dragging a port, or click an output and then the destination input. Condition blocks keep their branch outputs in separate rows above the error output.
Clicking an output shows a preview line until you choose an input. Press Escape or click away from the ports to cancel. Automatic layout keeps ordinary chains on a shared row instead of moving each node to match an offset output port. Branch outputs retain their vertical order, downstream chains inherit the final branch rows, and joins balance their incoming connections. Repeating automatic layout preserves the same positions when the graph and node sizes are unchanged.
The connection indicator in a block's header counts its directly attached lines, not all upstream blocks. Hover or keyboard-focus it to see incoming and outgoing counts separately. Separate lines to the same block each count as a connection.
You wire blocks by dragging from an output port to an input port. One output can fan out to many inputs; some blocks (Condition, Router) have multiple branch outputs. Full reference: Connections.
Common patterns
Sequential
Trigger → Agent → Function → ResponseConditional 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 |