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

Choose Fin if a support team will run the agent: it answers from your help center and policies across chat, email, phone and social channels, works inside Intercom or on top of helpdesks such as Zendesk and Salesforce, and is configured in a dashboard. Choose Vatio if you're building an app with a coding agent and want an agent inside that app that serves 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 hand conversations to people and both let you test changes before customers see them. They differ in who builds the agent, where it lives and how it reaches your users' data.

#What Fin is

Fin is Intercom's AI agent for customer service, which Intercom also offers for sales and ecommerce. It is part of Intercom, and Intercom says it also works with Salesforce, Zendesk, HubSpot, Freshdesk and other helpdesks. On Zendesk, for example, Zendesk stays the system of record.

• How it's built. In Fin's dashboard, by the support team. Fin learns from public and private sources: help center articles, internal content, PDFs and webpages. Guidance sets policies and tone. Procedures are multi-step instructions in plain language, with conditions, code conditions and data connectors in their steps, and Fin can draft one from your help center and past conversations.
• How it reaches your data. Data connectors are no-code API integrations; engineering configures the endpoint, its authentication and which response fields Fin may use. A connector identifies the customer by an attribute such as user_id, and Intercom recommends signing that attribute with a JWT through Messenger security. Deciding whether a customer may act on an order stays with your own systems.
• Where it runs. Intercom's Messenger on the web and in iOS, Android, React Native and Cordova apps, plus email, phone (Fin Voice), WhatsApp, Facebook Messenger, Instagram, SMS and Slack.
• Handoff. You configure when Fin escalates, and it passes the conversation to your team in Intercom or in your helpdesk. With Zendesk, Fin's Messenger can open a live messaging conversation there or create a ticket with the transcript.
• Testing. Previews for spot checks; batch tests of up to 50 questions whose answers your team rates; and Simulations, where an AI plays the customer through a Procedure and passes or fails it against criteria you set, saved to run again after each change. Insights and QA review conversations after launch.

#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 Fin is the better choice

• A support team owns the agent and wants to configure it in a dashboard without waiting for engineers.
• Your team already works in a helpdesk (Intercom, Zendesk, Salesforce or another) and wants the agent's handoffs, tickets and reports there.
• You need email, phone, SMS or Slack. Vatio's channels are chat: your app, WhatsApp and Instagram, with replies in text.
• Your answers live in a large help center or on webpages you want the agent to learn from as they are. Vatio doesn't read websites: what the agent needs goes into knowledge entries.
• You want structured multi-step procedures, with branches written and tested in a dashboard by the people who own the policy.
• 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 built the same way, from the app's project, in files you can review.
• The agent has to act for signed-in users: read their account, bookings or orders and change them through your own API. Your backend signs a short-lived token with a key Vatio never sees, so Vatio can check who someone is but never claim it.
• The people reading conversations fix mistakes by saying what should have happened, and you want each of those notes checked against every new version before it reaches your users.
• The agent belongs inside your app first, in the widget or in your own UI with the iOS, Android and Flutter SDKs, with WhatsApp and Instagram as added channels.
• You want preview and live, with rollback, and to approve each publish yourself.

#Moving from Fin 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 Fin. Then bring over what Fin worked from:

1. Answers into knowledge entries. Intercom doesn't export articles from the workspace, but its REST API lists them, with each body as HTML. Put the articles the agent should answer from in a folder in your project, with the internal content and PDFs Fin used. vatio-init proposes knowledge from the docs, FAQs and policies it finds and writes one Markdown entry per topic. Guidance about tone and policy goes into the agent's instructions.
2. Data connectors into tools. Each connector becomes a tool: one HTTP request to your API, described in YAML. A connector that sent a user_id or an email becomes a private tool that forwards the user's token, and your endpoint reads the user from it. Conditions and code conditions in a Procedure move into your backend, as one endpoint that does the whole job; its plain-language steps become instructions.
3. Identity. If your backend signs a JWT for Intercom's Messenger, the same place can sign one for Vatio. Ask your coding agent to add it, with the private key from vatio auth --new-key: RS256, with sub, aud set to your workspace slug and exp. On Supabase, an Edge Function can sign it.
4. Handoff rules. Write the situations Fin escalated on 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 the inbox takes the conversation over (Human in the loop).
5. Run both. Keep Fin 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. Flag each wrong reply with what should have happened and run /vatio-improve until the agent gets them right.
6. 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 Intercom's Messenger snippet with Vatio's script tag or @vatio-ai/widget. In a mobile app, Intercom's SDK opens its own Messenger; Vatio's iOS, Android and Flutter SDKs give you the conversation as state and you draw the UI.

