Deploy to Vercel
Everything you've built runs the same way locally and on Vercel, which makes this last step gratifyingly boring. There's no special production rewrite of the agent, no "now port it to the cloud." You build, you deploy, you poke the live URL and watch the same dispatcher answer from a server instead of your laptop.
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.
Hands-on exercise
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:
import { defineSandbox, defaultBackend } from "eve/sandbox";
export default defineSandbox({
backend: defaultBackend(),
});Build and deploy. npx eve build compiles the agent and writes the Vercel output; vercel deploy ships it. From the project root:
npx eve build
vercel deployThe 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 }Then drive a real turn as a customer (the deployed routes enforce the fail-closed auth from 5.1, so send a session):
curl -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?"}'Or point the dev TUI at the deployment and talk to it interactively:
npx eve dev https://<your-app>Same dispatcher, same tools, same approval gate, now answering from production. Ask it to book the overhaul and the approval still parks the turn, exactly as it did on your laptop.
A 401 on every live request? That's the fail-closed lock doing its job, send a valid shop_session cookie, or for a quick poke, hit /eve/v1/health, which is always public. If eve build fails on discovery, read the diagnostics it prints (and .eve/diagnostics.json); the most common cause is a tool file that doesn't export default its defineTool.
Done-When
agent/sandbox/sandbox.tssets a backend (defaultBackend()is fine).eve buildsucceeds andvercel deployships the app.curl https://<your-app>/eve/v1/healthreturnsok.- A real turn against the deployed URL works (TUI via
eve dev <url>orcurlwith a session).
Solution
The only code is the sandbox backend; the rest is two commands:
import { defineSandbox, defaultBackend } from "eve/sandbox";
export default defineSandbox({
backend: defaultBackend(),
});npx eve build && vercel deployThe dispatcher you started as a persona in 1.1 now diagnoses, quotes from a real catalog, remembers bikes, adapts per tier, asks before it spends, answers on the web and in Slack, and runs in production behind real auth. One last short stop: a look at the three things the shop didn't need, and when you would.
Was this helpful?