ID-71 — Vercel async-worker architecture (research, 2026-07-07)

Vercel async-worker architecture — research

Status: RESEARCH. This document surveys and maps; it does not decide and proposes no implementation plan. Owner-requested (S451) because Canonical has no asynchronous worker architecture today and will need one for (a) the OKF producer/consumers (id-132, id-131 downstream) and (b) the headless-agent fleet that starts with goose (id-71) and expands under id-71/id-104. Every capability claim below is date-stamped to a source URL; the Vercel surface is very new (most GA/beta between Oct 2025 and Jun 2026, i.e. post-knowledge-cutoff), so nothing here is answered from model memory. Numbered owner-ratification questions are in §4.

Verification note. Capability claims were checked live against vercel.com docs/changelog on 07/07/2026 (doc last_updated stamps, where present, are cited inline — all fall Apr–Jun 2026). This is a capability survey, not an API-integration spec: no import-and-call empirical check was run, because no Canonical code is proposed here. Any follow-on adoption spec (a TECH.md) MUST run the pre-ratification import-and-call check against the pinned workflow / @vercel/queue / @vercel/connect / vercel (Python) versions before it cites their APIs — per shared-discipline §Empirical verification.

Executive summary (10 lines)

Vercel shipped a full durable-async + agent stack in the last ~9 months: eve (agent framework, beta, launched 17/06/2026), Workflows (durable execution, DevKit public beta since Oct 2025), Queues (durable pub/sub, public beta), Sandbox (ephemeral microVM compute), AI Gateway (one-key model router, zero markup), and Connect (short-lived OAuth/API-key brokering).
eve is the umbrella: agents-as-directories that compile to Vercel Functions and compose Workflows (durable sessions) + Sandbox (code isolation) + AI Gateway (models) + Connect (credentials) + Observability. It is a direct comparator to the goose pilot.
All of it runs on Vercel compute (Functions/Fluid). Canonical’s ingestion pipeline runs on IONOS/Coolify VPS, not Vercel — so adoption forces a “what runs where, what crosses the boundary” decision on every workload.
Workflows fits the orchestration shape well (durable, sleep-for-months, hooks, auto-retry, no max run duration) but each step is a Vercel Function bounded by Functions limits — heavy cocoindex compute cannot move into a step; it stays on the VPS and a step calls it over HTTP.
The strongest genuine fit is the headless-agent fleet (goose/eve), not the pipeline: eve/Workflows natively deliver the strawman’s missing affordances A23 scheduled/ triggered delivery and A22 batch-propose→human-confirm (hooks).
The hard blocker is egress + isolation, not capability. Vercel Workflows stores step inputs/outputs in Vercel-managed persistence; AI Gateway routes prompts through Vercel infra; Sandbox runs code on Vercel. All put Vercel into the client-data path — in direct tension with the zero-egress discipline (Raindrop precedent) and DR-017 (per-client goose on the client’s own VPS, “your data never shares a machine”).
Connect ≠ private networking. Connect brokers outbound third-party credentials (Slack/Snowflake/etc.). Reaching Canonical’s private VPS pipeline from Vercel is a Secure Compute concern (static IP / VPC peering / PrivateLink — Enterprise-only, and PrivateLink/peering are AWS-shaped, not IONOS).
Costs are usage-metered and modest at pilot scale but multiply per-tenant: Workflows $0.02/1K events + $0.50/GB written + Functions compute; Queues ~$0.60/1M ops; Sandbox $0.128/vCPU-hr active; AI Gateway zero-markup pass-through + $0.10/1K for team-wide ZDR.
Two credible in-house baselines already align with the isolation promise: Supabase Queues (pgmq) + pg_cron + Edge Functions (data never leaves the client’s own Supabase project), and redis/BullMQ on the existing client VPS (full control, ops burden). The status quo is Coolify scheduled tasks (loopback cron → /walk).
Recommendation shape (not a decision): treat Vercel’s stack as a strong candidate for the app-side agent fleet (id-71 headless surface) and a poor fit for the per-client pipeline (id-132 producer) on egress/isolation grounds — but the vendor-lock-in and client-data-egress postures in §4 are owner rulings, not research conclusions.

1. How the Vercel pieces fit together

Six products, one composition story. eve sits on top; Workflows/Queues/Sandbox/AI Gateway/Connect are the primitives it (and you, directly) compose. Common substrate: everything executes on Vercel Functions / Fluid compute — none of it is a worker you run on your own box.

