#Vatio vs Voiceflow: which one for your app's agent?

Choose Voiceflow if a team will design and run chat and voice agents on a platform: playbooks and visual workflows, phone calls and SMS, several environments with traffic splits, and handoff to a contact center. Choose Vatio if you're building an app with a coding agent and want an agent inside that app that acts for its signed-in users through your own API: your coding agent writes it in your app's project, Vatio runs it, and every reply your team reports becomes a test before you approve the next version. Both host the agent, call your APIs, hand conversations to people and test changes before release. They differ in where the agent is defined, how it knows the user and which channels it covers.

#What Voiceflow is

Voiceflow is a platform for building, testing, deploying and monitoring chat and voice agents for customer experience, aimed at CX and support teams, engineers and product teams. Agents are hosted on Voiceflow.

• How it's built. In a Voiceflow project. A global prompt shapes every reply. Playbooks handle open-ended conversations toward an outcome; workflows are visual, step-by-step flows for processes with strict business logic, mixing AI, scripted and logic steps. The knowledge base imports URLs, sitemaps and documents. Tools include API tools, function tools in JavaScript, MCP tools and integrations, with secrets for credentials.
• From a coding agent. The vf CLI manages agents, knowledge base documents, transcripts, analytics and environments from a terminal or CI, and switches to structured errors when it runs inside Claude Code or Cursor. Voiceflow also offers an MCP server for coding assistants, and APIs.
• How it reaches your users' data. The page that loads the chat widget can set a userID, which becomes the agent's {user_id} variable, and pre-fill variables through the launch payload. Voiceflow's authentication tutorial has a playbook collect credentials in the chat, verify them through an API tool and store the result in a variable.
• Where it runs. The chat widget on the web and in apps, inbound and outbound phone calls, SMS through a Twilio number, WhatsApp, and any interface through its Conversations API. Each environment has a draft and a published version; a project has Main plus up to nine more, and a traffic split sends a share of live conversations to another environment.
• Handoff. A live agent handoff step connects the user to a person in your contact center (Genesys, Ujet, Kustomer, Dixa or Zendesk), relays messages both ways and can return the user to the agent afterwards.
• Testing. Tests are scripted or simulated conversations with checks on the reply, the routing and the tool calls, run when you start them; the recommended flow is to clone Main into an environment, change it, test it and merge. Evaluations score past conversations against criteria you define, and each transcript keeps a timestamped log of what happened in the conversation.

#What Vatio is

Vatio is an agent for the app you're building, with a coding agent or an app builder. It has two steps. The fastest, from any chat: add the remote MCP server https://vatio.ai/mcp as a connector in Claude, ChatGPT or Cursor, sign in with a Vatio account and ask for the agent; it is created in a preview to try, and nothing reaches your users until you publish (Vatio in Claude and ChatGPT). To build the agent into the app's code: in the project run npx @vatio-ai/skills, then /vatio-init, and /vatio-improve daily. Your coding agent reads the app, asks what the code doesn't answer and writes the agent into your project: instructions in vatio.yml, tools that call your API, and knowledge entries, which you can review like the rest of your code.

Vatio runs the conversations in your app, through the web widget and the iOS, Android and Flutter SDKs. Your team follows them in the inbox and reports wrong replies. Each report with a note becomes a test: /vatio-improve prepares the fix, Vatio replays every reported case against preview, and you approve each publish.

#The main differences

#When Voiceflow is the better choice

• The agent answers or makes phone calls, or texts by SMS. Vatio's channels are chat, with replies in text.
• A team designs the conversation, with deterministic workflows, scripted steps and logic inside the agent platform. In Vatio, each tool is one HTTP request, and branching lives in your backend.
• You want several environments, protected environments, or a traffic split to compare two versions on live conversations. Vatio has one preview and one live per workspace.
• Handoffs go to a contact center such as Genesys, Kustomer or Zendesk.
• You want to write your own test checks on routing and tool calls, or score every conversation against criteria such as resolution.
• There is no app, or the agent isn't meant to act inside one.

#When Vatio fits better

• You're building an app with Claude Code, Cursor or Codex and want the agent defined in that app's project, next to the API its tools call, reviewed and versioned like the rest of your code.
• The agent acts for signed-in users. Vatio verifies who they are from your app's sign-in, instead of the agent collecting credentials in the chat. Your backend signs a short-lived RS256 token with a key Vatio never sees.
• A private tool can't take a user id as a parameter: the deploy fails if one tries, so nobody can talk the agent into reading another user's data.
• Tests come from the people reading conversations. Whoever supervises the inbox reports a wrong reply and writes what should have happened, without writing a test script, and every such note is checked before you publish.
• The agent belongs inside your app first, in the widget or in your own UI with the iOS, Android and Flutter SDKs.

#Moving from Voiceflow to Vatio

