#Add an AI agent to the app you built in v0

There are two steps. Step 1 works from any chat. Step 2 needs the v0 project on your computer.

Step 1: create the agent from a chat. In Claude, ChatGPT or Cursor, add the remote MCP server https://vatio.ai/mcp as a connector, sign in with a Vatio account and ask for the agent. It is created in a preview you can try. Nothing reaches your users until you publish it. Details: Vatio in Claude and ChatGPT (MCP).

Step 2: build the agent into the app. Connect the v0 project to GitHub, clone the repository, open it in Claude Code or Cursor and run:

npx @vatio-ai/skills
/vatio-init

/vatio-init reads the Next.js app and creates the agent, or finds the one from step 1. Then ask your coding agent to put the web widget in the app. /vatio-improve is the daily routine afterwards (Improve your agent). Vatio runs the conversations.

#Get your project into Claude Code or Cursor

In v0, open the Project menu ... → Settings → GitHub and select Connect.
Under Git Scope, pick the GitHub account or organization that will own the repository, and enter a Repository Name.
Select Create Repository. v0 creates a private repository and pushes the project's current code.
Clone the repository on your computer and open the folder in Claude Code or Cursor. You need Node.js 20 or newer.

v0 pushes each chat's changes to a working branch of its own and merges it into the base branch, usually main, when you Publish. So main holds what you last published: publish in v0 before you clone, or check out the chat's working branch, shown next to Publish.

v0's sandboxes also come with Claude Code in their terminal. v0's documentation calls installing other CLI tools there and using them on project data an unsupported configuration, and vatio-init runs the Vatio CLI, so use your computer.

In Claude Code, run the first command in a terminal in the cloned project and the second in Claude Code. In Cursor or Codex, ask it to use vatio-init. The first time vatio-init pushes the agent, your browser opens to sign in with email, Google or GitHub.

#What vatio-init finds in a v0 project

vatio-init first looks for a vatio.yml in the repository. If there is one, the agent already exists and it works on that one. Then it reads the app. v0 builds on Next.js by default, so that usually means:

Your API routes. v0 creates backend endpoints with Next.js App Router conventions. A tool is one HTTP request to a URL, so it calls a route to read or change a user's data.
A database integration. Supabase, Neon or Upstash, added from Settings → Integrations.
Sign-in, if the app has it, for example Supabase Auth through the Supabase integration.
Your pages. Help text, pricing and policies can become knowledge entries.

v0 keeps environment variables in the connected Vercel project, not in the repository, so a fresh clone may not have your Supabase address in a .env; your coding agent may need it from you.

Vatio runs your tools from its servers, so they call your deployed app, at its production address, and never your computer. Your backend's address is a secret kept in Vatio, not in the repository.

#Your users, signed in

For how tokens and private tools work, see Authentication and Private tools.

The app uses Supabase Auth. A Next.js route (or a Supabase Edge Function) reads the user's Supabase session and signs the Vatio token, as below.

Either way, a Next.js route signs a short-lived token for whoever is signed in, with the key from vatio auth --new-key. Your coding agent can add the route. The private key goes into Project menu ... → Settings → Environment Variables, never under a NEXT_PUBLIC_ name, which Next.js puts in browser code. identity.pub stays in the repository.

#Put the agent in your app

Your coding agent adds the web widget. In a Next.js app it installs @vatio-ai/widget and mounts it from a client component:

"use client";
import { useEffect } from "react";
import { mountVatioWidget } from "@vatio-ai/widget";

export function VatioChat() {
  useEffect(() => {
    const widget = mountVatioWidget({ workspace: "acme", token: "vatpub_..." });
    return widget.unmount;
  }, []);
  return null;
}

With a signed token, the page hands it over with widget.identify(token).

Origins: every publishable key accepts any https subdomain of vusercontent.net, where v0 shows its previews, without listing it. Your published app is different: v0 deploys to Vercel, and its vercel.app address and any custom domain have to be added to the key. Run vatio keys origins or use Settings → API keys in the inbox. Origins are exact, so each Vercel preview deployment, with its own unique address, is one more origin. A page on an origin the key does not accept gets origin_not_allowed, and the browser console names the origin to add.

Use preview's key while you try the agent, and switch to a live key when you publish.

#Keep building in v0

Commit vatio.yml, tools/, the knowledge and your app's changes, and push to the base branch. In v0, the branch menu's Pull Changes brings the base branch's new commits into the chat's working branch.

Expect a deployment. Vercel builds a production deployment from the project's production branch, often main, so a push there can change your published app.
Protect the agent's files. Save an instruction in v0 (the + button in the prompt bar → Instructions → New Instruction) such as "vatio.yml, tools/ and knowledge/ belong to the Vatio agent; don't change them", and keep it checked.
Pull before you work. Before running vatio-init or /vatio-improve again, pull, so your clone has what v0 published since.

If a change in v0 renames a route a tool calls, that tool's calls start failing. vatio tools --env live shows each tool's errors.

#Try it, then publish

vatio-init links to the inbox, where Try the agent opens, with WhatsApp, Instagram and a web chat. The web chat is a visitor who isn't signed in, so it only reaches public tools. To try what a signed-in user gets, open your app with the preview's widget in it and sign in as a test user.

v0's preview reads only the Vercel project's Development variables, never ones marked sensitive, so a signing key stored that way isn't there. Try signed-in chat on a deployment that has it.

When it does what you want, tell your coding agent to publish, switch the widget to a live key and Publish in v0. Pricing: https://vatio.ai/pricing.

#Sources

Checked on 14 October 2026.

#Frequently asked questions

#Can I run vatio-init in the Claude Code that comes with v0?

No. v0's sandboxes come with Claude Code in their terminal, but v0's documentation calls installing other CLI tools there and using them on project data an unsupported configuration, and vatio-init runs the Vatio CLI. Clone the project's GitHub repository and run it on your computer instead.

Yes, once you add that address to the key. Every publishable key accepts v0's preview addresses on vusercontent.net without listing them, but a vercel.app address or a custom domain has to be added to the key's origins, with vatio keys origins or under Settings → API keys in the inbox. Each Vercel preview deployment you test on is one more origin.

#Can the agent know which user of my v0 app it is talking to?

Yes. A Next.js route (or, with Supabase Auth, an Edge Function that reads the Supabase session) signs a short-lived token for whoever is signed in, with a key from vatio auth --new-key, and your coding agent can add it.

Replit apps: Push your Replit app to GitHub, add the agent from Claude Code or Cursor, and pull it back into Replit.
Build an AI agent: Instructions, knowledge, tools and publishing.
An AI chat for your web app or site: The web widget in your app.
Improve your agent: Report mistakes in the inbox and fix them with /vatio-improve.

Latest CLI version: 0.114.0 · Changelog · The whole contract as Markdown: /docs/docs.md · or vatio docs