1.1 eve — the agent framework (the umbrella)

What it is (src: vercel.com/blog/introducing-eve, /docs/eve last_updated 19/06/2026; launched 17/06/2026 at Vercel Ship London, public beta, Apache-2.0, npm eve): a filesystem-first framework for durable backend AI agents. An agent is a directory (agent/ — instructions.md, agent.ts, tools/, skills/, channels/, connections/, a sandbox). The minimal agent is two files. eve compiles the directory to an app that runs on Vercel Functions.
Execution model: durable sessions (stream NDJSON lifecycle events, resume after cold start / deploy / long pause) backed by Workflow; tools are typed actions; skills are lazy-loaded procedures; Agent Runs dashboard for sessions/turns/tokens/timing.
Composition: Workflow (session state + resume) · Sandbox (code isolation) · AI Gateway (model routing, openai/gpt-5.4-mini-style strings, OIDC auth so no provider keys) · Connect (OAuth/API-key brokering) · Observability.
Maturity signal: Vercel runs 100+ of its own agents on eve in production (e.g. d0, an internal data analyst, ~30k questions/month, per-asker permission scoping) — src: thenewstack.io, infoq.com, techtimes (18/06/2026). Real, but beta; APIs may change before GA.
Canonical relevance: this is the most direct comparator to the goose pilot (id-71 G0–G6). goose = an off-the-shelf headless runtime on a cron hitting our remote-MCP; eve = a Vercel-native fleet that would replace both the runtime and the cron/delivery plumbing goose G4 is currently stuck on.

1.2 Vercel Workflows — durable execution

What it is (src: /docs/workflows last_updated 17/06/2026; /blog/introducing-workflow; DevKit open-sourced + public beta since Oct 2025, github.com/vercel/workflow, workflow-sdk.dev): durable functions in TS/JS and Python (beta). 'use workflow' / 'use step' directives (TS) or @wf.workflow / @wf.step (Python). No YAML/state machines — plain async code.
Execution model: each step is an isolated route that auto-persists progress and auto-retries (3× default) on transient failure without re-running the whole workflow. Sleep pauses minutes→months with zero compute while suspended. Hooks wait for external events (webhooks, human approval) and resume on resume(token). Deterministic replay survives deploys/crashes. Runs on Vercel Functions + Vercel Queues + managed persistence (Vercel stores all state + event logs).
Fan-out: parallelism is ordinary async (Promise.all over steps); child workflows are the recommended decomposition for long/large runs.
Hard limits (src: /docs/workflows/pricing last_updated 16/06/2026): 10,000 steps/run, 25,000 events/run (perf degrades >2,000), 50 MB max payload, 2 GB entity storage/run (perf degrades >1 GB), max replay 240 s, concurrency up to 100,000, no max run duration, no max sleep duration. Individual step runtime = Vercel Functions limits (this is the ceiling that matters for heavy work). Run creations 1,000/s; events 200/run/s.
Pricing: Workflow Events $0.02/1K (50k/mo free on Hobby) · Data Written $0.50/GB (1 GB free Hobby) · Data Retained $0.50/GB-month (Pro on-demand; not on Hobby). Functions invoked by steps are billed at normal compute rates (Fluid recommended). Queues usage billed separately. Post-completion retention: Hobby 1d / Pro 7d / Enterprise 30d.
Maturity: DevKit public beta; no confirmed GA date as of Jul 2026; pricing “may change at GA with notice”; Python workflow support explicitly beta (src: /docs/workflows/python last_updated 16/04/2026).

1.3 Vercel Queues — durable pub/sub

What it is (src: /docs/queues, /docs/queues/pricing last_updated 06/04/2026; /changelog/vercel-queues-now-in-public-beta, public beta): durable event-streaming — publish to topics, independent consumer groups process in parallel (push or pull), with retries, sharding, delivery guarantees. @vercel/queue Node SDK. It is the substrate under Workflows.
Execution / guarantees: messages durably written to 3 availability zones, approximate write ordering. Push-mode delivers to your Function (Notify op). SDK auto-extends the lease (visibility timeout) while the handler runs.
Limits: retention 60 s–7 d (default 24 h) · delay-before-visible 0–7 d · visibility timeout 0–60 min (default 60 s) · messages/receive 1–10 · max concurrency unlimited · max message size 100 MB · unlimited topics/consumer groups. Retry: configured delay for first 32 attempts, forced backoff after.
Pricing: billed per API operation, metered in 4 KiB chunks (~$0.60/1M ops per the changelog); five op types (Send/Receive/Delete/Visibility-change/Notify); idempotency-key sends and max-concurrency push billed 2×. Push-mode Functions at Fluid rates.

