Brand Agents vs. Third-Party Chatbots: The Migration Guide

If you run a third-party chatbot today — Gorgias, Tidio, Re:amaze, or a homegrown widget — you have almost certainly been pitched on replacing it with Shopify's Brand Agents since the Spring '26 edition shipped on June 17. The pitch is reasonable. The execution question is where most merchants get stuck: what actually carries over, what has to be rebuilt from scratch, and how do you switch without leaving customers talking to a broken bot mid-migration.

What a chatbot actually does vs. what a Brand Agent does

A decision-tree chatbot is a flowchart with a chat interface on top. A shopper's message gets matched against trigger phrases or button clicks, and the bot walks a pre-built path: "Track my order" leads to a form, "Return policy" leads to a canned paragraph. When the message does not match a branch, the bot either fails silently, loops back to a menu, or escalates to a human. The bot has no model of your catalog — it has a script someone wrote once and forgot to update.

Decision-tree chatbot

A support tool that matches user input against pre-built trigger phrases or menu choices and returns a scripted response or path. It cannot answer anything outside the tree it was given.

Brand Agent

Shopify's native AI shopping and support agent, shipped in the Spring '26 edition (June 17, 2026, Shopify Plus). It reasons over live catalog data, order history, and store policies to answer novel questions and take action — not just retrieve a scripted reply.

A Brand Agent instead reasons over structured data at query time: your product catalog, variant and inventory data, order status, and policy documents you feed it. Ask it something nobody scripted — "does the medium run small compared to the size chart" or "can I combine this discount with the loyalty program" — and it composes an answer from your actual data rather than failing over to a menu. That is the real difference: a chatbot executes a script, a Brand Agent reasons over your ground truth. The tradeoff is that a Brand Agent is only as good as the ground truth you give it, which is a catalog and policy data problem, not a conversation-design problem. We cover that reasoning shift in more depth in Shopify Brand Agents, explained.

Should I replace my chatbot with a Brand Agent?

For most Shopify Plus merchants, yes — but not on day one and not as a like-for-like swap. The honest framing: a Brand Agent handles a wider range of real shopper questions with less maintenance than a hand-built decision tree, because you are not the one writing every branch. The cost is that it needs catalog and policy data to be genuinely structured, and Brand Agents are currently Shopify Plus only, so merchants on Basic or Grow plans do not have the option yet regardless of how their chatbot is performing.

Keep the chatbot a while longer if any of these are true: your catalog data is thin or inconsistent (a Brand Agent grounded in bad data will confidently state wrong things, which is worse than a bot that says "I don't know"), you are not on Shopify Plus, or your chatbot is handling a narrow, well-defined job — like a single WISMO ("where is my order") flow — that it already does reliably and cheaply. Replace it when your support volume includes a lot of genuinely novel product and policy questions that a script cannot anticipate, which is exactly the category a Brand Agent is built for.

How do I migrate from a chatbot to a Brand Agent?

Treat this as a data and sequencing project, not a settings toggle. The merchants who get burned are the ones who flip the chatbot off and the Brand Agent on the same afternoon, discover their catalog has no size-chart data or return-window field, and spend two weeks fielding escalations while the agent guesses.

1. 1

   Audit your chatbot's real question set

   Pull six months of chatbot transcripts and bucket them by intent. This is your actual test suite — not a guess at what shoppers ask, but a record of what they asked. It tells you which categories of question your Brand Agent absolutely must handle on day one.

2. 2

   Fix the catalog and policy data the agent will ground on

   A Brand Agent cannot reason its way around missing attributes, absent size charts, or a return policy that only exists as a paragraph on a separate page. This is the same structured-data work covered in catalog enrichment for AI — do it before launch, not after the first bad answer.

3. 3

   Rebuild your highest-value flows as grounding content, not scripts

   Your best-performing chatbot macros — the return policy explainer, the sizing guide, the shipping-delay response — need to become structured, current source content the agent reads at query time. Copying the old script text in verbatim as a static answer defeats the purpose; the agent should compose the answer from the same data every other part of your store uses.

4. 4

   Run both systems in parallel

   Turn the Brand Agent on alongside the existing chatbot for two to four weeks. Route a portion of traffic to it, or run it in a soft-launch/preview mode if your setup allows, and compare its answers against your audited question set before it becomes the only line of support.

5. 5

   Cut over the narrow flows last

   The well-defined jobs your chatbot already does cheaply and reliably — a single WISMO flow, for instance — don't need to move first. Cut over the broad, novel-question traffic first since that's where the Brand Agent's advantage is largest, and retire the last chatbot flows once you've watched the agent handle them cleanly.

6. 6

   Decommission the chatbot only after a clean measurement window

   Don't cancel the chatbot subscription the day the agent launches. Give yourself a full billing cycle of parallel data before you pull the plug, so you have a rollback path if an edge case surfaces.

Can I keep my old chatbot flows when switching to Brand Agents?

Not in the form they exist today. A decision-tree flow is a sequence of if-this-then-that branches tied to a specific bot's logic — there is no import button that turns a Gorgias flow into Brand Agent reasoning, because the two systems don't share an underlying model. What carries over is the intent behind the flow, not its structure.

Concretely: the return-policy flow's actual return window, exceptions, and process need to exist as structured policy data the agent can cite accurately — not as a flowchart. The sizing-guide flow's actual measurements need to be product attributes, not a static image the bot links to. The order-status flow mostly disappears as custom work entirely, because a Brand Agent has direct access to order data and doesn't need a scripted path to look it up. Think of migration as extracting the facts your flows encoded and re-platforming those facts as data, while retiring the flow logic itself.

• Transcripts carry over as intelligence. Historical chat logs tell you what to prioritize — mine them, don't discard them.
• Policy text carries over as source content, once restructured into fields the agent can ground on rather than a script it walks.
• Flow logic does not carry over. The branching structure itself is chatbot-specific and has no equivalent in a reasoning system.
• Escalation rules need to be rebuilt. Decide explicitly when the Brand Agent should hand off to a human — don't assume it inherits your old bot's escalation thresholds.

What breaks if you rush it

The two failure modes we see most often both trace back to skipping a step in the sequence above. First: launching the Brand Agent on a catalog that has not been audited, which produces confidently wrong answers on exactly the product questions that used to be your chatbot's bread and butter. A bot that says "I'm not sure, let me connect you with someone" is annoying; an agent that states an incorrect fabric content or incompatible-fit claim is a returns problem. Second: a hard cutover with no parallel window, which means the first time you see how the agent handles your real question mix is in production, with customers as the test group.

Both are avoidable with the sequence above, and both are exactly the gap-avoidance work covered in more detail in the first 30 days after Brand Agent launch and in designing the agent's actual conversation behavior. Neither is optional — they are the difference between a migration that reduces support load and one that generates a spike of it.

Where GigaCommerce fits

This migration touches catalog data, policy structuring, conversation design, and a sequencing decision most support teams have not had to make before — it is not a plugin swap. Our Agentic Commerce Setup engagement runs the audit, the data fixes, and the parallel-run cutover as one fixed-scope project, live in two weeks, so the switch happens without the support gap.