Scrydon
Architecture

Agentic

The workflow engine — visual editor, automations, and the runtime that executes everything.

The Agentic subsystem is the workflow product surface. It hosts the visual editor, the agent runtime, Automations, and the chat / voice surfaces customers interact with.

What it does

CapabilityWhere it shows up
Visual workflow editorThe canvas. Blocks, connections, variables, response formats. See Blocks.
Workflow runtimeExecutes workflows on every trigger — chat, API, schedule, webhook. See Execution.
AutomationsSingle-agent jobs on a schedule or webhook. See Automations.
Knowledge basesGrounded retrieval over uploaded documents. See Architecture → Knowledge bases and Knowledge base clearance.
Copilot hostThe "build a workflow by chatting with Copilot" experience. See Architecture → Copilot.
Chat surfaceThe user-facing chat application — agents, document grounding, voice.

Where it sits in the cluster

Agentic runs in the scrydon-agentic namespace. It depends on:

  • Platform — for authentication, authorisation, and integration credentials.
  • Cortex — for every LLM, embedding, and image call. See Cortex.
  • Analytics + Ontology — for managed-table reads and typed-object retrieval.
  • PostgreSQL + pgvector — for workflow state, chat history, and document embeddings.
  • SeaweedFS / S3 — for document blobs and workflow artefacts.

Runtime model

A workflow run is deterministic: the engine builds a dependency graph from your blocks and executes them in topological layers. Independent branches run in parallel; downstream blocks wait for their inputs.

Key runtime concepts:

ConceptWhat it means
Layered executionBlocks run in dependency layers, not one-by-one. Parallel branches actually run in parallel.
Path trackingCondition and Router blocks dynamically prune the execution graph — branches that aren't picked don't run.
Execution contextEach run carries block outputs, active paths, loop / parallel iteration indices, environment variables, and routing decisions.
Execution grantsAuthorisation is evaluated once when the workflow is triggered, then turned into a short-lived server-issued grant that is bound to a single workflow instance. The runtime never trusts identity passed in the payload. See Security → Authorization.

Trigger sources

Workflows can be triggered five ways. The Starter block declares which:

  • Manual — run from the editor.
  • Chat — exposed at a chat subdomain.
  • APIPOST /api/workflows/{id}/execute with an API key. See Execution.
  • Schedule — cron expression. See Schedule triggers.
  • Webhook — vendor-specific (GitHub, Microsoft Graph, …) or generic. See Webhook triggers.

Automations use the same trigger model but skip the canvas: prompt + tools + trigger, that's it.

Real-time / voice

Voice agents run on a separate WebRTC service in the same namespace, optimised for low-latency STT → LLM → TTS streaming. The voice service shares the same authorisation, audit, and integration registry as the rest of agentic. See Architecture → Voice.

Editor connection state

The visual editor stays in sync through a live realtime connection. A small status dot in the top toolbar shows the current state — green (connected), amber (connecting), red (disconnected).

If the connection drops and does not recover within a few seconds, a banner appears across the top of the editor and the workflow becomes read-only: you can still pan, zoom, and inspect blocks, but edits are paused until the connection is restored. This prevents changes from being silently lost while the editor cannot sync them.

The banner includes a Reconnect button that forces an immediate fresh connection attempt. The editor also keeps retrying automatically in the background; once it reconnects, the banner clears and editing resumes. Brief connection blips that recover on their own do not interrupt editing.

On this page

On this page