Scrydon (built-in)
Platform-native products — knowledge, memory, storage, tables, workflow orchestration, and the core agent toolset
Vendor ID: scrydon · Maturity: preview · scrydon.com · Docs
The scrydon vendor is the platform's built-in integration. It has no external auth — every product runs against Scrydon's own services. These products are always available; they are also what most workflows lean on most.
Auth
| Credential | Notes |
|---|---|
none | Built-in. Tools authorize through the workflow's session, not an external credential. |
a2a | Outbound A2A agent API key, or a JSON authentication descriptor for API key, Basic, bearer, OAuth 2.0, or OpenID Connect. |
Products
Knowledge
ID: scrydon:knowledge — RAG search and document grounding against the workspace knowledge base.
Tools include knowledge-rag-search, semantic and lexical retrieval, citations, and per-document DAC checks (clearance + grant).
Memory
ID: scrydon:memory — agent-scoped memory store.
Add, update, list, and recall memories in conversation- or workflow-scoped namespaces.
Storage
ID: scrydon:storage — ACL-enforced file and folder access to organization and workspace storage.
Read, write, list, search, and delete files. Backs the Karpathy-style agent loop where the agent's "filesystem" is the workspace storage.
The Storage block on the canvas exposes these tools through an Operation dropdown:
| Operation | Tool | What it does |
|---|---|---|
| Read File | storage-read | Read one file by its full storage path |
| Read Folder (all files) | storage-read-folder | List a folder prefix and read every file under it in one step (default 20 files, max 50) |
| List Paths | storage-list | List the storage paths under a folder prefix |
| Search Files | storage-search | Full-text search across files under a prefix |
| Write File | storage-write | Create or overwrite a file with text content |
| Delete File | storage-delete | Delete one file |
The file and folder fields are searchable selectors. They list only the files in the block's selected Scope (see below) that the current user's storage ACL allows. You can pick from the list, type a name relative to the scope (e.g. test.txt writes to the scope's folder — handy for creating a new file), or paste a full path (00_organization/… or 02_workspaces/…). Relative names are resolved under the scope at run time; a full path is used as-is. You can copy a file's exact path from Settings → Storage in the platform app — each row in the organization and workspace file browsers has a Copy path action.
Write File outputs path, the full storage path of the file it wrote — reference it from a downstream block (for example a Read File block's File field) to chain a write into a read. Read Folder returns files (path, content, mimeType per file) plus a skipped list for files the executing principal was not allowed to read — a partially readable folder does not fail the step.
Scope (Workspace or Organization)
Every Storage block declares a required Scope — Workspace (the default) or Organization — instead of a hand-typed path:
- Workspace confines the block to the running environment's shared files (
02_workspaces/<workspace>/<environment>/shared/). - Organization confines it to org-wide files (
00_organization/).
The File / Folder list shows only files in the chosen scope, so you can't accidentally pick a file the block will then refuse. There are no workspace or environment ids to look up — the Workspace scope is resolved to the correct path at run time from the environment the workflow actually runs in, so the same workflow stays correct when deployed to a different workspace environment.
This is a defense-in-depth control: the scope is resolved and enforced server-side at run time on a trusted channel the agent cannot alter, so even if an AI agent step is steered toward a different path (for example by a prompt-injection attempt in a document it read), an out-of-scope request is still refused. If a Workspace-scoped block runs where the workspace can't be determined, the operation fails closed with an explicit error rather than reaching any path.
A few practical rules: the comparison is case-sensitive and respects folder boundaries (a scope of ws1/ does not admit ws10/); parent-directory segments (.., including URL-encoded forms) are always refused; and a scope value that itself contains .. denies every request rather than widening access — fix the scope value if you see every operation refused.
Tables
ID: scrydon:tables — managed structured tables.
Create, write, query, get schema, delete. Powers structured data without provisioning a database.
Workflow
ID: scrydon:workflow — orchestrate sub-workflows from a parent workflow.
Use the Workflow block on the canvas, or call the executor tool directly to run another workflow as a step.
Web
ID: scrydon:web (fetch-webpage) — SSRF-protected web fetch.
Returns content as HTML, Markdown, or text. The runtime enforces an egress allowlist and blocks RFC 1918 / link-local addresses.
Email (SMTP)
ID: scrydon:smtp — send email through any SMTP server.
Useful when the workspace doesn't have a Gmail / Outlook integration installed but still needs outbound email.
SMS
ID: scrydon:sms — outbound SMS via the platform's Twilio-backed messaging service.
Guardrails
ID: scrydon:guardrails — content validation gates.
JSON, regex, and PII checks an agent step can fail-closed on. Pair with the Evaluator block for quality gating.
Search
ID: scrydon:core-search — web search through the platform web-search capability.
The Search block's Search Integration selector lists your organization's enabled web-search integrations — the built-in provider (Google Custom Search) plus any pack-installed integration whose search product declares the web-search capability (e.g. Tavily). Pick one explicitly, or use Organization Default. Organization admins set that default under Settings → Platform Defaults → Default Web Search, where Select Automatically lets the platform choose (stored as the platform.defaultWebSearchIntegration policy). No API key on the block — credentials always resolve server-side from the integration connection.
If no web-search integration is enabled for the organization, the selector shows a red configuration error telling you to ask an admin to install one — and executions fail with a configuration hint (HTTP 412) until one is configured.
A2A
ID: scrydon:a2a — Agent-to-Agent protocol.
Talk to external Scrydon-compatible agents over the A2A wire format.
The integration speaks A2A 1.0 over JSON-RPC and HTTP+JSON, with optional v0.3 compatibility. It exposes the full discovery, messaging, streaming, task, subscription, push-configuration, and extended-card surface. See A2A agents for publishing, authentication, operation, and security details.
SSH
ID: scrydon:ssh — execute commands and manage files on remote servers.
Use a secret-store-backed credential; commands run inside the integration sandbox.
Generic
ID: scrydon:generic — primitives for outbound webhook calls and other patterns that don't fit a vendor product.
Core
ID: scrydon:core — the toolset behind core blocks (function execute, etc.). You won't usually invoke these directly — they back the Function / API / Agent core blocks.
Capabilities
The Scrydon vendor doesn't ship LLM / STT / TTS / embedding capabilities itself — those resolve through the capability registry against installed AI vendors (OpenAI, Anthropic, Mistral, Bedrock, Vertex, Foundry, Ollama, vLLM).
Where to next
- Knowledge bases — DLP and clearance for the Knowledge product
- Authoring integrations — author vendors that complement these built-ins