Start from a chat with the Vatio MCP server (https://vatio.ai/mcp), or in your app's project with npx @vatio-ai/skills and /vatio-init, and say you're moving from Voiceflow. Then bring over what your Voiceflow agent worked from:

1. Knowledge base into entries. Gather the documents your Voiceflow knowledge base was built from (vf document list lists them). For URLs and sitemaps, copy what the agent needs from the pages themselves, since Vatio doesn't read websites. Put it in a folder in your project: vatio-init proposes knowledge from the docs, FAQs and policies it finds and writes one Markdown entry per topic.
2. Prompt and playbooks into instructions. The global prompt and each playbook's goal and rules become the agent's instructions in vatio.yml. Scripted steps that must always happen the same way, and the logic steps of a workflow, move into your backend, as one endpoint that does the whole job.
3. Tools. Each API tool becomes a Vatio tool: one HTTP request, described in YAML, with its credentials as workspace secrets (vatio secrets set). A function tool's JavaScript moves into the endpoint the tool calls.
4. Identity. Replace the userID and the in-chat sign-in with a verified identity. Ask your coding agent to sign a token in your backend with the private key from vatio auth --new-key (RS256, with sub, aud set to your workspace slug and exp) and pass it to the widget. Tools that read {user_id} become private tools that forward Bearer $auth.token.
5. Handoff rules. Write the situations that led to your handoff step in the when_to_use of a tool that alerts your team. The tool calls your backend with a link to the conversation, your backend tells whoever should pick it up, and whoever replies in Vatio's inbox takes the conversation over (Human in the loop).
6. Run both, and carry your tests over. Keep Voiceflow answering while you try Vatio's preview. The chat in Try the agent in the inbox is a signed-out visitor, so for account questions ask your coding agent to put the preview's widget in a development build of your app and sign in as a test user. Have the conversations your Voiceflow tests covered, flag each wrong reply with what should have happened for /vatio-improve, and keep each one it gets right with vatio test add.
7. Switch the widget. Publish when you're ready, by telling your coding agent or running vatio publish. Create a publishable key that allows your domain (vatio keys create publishable --origin https://yourapp.com, or Settings → API keys in the inbox), and replace the Voiceflow widget snippet with Vatio's script tag or @vatio-ai/widget. In a mobile app, use Vatio's iOS, Android or Flutter SDK.

For steps 3 and 4, an API tool that sent {user_id} to look up a subscription becomes tools/my_subscription.yml:

description: The signed-in user's plan, renewal date and payment status.
when_to_use: The user asks about their plan, a renewal or a payment.
access: private
request:
  method: GET
  base_url: "$env.APP_API"
  path: /me/subscription
  headers:
    Authorization: "Bearer $auth.token"
respond:
  data:
    subscription: "$.subscription"

There is no user id in it: your endpoint verifies the token and answers for that user. See Tools and Private tools.

From then on, the routine is daily: your team reports wrong replies in the inbox, you run /vatio-improve, review the tests on preview and approve the update (Improve). WhatsApp and Instagram are on every plan (Pricing).

Checked on 14 October 2026. Features and plans change: check Voiceflow's own documentation, listed below, for what it offers today.

#Sources

• Voiceflow
• Build AI agents with Voiceflow
• Building an agent
• Variables
• Chat widget API
• Build an authentication workflow
• Live agent handoff
• Tests
• Deploy glossary
• The vf command line interface
• vf document
• Evaluations
• Transcripts

#Frequently asked questions

#Should I use Voiceflow or Vatio for my app's AI agent?

Voiceflow fits a team that designs chat and voice agents on a platform: playbooks and visual workflows, phone and SMS, several environments and traffic splits, and handoff to a contact center. Vatio fits when you're building an app with a coding agent and want an agent inside it that acts for signed-in users through your own API: your coding agent writes it in your app's project, and the replies your team reports become tests that every new version is checked against before you approve it.

#Voiceflow has a CLI for coding agents. How is Vatio different?

Voiceflow's vf CLI lets a coding agent inspect and update agents, knowledge, transcripts and environments that live in your Voiceflow workspace. With Vatio, the agent's configuration lives in your app's project: vatio.yml, a YAML file per tool and the knowledge entries, written by your coding agent next to the code those tools call. Vatio runs the conversations, and you approve each publish.

#How does a Vatio agent know which user it's talking to?

From your app's sign-in, verified by Vatio. Your backend signs a short-lived RS256 token with the key from vatio auth --new-key. Private tools forward that token to your API, which reads the user from it, and a private tool cannot take a user id as a parameter. The agent never has to ask for credentials in the chat.

#Can Vatio answer phone calls like a Voiceflow voice agent?

No. Vatio's channels are chat: your app's widget and SDKs, and WhatsApp and Instagram. Replies are text; a voice note a user sends reaches the agent as its transcript. If the agent has to answer or make phone calls, or text by SMS, Voiceflow fits that better.

#How do I bring my Voiceflow tests to Vatio?

Vatio's tests come from reported replies and vatio test add. Have the conversations your Voiceflow tests covered with Vatio's preview, and once a reply is right, keep it with vatio test add and a note on what it should do. Each one becomes a test that Vatio replays against every new version, and a version that breaks one live passes is not published unless you override it.

#Related guides

• Tools: Give the agent your API as tools.
• Improve: Report mistakes in the inbox, /vatio-improve fixes them, and you approve the update.
• Choosing how to build your app’s agent: When an agent framework, a no-code builder or a runtime like Vatio is the right call.
• Vatio vs Botpress: A bot platform with a studio and a TypeScript ADK, or an agent in your app's project. When each fits, and how to move.