Vendors

A vendor is a third-party (or first-party) system Scrydon talks to — Google, OpenAI, Salesforce, Mistral, the built-in scrydon core, and so on. Every block, tool, and runtime capability you can use in a workflow is exposed by a vendor.

The model

Vendor                    e.g. google, openai, scrydon
└── Product               e.g. gmail, sheets, drive — one per vendor area
      ├── Block           workflow-editor card (one per product)
      ├── Tools           individual operations the agent can call
      ├── Triggers        webhook + polling triggers
      └── Capabilities    runtime contracts: LLM, STT, TTS, embeddings, image, video, OCR, webhooks, discovery

A workflow that "sends a Gmail" is using vendor=google → product=gmail → tool=send-mail. The "Gmail" card on the canvas is google → gmail → block. The platform's extension registry resolves all of this — you never hardcode vendor names in workflow code.

Catalog

Built-in (always available)

Productivity & Storage

AI & LLMs

Cloud

Observability

Isolation tiers

A vendor definition may declare how the platform isolates its archive at runtime:

defineExtension({
  // ...
  isolation: "microvm", // optional — defaults to "memory"
})

• memory (legacy default declaration) — the manifest does not strengthen the deployment/organization minimum. The shared resolver still binds execution to microvm or managed_process; it never means an in-process Worker Thread.
• microvm — the archive requires a dedicated microVM. If that tier is not permitted, proven, and ready, execution is refused; there is no downgrade.

The manifest field is a minimum-isolation declaration, not a backend selector. Administrators can see the effective execution tier in the audit log.

Where vendors come from

Both paths produce the same kind of artifact (a defineExtension() definition); the only difference is where the archive is stored.

Capability resolution (LLM, STT, TTS, embeddings, …)

Capabilities are resolved through the extension registry, in this order:

1. Per-call override (e.g., a block setting that pins one model)
2. Org policy (defaults configured by an admin)
3. Automatic pick across installed candidates (first that matches the requested capability)
4. null — callers translate this to HTTP 412 ("no provider configured")

Capabilities resolve through your installed extensions — no vendor is hardcoded and no silent fallback occurs. Speech-to-text requests are brokered server-side by the platform (credentials never leave the server); other capabilities (LLM, embedding, OCR) resolve through your installed extensions at request time. Never import a vendor SDK directly in product code, never hardcode a vendor branch, never silently fall back to a vendor the org didn't install.