1.4 Vercel Sandbox — ephemeral untrusted-code compute

What it is (src: /docs/sandbox, /docs/sandbox/pricing, /changelog/run-untrusted-code-with-vercel-sandbox, github.com/vercel/sandbox): ephemeral, isolated microVMs on Fluid compute for running untrusted / AI-generated code. @vercel/sandbox SDK.
Limits: runtime max 45 min (Hobby) / 24 h (Pro+Enterprise), default 5 min.
Pricing: Active-CPU model — $0.128/vCPU-hr billed only while CPU is active + $0.0212/GB-hr memory for full wall-clock. Hobby monthly free allotment; Pro usage against the $20/mo credit.
Canonical relevance: only relevant if agents need to execute generated code (e.g. a future analysis agent). Not relevant to the cocoindex pipeline. It would run code on Vercel, not the client box — same isolation tension as everything else.

1.5 Vercel AI Gateway — one-key model router

What it is (src: /docs/ai-gateway, /docs/ai-gateway/pricing last_updated 20/06/2026): one API for hundreds of models with routing, fallbacks, provider preferences.
Pricing / data: zero markup — provider list price, including BYOK (zero markup, paid tier). $5/mo included credits per team. Observability, spend monitoring, retries, load-balancing, fallback, BYOK all no extra charge. Zero Data Retention (ZDR): per-request free, team-wide $0.10/1K requests (Pro/Enterprise) — routes only to providers that agreed not to retain/train on prompt data. Team-wide provider allowlist $0.10/1K; per-request only filter free.
Canonical relevance: could consolidate model access + give per-tenant spend observability, but inserts Vercel into the client-data (prompt) path. The platform already calls Anthropic directly from the pipeline; AI Gateway would add an intermediary. ZDR mitigates provider retention, not Vercel transit — a §4 decision.

1.6 Vercel Connect — credential brokering (NOT private networking)

What it is (src: /docs/connect, /blog/introducing-vercel-connect, /kb/guide/vercel-connect): issues short-lived, user-authorized OAuth tokens / API keys on demand so secrets never live in the runtime. Register a connector once, link to a project, request a token at call time via the deployment’s OIDC identity; SDK auto-refreshes; every token request is audit-logged. For calling outbound third-party APIs (Slack, GitHub, Snowflake, Salesforce) from agents.
Important distinction: Connect does not connect Vercel to your private backend. Reaching Canonical’s private VPS pipeline from Vercel Functions is Secure Compute (src: /docs/connectivity/secure-compute, /docs/networking/privatelink): dedicated static egress IPs, VPC peering, AWS PrivateLink — Enterprise feature, and peering/PrivateLink are AWS-shaped (Canonical’s boxes are IONOS). The realistic Vercel→VPS path stays public bearer HTTPS (exactly today’s /walk posture) — no egress reduction, no new private-network product.

2. Platform fit — what runs where, what crosses the boundary

The load-bearing constraint: every Vercel product above runs on Vercel Functions/ Fluid. Canonical’s ingestion pipeline runs on the client/Platform VPS (IONOS/Coolify), writing the client’s own Supabase project (deployment-architecture.md §2). The Next.js app is on Vercel; the pipeline is not. So “adopt Vercel Workflows” always resolves to one of:

(O) Orchestrate-only: the workflow runs on Vercel and calls the VPS pipeline over HTTP (/walk, /extract bearer endpoints); heavy compute stays on the VPS. Crosses the boundary: a control call out + a completion webhook back (already the pipeline-runs/record shape). Step duration is fine because the step just triggers + polls, not does the walk.
(M) Move compute: re-home the workload onto Vercel compute. Blocked for cocoindex (Python incremental pipeline, Docling, long walks, per-client Supabase) and squarely against DR-017/zero-egress.

