Deploy to Vercel

The agent runs the same way locally and on Vercel. Build it, deploy it, and test the live URL to confirm the dispatcher answers from the hosted environment.

The one production-specific choice is where the sandbox runs, and even that's mostly handled for you. Let's ship it.

Outcome

The Spoke & Mirror dispatcher runs on Vercel, and you've confirmed it live by hitting its deployed routes.

Pick the sandbox backend. Your agent has a sandbox (it seeds torque-specs.md into /workspace). Locally that runs on your machine; on Vercel it runs on hosted Vercel Sandbox. One definition covers both, defaultBackend() resolves to the right one per environment:

agent/sandbox/sandbox.ts

import { defineSandbox, defaultBackend } from "eve/sandbox";
 
export default defineSandbox({
  backend: defaultBackend(),
});

Pinning a backend explicitly

defaultBackend() is the portable choice: it picks the best available environment (Vercel Sandbox when hosted on Vercel, then Docker, microsandbox, or just-bash). To pin Vercel unconditionally instead, import its factory from the nested path and use it directly:

import { vercel } from "eve/sandbox/vercel";
// backend: vercel({ runtime: "node24" })

eve ships a pinned factory per backend; check node_modules/eve/docs/sandbox.mdx for the set in your installed version.

Build and deploy. eve deploy runs the supported production workflow: it links the project when needed, installs dependencies, builds the app, and deploys it to Vercel. From the project root:

npx eve deploy

The deployed app serves the exact same health, session, and stream routes you've been hitting since 1.3, plus the web dashboard from 4.1. If you wired up Slack in 4.2, this is the deploy that gives its webhook a real home.

Try It

Smoke-test the live agent. Health first, it's public, no auth:

curl https://<your-app>/eve/v1/health

{ "ok": true }

Now prove the fail-closed behavior from 5.1. With no customer cookie or Vercel OIDC token, the deployed production process rejects the request:

curl -i -X POST https://<your-app>/eve/v1/session \
  -H 'content-type: application/json' \
  -d '{"message":"hello"}'

HTTP/2 401
{ "ok": false, "code": "unauthorized" }

Then drive a real turn as a customer. The same route accepts the server-recognized demo session, returns 202, and gives you a sessionId to stream:

sid=$(curl -s -X POST https://<your-app>/eve/v1/session \
  -H 'content-type: application/json' -H 'cookie: shop_session=demo-pro' \
  -d '{"message":"what does a full overhaul cost?"}' \
  | sed -E 's/.*"sessionId":"([^"]+)".*/\1/')
curl -sN -H 'cookie: shop_session=demo-pro' \
  "https://<your-app>/eve/v1/session/$sid/stream"

Or point the dev TUI at the deployment and talk to it interactively:

npx eve dev https://<your-app>

The production dispatcher keeps its tools and approval gate. Ask it to book the overhaul and the turn still pauses for approval.

Find your runs in the dashboard

Once deployed, Vercel auto-detects eve as the framework and surfaces an Agent Runs tab under your project's Observability view. Each conversation is a trace you can open and walk, every tool call, every approval, every turn. (The tab is gated per team in the current release; if you don't see it, ask your Vercel contact to enable it.)

A 401 on every live request means the fail-closed lock rejected the caller. Send a valid shop_session cookie, or use the public /eve/v1/health route for a quick check. If eve build fails on discovery, read the printed diagnostics and .eve/diagnostics.json. A common cause is a tool file that doesn't export default its defineTool.

Done-When

agent/sandbox/sandbox.ts sets a backend (defaultBackend() is fine).
eve deploy builds successfully and ships the app.
curl https://<your-app>/eve/v1/health returns ok.
An unauthenticated session request returns 401, while shop_session=demo-pro returns an accepted session ID.
A real turn against the deployed URL works (TUI via eve dev <url> or curl with a session).

Solution

The only code is the sandbox backend; the rest is one command: