SYSTEM Cited by 2 sources

Vercel Workflow

Vercel Workflow (docs) is Vercel's durable orchestration primitive for background jobs on the Vercel platform. It is the scheduling and step-orchestration surface for multi-step async pipelines. Ships with the Workflow Development Kit (WDK) — the open-source SDK that provides the "use workflow" / "use step" directive language + SWC compiler plugin + per-framework integration packages.

Workflow DevKit (WDK, 2026-04-21 disclosure)

Per Vercel's 2026-04-21 integration-pattern post, WDK ships with 8 frameworks supported as of 2026-04-21:

• File-based-routing family (integrated by dropping generated handlers into framework-specific directories): Next.js (app/.well-known/workflow/v1), SvelteKit (src/routes/.well-known/workflow/v1), Astro, Nuxt.
• Bare-HTTP framework family (integrated via Nitro shim that wraps the user's HTTP server + injects virtual handlers): Express, Hono.
• Nitro itself (launch-supported framework).
• In development: TanStack Start, React Router.

Adoption datum verbatim: "Since launch, the Workflow DevKit has gained over 1,300 GitHub stars, with developers building workflows across all these frameworks."

The compilation architecture

WDK is structured around a single SWC compiler plugin with three transform modes (patterns/swc-plugin-three-mode-transform):

Mode	Phase	Output
Client	Framework's build (Rollup/Vite plugin)	Rewrites workflow calls into HTTP client code + workflowId
Step	WDK's own esbuild phase	Transforms "use step" functions into HTTP handlers
Workflow	WDK's own esbuild phase	Transforms "use workflow" functions into orchestrators

The plugin reads use- directive compilation markers ("use workflow" / "use step") to decide which functions get which transform. Same source file → three deployment artefacts: client stub, step handler, workflow orchestrator.

The two-phase integration pattern

Every framework integration implements the patterns/two-phase-framework-integration-pattern:

1. Build-time — compile user source into handler artefacts. Determine output location per framework. Configure HMR via patterns/vite-hotupdate-directive-triggered-rebuild for Vite-based frameworks.
2. Runtime — expose handlers as HTTP endpoints. File- based-routing frameworks auto-discover; bare-HTTP frameworks use Nitro virtual handlers injected into the user's HTTP server.

Framework-specific request-object shapes get bridged by injected per- handler converter functions, not a fat cross-framework abstraction — e.g. convertSvelteKitRequest for SvelteKit's custom request object.

Original role: corpus-sync orchestrator

(Source: sources/2026-04-21-vercel-build-knowledge-agents-without-embeddings)

Canonical corpus-sync orchestrator in Vercel's Knowledge Agent Template pipeline. The template's five-layer flow:

"You add sources through the admin interface, and they're stored in Postgres. Content syncs to a snapshot repository via Vercel Workflow. When the agent needs to search, a Vercel Sandbox loads the snapshot."

Workflow is the (1) Postgres → (2) snapshot repo transformation layer. Canonical instance of patterns/snapshot-sync-from-postgres-to-repo — async background job transforming live admin-interface source configuration into an immutable snapshot the Sandbox can load per request.

What's disclosed vs what isn't

Disclosed (2026-04-21 integration-pattern post): - 8 supported frameworks + 2 in development - Two-phase integration pattern (build-time + runtime) - Three SWC transform modes (client/step/workflow) - Nitro as substrate for bundlerless-framework shim - Injected request-converter approach for framework adapters - Vite hotUpdate hook + directive-regex gate for HMR - ~90% code reuse across Vite-based frameworks

Undisclosed: - Sandboxed virtual environment for workflow orchestrators is asserted, not described. Isolate model, determinism invariants, replay semantics, deterministic-function requirements — the reliability core of any durable workflow system — are elided. - Actual SWC transform outputs — the post names client/step/workflow modes and roles but doesn't show what the transformed code looks like. - Orchestrator runtime shape — where workflows run, lifetime, scaling, failure recovery. - Per-framework adapter internals beyond SvelteKit's converter snippet.

Seen in

• sources/2026-04-21-vercel-inside-workflow-devkit-how-framework-integrations-work — canonical wiki disclosure of the 8-framework integration pattern, three SWC transform modes, Nitro-shimmed bundlerless-framework integration, injected request-converter approach, Vite HMR hook. Fifth 2026-04-21 Vercel ingest.
• sources/2026-04-21-vercel-build-knowledge-agents-without-embeddings — canonical snapshot-sync orchestrator in the Knowledge Agent Template pipeline.

Related

• companies/vercel
• systems/vercel-knowledge-agent-template
• systems/vercel-sandbox
• systems/nextjs, systems/sveltekit, systems/astro, systems/express, systems/hono, systems/nitro-unjs — supported frameworks.
• systems/vite, systems/rollup, systems/esbuild — build-system substrate.
• patterns/snapshot-sync-from-postgres-to-repo — corpus-sync use case.
• patterns/two-phase-framework-integration-pattern — integration architecture.
• patterns/swc-plugin-three-mode-transform — compiler plugin structure.
• patterns/virtual-handler-via-nitro-for-bundlerless-frameworks — bare-HTTP framework integration strategy.
• patterns/injected-request-object-converter — per- framework request-adapter strategy.
• patterns/vite-hotupdate-directive-triggered-rebuild — HMR integration pattern.
• concepts/use-directive-as-compilation-marker — the "use workflow" / "use step" directive family.
• concepts/build-time-vs-runtime-phase-separation — integration decomposition axis.
• concepts/file-based-routing-vs-bare-http-framework-taxonomy — framework taxonomy shaping the integration bridge.