The bridge is a fetch-style handler (createBridge from agent-interface-protocol/server, or an app handler wrapping it like the demo’s createApplication), so it runs anywhere that can serve Request → Response on the same origin as your pages.
Vite (dev / preview)
Public tunnel
Vercel
agentInterfacePlugin({ handle, match }) mounts the handler into vite dev and vite preview. One process serves the frontend and the bridge, with an in-memory store.To test with a hosted agent, expose preview through a tunnel and tell the bridge its public origin so it can set Secure cookies and check the host:Use only dummy data. This exposes the demo publicly. The demo’s examples/demo/middleware.ts runs the same handler as Vercel Routing Middleware for /__aim/*, manifests and /.well-known/agent-interface. vercel.json rewrites page routes to index.html.Deploy with vercel from examples/demo, or import the repo and set the Vercel project’s root directory to examples/demo. No environment variables are needed.
Storage
Sessions, snapshots and queued invocations live in a Storage implementation (exported from agent-interface-protocol/server). The default is in-memory and process-local:
- Restarting the server clears every session.
- Multiple instances don’t share state. On serverless platforms, requests for one session can land on different instances.
For any multi-instance deployment (including Vercel under load), implement Storage against a shared store such as Redis and pass it to createBridge (or your app handler). The in-memory store is fine for demos only.
get, set (with TTL and an optional only-if-absent flag) and take (atomic get-and-delete).