For step 2, a connector that looked up a customer's orders becomes something like this, which your coding agent writes as tools/my_orders.yml:

description: The signed-in user's recent orders and where each one is.
when_to_use: The user asks about an order they placed.
access: private
request:
  method: GET
  base_url: "$env.APP_API"
  path: /me/orders
  headers:
    Authorization: "Bearer $auth.token"
respond:
  data:
    orders: "$.orders"

There is no customer id in it: your endpoint verifies the token and returns that user's orders. 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 Intercom Fin's own documentation, listed below, for what it offers today.

#Sources

• Fin
• Fin AI Agent explained
• Quick start: Create a Fin Procedure
• Using Data connectors for automation
• Designing and using your APIs with Data connectors
• Authenticating users in the Messenger with JWTs
• Choose channels to deploy Fin AI Agent
• Use the Messenger in your mobile app
• Fin for Zendesk explained
• Fin Messenger: Zendesk setup
• Simulations vs. Batch tests vs. Previews
• Public articles FAQs

#Frequently asked questions

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

Fin is built for support teams: it answers from your help center and policies across chat, email, phone and social channels, and hands off inside Intercom or another helpdesk, configured in a dashboard. Vatio is for people building an app with a coding agent: your coding agent writes the agent in your app's project, it acts for signed-in users through your own API, and replies your team reports become tests before you approve each update. Choose by who will build and maintain the agent, and where your users talk to you.

#Can I move my Intercom help center articles into Vatio?

Yes, as knowledge entries. Intercom doesn't export articles from the workspace, but its REST API lists them, with each article's body as HTML. Put the articles in a folder in your app's project and ask your coding agent to turn each topic into a Markdown entry. The entries are tried in preview and go live when you publish.

#How does identity differ between Fin and Vatio?

Intercom secures its Messenger with a JWT your server signs with the Messenger secret key, and a data connector identifies the customer by an attribute such as user_id. In Vatio, your backend signs a short-lived RS256 token with a private key Vatio never sees, . A private tool forwards that token to your API, which reads the user from it, and a private tool cannot take a user id as a parameter.

#Where does a handoff go in Vatio?

To whoever you choose. The agent asks for a person by calling a tool you declare, when a situation you described in its when_to_use applies or the user asks for one, and your backend alerts your team with a link to the conversation in Vatio's inbox, where whoever replies takes it over. Your backend can also open a ticket in your helpdesk, but the reply is written in Vatio's inbox, so if your team needs to work handoffs inside Intercom, Zendesk or Salesforce, Fin fits that better.

#Do I need to write code to switch from Fin to Vatio?

No, but you need your app's project open in a coding agent such as Claude Code, Cursor or Codex. Run npx @vatio-ai/skills and /vatio-init there. Your coding agent writes the agent, its tools and its knowledge, and can add the token signing and the widget to your app. You review the files and approve every publish.

#Related guides

• Support for signed-in users: Answer from your docs, check the user's own account, troubleshoot and open a ticket with what was tried.
• Handoff: When the agent passes a conversation to your team.
• Tools: Give the agent your API as tools.
• Vatio vs Chatbase: A no-code agent trained on your content, or one your coding agent builds into your app. Differences, and moving your sources and actions.