Help us improve
Share bugs, ideas, or general feedback.
From vercel
Use Vercel's three agentic-infrastructure primitives together — Sandbox (sandboxed code execution from agent tools), Vercel Agent (hosted agentic runtime with built-in state and tools), and Workflows (durable execution for multi-step processes that survive restarts, retries, and human approvals). Use this skill any time agents need to execute generated code safely, when long-running multi-step processes need durability, when "this needs to run for hours / wait for a human / retry on failure" comes up, or when an existing serverless-function approach is straining under workflow complexity. Trigger on any agentic-infrastructure question on Vercel.
npx claudepluginhub bpainter/composable-dxp-claude-marketplace --plugin vercelHow this skill is triggered — by the user, by Claude, or both
Slash command
/vercel:vercel-agent-runtimeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Three agentic primitives that go together. **Sandbox** runs untrusted or LLM-generated code safely. **Vercel Agent** is the hosted runtime for agents-as-services with state and tools. **Workflows** is durable execution — functions that survive restarts, do retries, wait for humans, and run for days.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
Three agentic primitives that go together. Sandbox runs untrusted or LLM-generated code safely. Vercel Agent is the hosted runtime for agents-as-services with state and tools. Workflows is durable execution — functions that survive restarts, do retries, wait for humans, and run for days.
This skill covers all three. Pair with vercel-ai-sdk (LLM calls inside the agent), vercel-ai-gateway (model routing for the LLM), vercel-fluid-compute (function config — Workflows have different limits than vanilla functions), vercel-storage (state across steps), vercel-observability (trace agent / workflow execution), and software-engineering-agentic-workflow-engineer for the application-side multi-agent architecture.
A sandboxed Node execution environment you can call from your code. Designed for agent tools — when an LLM generates code (or a user submits it) and you need to run it without exposing your real server.
import { Sandbox } from "@vercel/sandbox";
// Inside an AI SDK tool's `execute`:
const codeSandbox: tool({
description: "Run Python or JavaScript code and return the output",
parameters: z.object({
runtime: z.enum(["python", "javascript"]),
code: z.string(),
}),
execute: async ({ runtime, code }) => {
const sandbox = await Sandbox.create({ runtime });
const result = await sandbox.run(code, { timeout: 30_000 });
return { stdout: result.stdout, stderr: result.stderr, exitCode: result.exitCode };
},
});
Use cases:
Don't use Sandbox for:
Verify current pricing and limits — Sandbox is metered separately from regular functions.
Docs: https://vercel.com/sandbox
The hosted runtime for agents-as-services. Vercel Agent gives you:
When to reach for Vercel Agent vs. building your own AI SDK + Workflows + storage stack:
For Slalom defaults: try Vercel Agent first for hosted-agent use cases (a chat assistant for a client's product); fall back to the AI SDK + Workflows pattern for bespoke multi-agent orchestration.
Verify the API shape against current docs at https://vercel.com/agent — this is a newer surface and evolving.
Durable execution. A workflow is a function that:
// Pseudocode shape — verify against current Workflows SDK
import { workflow, step } from "@vercel/workflows";
export const onboardCustomer = workflow("onboard-customer", async (input: { customerId: string }) => {
const customer = await step("fetch", () => fetchCustomer(input.customerId));
await step("send-welcome-email", () => sendEmail(customer.email, "welcome"));
// Wait for human approval before continuing
await step("wait-for-approval", () =>
waitForEvent("manual-approval", { customerId: input.customerId, timeout: "7d" }));
// Long-running computation — workflow survives function restarts
const enrichment = await step("enrich", () =>
enrichCustomerData(input.customerId));
// Branch based on result
if (enrichment.tier === "enterprise") {
await step("notify-account-team", () => notifyAccountTeam(input.customerId));
}
await step("mark-onboarded", () => updateCustomer(input.customerId, { onboarded: true }));
});
What this gets you:
step is durable. If the function dies during step 3, on resume the workflow picks up at step 3 with steps 1 and 2 already completed.waitForEvent is durable. Workflow can sleep for 7 days waiting for human approval. The function isn't running during the wait; it resumes when the event arrives.When to reach for Workflows:
When to skip:
Docs: https://vercel.com/workflows
Common patterns:
User prompt → AI SDK chat → tool call: "run this Python"
↓
Sandbox runs the code
↓
Result feeds back to the LLM
↓
LLM responds to user
Sandbox is a tool; the AI SDK orchestrates.
Trigger (webhook / cron) → Workflow starts
↓
Step: gather context
↓
Step: run agent (AI SDK)
↓
Step: act on agent's decision (write to DB, send email)
↓
Step: wait for outcome / human review
↓
Step: complete
Workflow gives the agent durability and human-in-the-loop. The agent provides the reasoning.
Hosted agent (Vercel Agent) handles user conversation
↓
Triggers a Workflow for any process > 30s
↓
Workflow runs autonomously, calls back to agent on completion
↓
Agent surfaces result to user
Use when the agent needs to kick off long work without blocking the chat.
These primitives have different limits than vanilla Fluid functions:
For chat routes that orchestrate Workflow triggers, your AI SDK route still has standard function limits (maxDuration). The Workflow runs separately.
See vercel-fluid-compute for the underlying function config; the AI SDK route + Workflow combo is what Slalom uses.
Each primitive has different state defaults:
Sandbox.create() is fresh. If you need state across calls, store it externally (Postgres, KV) and inject.Common pattern: the workflow itself is the source of truth for "where in the process are we"; your application database is the source of truth for "what does the data look like." Don't duplicate.
Each primitive emits traces visible in:
For end-to-end tracing across these + your app, configure OTEL — see vercel-observability. The output goes to your tracing backend (Honeycomb, Datadog, Tempo) where you can see the full flow from "user message" through "workflow step 5" to "response back."
waitForEvent. Workflow runs forever waiting for an approval that's never coming. Always set a timeout.# Workflow: [Name]
## Trigger
- {webhook | cron | manual | event}
## Steps
1. {name}: {what it does, expected duration}
2. {name}: ...
## Wait points
- {step}: waits for {event}, timeout {duration}, fallback {action}
## Idempotency
- {step}: idempotent because {reason}
- {step}: deduplicated by {key}
## Failure handling
- {step}: retries {N} with backoff, then {action}
## State
- Workflow state: {what's checkpointed}
- App state: {what's in DB}
## Observability
- Trace target: {Honeycomb / Datadog}
- Alerts: {on-failure routing}
## SLA
- p95 completion: {duration}
- Cost per invocation: {estimate}
vercel-ai-sdk.vercel-ai-gateway.vercel-fluid-compute.vercel-storage.vercel-observability.vercel-security.software-engineering-agentic-workflow-engineer.software-engineering-backend-architect.../../references/api-surface.md