Workload	Today	Vercel-fit verdict (research, not decision)
OKF producer (id-132; Python cocoindex, DR-018 chains it off a successful walk with `source_documents` deltas)	Coolify container on the VPS, writing the client Supabase + client git repo	Poor fit to move; marginal to orchestrate. The producer is heavy Python close to the client DB and the client-owned git repo. Workflows could orchestrate the post-walk trigger (a durable “walk done → run producer → publish gate” state machine with hooks for the human review bridge), but the trigger is already DR-018/{132.16} and lives naturally VPS-side. Moving producer compute to Vercel violates DR-017 isolation + adds egress.
OKF consumers (downstream of L-concepts)	Not built	Depends on the consumer. App-side consumers (search/browse, id-135) are already on Vercel and could use Workflows for durable multi-step jobs. VPS-side/DB-side consumers keep the pipeline pattern.
goose recipe delivery (id-71 pilot; cron → remote-MCP; G4 bind-mount blocker, zero AI spend yet)	`kh-goose-pilot` container on Server B, staging-pointed	Strong fit — direct comparator. eve/Workflows natively provide the durable session + scheduled delivery + human-gated hook that goose G4 is hand-rolling. But DR-017 says per-client goose on the client’s own VPS — an eve fleet on Vercel is the opposite topology. This is the sharpest strategic fork in the doc.
id-71 tool-surface workflows (strawman §B HA variants: W3.x trust sweeps, W4.x briefings, W5.x watch-agents, W6.x expiry sweeps, W9.x onboarding)	None (surface #4 unbuilt)	Genuine capability fit. These HA variants are exactly the strawman’s missing affordances A23 scheduled/triggered delivery and A22 batch-propose→human-confirm — which Workflows hooks + sleep + cron implement directly. All are read-anything / propose-writes / human-gates-publication (the strawman standing rule), so egress is app→model, not pipeline→Vercel. Best-aligned Vercel use-case.

Boundary summary. The clean fit is the app-side headless-agent surface (goose/eve replacement + the id-71 HA workflows), where the data already flows app↔model and Vercel is already in the path. The pipeline (id-132 producer, id-131 L-records) is the wrong place for Vercel workers — it is per-client, VPS-resident, Supabase-adjacent, and governed by DR-017/DR-025. The one nuance is that a Vercel-hosted eve fleet is multi-tenant Vercel infra, which is the inverse of DR-017’s per-client-box ruling even for the agent layer — so even the “good fit” carries an isolation decision (§4 Q2).

3. Alternatives baseline (honest trade-offs, not advocacy)

Four ways to get an async worker layer. Scored on the axes that matter here: client-data isolation, ops burden, durability/retry, fit to existing stack, per-tenant cost shape.

Option	What it is	Isolation / egress	Ops burden	Durability & primitives	Stack fit	Cost shape
Vercel Workflows / eve	Durable execution + agent fleet on Vercel Functions	Weakest — state in Vercel persistence, prompts via AI Gateway, code in Vercel Sandbox; multi-tenant Vercel infra (vs DR-017)	Lowest — fully managed, no infra to run	Strongest — durable replay, sleep-months, hooks, auto-retry, observability out of the box	App-side: native (Next.js already on Vercel). Pipeline: alien (VPS/Python)	Usage-metered, multiplies per tenant; needs Pro/Enterprise for ZDR + Secure Compute
Supabase Queues (pgmq) + `pg_cron` + Edge Functions	Postgres-native queue + cron + serverless in the client’s own Supabase project	Strongest — data never leaves the client DB; nothing new in the client-data path	Low–medium — already operate Supabase per tenant; pgmq/pg_cron are extensions to enable	Medium — durable messages + scheduled jobs + retries; no month-long sleep/replay/agent-session primitives	Excellent — the platform is Supabase-per-tenant already; aligns with DR-023/DR-025 (client-owned store)	Bundled into existing Supabase cost; scales with the DB you already pay for
redis + BullMQ on the existing VPS	Self-hosted job queue beside cocoindex on the client/Platform box	Strong — stays on the client box (DR-017-aligned); no third party	Highest — run/secure/monitor redis per client; you own failure modes	Strong — mature retries, delays, repeatable jobs, rate-limiting, flows	Good — co-located with the pipeline it would drive; Node/TS like the app	Infra cost per VPS (RAM — Server B is 4 GB); engineering time
Coolify scheduled tasks (status quo)	Cron-in-Coolify curling loopback `/walk` (built, `enabled:false` pre-cutover)	Strongest — loopback inside the box, no egress	Lowest — already built	Weakest — no fan-out, no durable retry/replay, no orchestration, no human-gate primitive	Native — it is the current design (DR-018 producer trigger rides this)	~Free

Reading: the status quo already covers the simple recurring trigger (walk → producer). The gap it doesn’t cover is fan-out + durable multi-step + human-in-the-loop + scheduled delivery — which is the id-71 headless-agent surface, not the pipeline. For that gap, the isolation-aligned in-house options are Supabase Queues/pg_cron (if the work is DB-close) and BullMQ-on-VPS (if it’s compute-close); the managed-convenience option is Vercel Workflows/eve at the cost of putting Vercel into the client-data path.

4. Decision surface — owner ratification required

RESEARCH stops here; these are owner rulings (candidates for the decision register), not research conclusions.

Vendor lock-in posture. Vercel’s stack is cohesive but proprietary and beta (eve/Workflows/Queues all pre-GA; APIs “may change before GA”). The durable-execution pattern is portable in principle (Temporal, Inngest, Restate are comparators) but eve’s agent fleet is Vercel-specific. How much lock-in to the Vercel platform is acceptable for the agent layer — thin-and-swappable (Workflows only, behind our own interface) vs all-in (eve fleet)?
Client-data egress vs the zero-egress discipline + DR-017. This is the crux. Vercel Workflows persists step inputs/outputs (potentially client content) in Vercel-managed storage; AI Gateway routes prompts through Vercel; Sandbox runs code on Vercel; even a Vercel-hosted eve agent fleet is multi-tenant Vercel infra — the inverse of DR-017 (“per-client goose on the client’s own VPS; the agent processing a client’s knowledge and its API spend lives on that client’s box”). The Raindrop precedent (platform-context.md §8) permanently excluded a hosted eval tool from the client-data path. Does the same exclusion apply to Vercel’s worker/agent infra — and if partially, where is the line (e.g. app-side agents on Vercel OK, pipeline never; or ZDR + Secure Compute makes app-side acceptable; or per-client Vercel projects required)?
Cost ceiling and per-tenant multiplication. Pilot-scale cost is modest (Workflows $0.02/1K events + $0.50/GB + Functions; Queues ~$0.60/1M ops; AI Gateway zero-markup), but ZDR (Q2’s mitigation) needs Pro/Enterprise and team-wide ZDR is $0.10/1K requests, and Secure Compute (private VPS reach) is Enterprise-only — and everything multiplies per client tenant. What is the cost ceiling, and is it modelled per-tenant (each client a Vercel project) or platform-wide?
Timeline coupling to id-13 completion.* The agent fleet (id-71 goose → eve) is explicitly gated on the id-13* spec chain completing (goose recipe delivery is the continuation-prompt focus; DR-017 per-client rollout is post-pilot). Vercel’s surface is beta today and will likely GA during that window. Do we (a) hold, run the goose pilot to G6 on the current DR-017 topology, and re-evaluate eve at GA; (b) pivot the pilot to eve now (beta risk); or (c) split — Workflows for app-side id-71 HA workflows now, goose/DR-017 for the per-client fleet unchanged?
Where the boundary sits for any pipeline orchestration. If Workflows is adopted at all near the pipeline, is it strictly orchestrate-only (Vercel triggers the VPS over bearer HTTPS, VPS does the work, webhook back — no client bytes in Vercel persistence), or is any step allowed to handle client records? Q5 is the concrete guard-rail that makes a “yes” on Workflows compatible with a “no” on egress.

Provenance

All claims checked live on 07/07/2026 against: vercel.com/docs/eve (19/06/2026) · /blog/introducing-eve · /docs/workflows (17/06/2026) · /docs/workflows/pricing (16/06/2026) · /docs/workflows/python (16/04/2026) · workflow-sdk.dev · github.com/vercel/workflow · /docs/queues · /docs/queues/pricing (06/04/2026) · /changelog/vercel-queues-now-in-public-beta · /docs/sandbox + /docs/sandbox/pricing · /docs/ai-gateway + /docs/ai-gateway/pricing (20/06/2026) · /docs/connect + /blog/introducing-vercel-connect + /kb/guide/vercel-connect · /docs/connectivity/secure-compute + /docs/networking/privatelink. Internal anchors: reference/deployment-architecture.md, reference/platform-context.md, reference/decision-register.md (DR-017/DR-023/DR-025/DR-026), the id-71 Lane A workflow strawman, and continuation-prompts/…-s435-id71-goose-recipe-delivery.md.

End of research. Nothing above is decided.