If you run support for an e-commerce shop, you have two ways to put an AI in front of your queue. You can switch on a hosted feature inside the tool you already pay for, the way Intercom's Fin sits on top of Intercom. Or you can run your own agent on an open model, on infrastructure you control. Both answer the same tickets. They are not the same product, and the difference is almost entirely architectural.
I build the second kind for French shops, so I am not neutral. But the honest comparison is more useful than a pitch, so here is what actually changes when you move the agent from someone else's cloud to your own.
Where your conversations actually go
A hosted support AI reads the ticket, and to do that it sends the customer's message, and usually a slice of your order and profile data, to the vendor's model. For a lot of teams that is fine. For a shop that sells in the EU and wants a short, defensible answer to "where is our customer data processed", it is the first question, not a detail.
A self-hosted setup inverts the default. The model runs on an instance you rent in your own name, in a region you pick. In my case that means an open French model on French hosting, so the data-residency answer is one sentence and it does not depend on a sub-processor list that can change with a product update. You give up the convenience of "it just works inside the tool" and you get a boundary you can actually point to.
The billing model quietly shapes the product
Hosted support AI is often billed per resolution. That number is easy to reason about on a slide and awkward in practice, because it couples your support cost to your ticket volume forever, and it gives the vendor an incentive to count a "resolution" generously. I keep the current, dated version of that pricing out of this post on purpose, because it changes; the factual Intercom comparison carries the figures with the date they were read.
A self-hosted agent moves the cost into two buckets you already understand: an instance you pay for by the month regardless of volume, and model inference that scales with usage but that you can measure and cap. Neither bucket is per-resolution, so a good month for sales is not automatically a more expensive month for support.
Lock-in is an architecture decision, not a contract clause
The part teams underestimate is reversibility. When the agent, the knowledge base, the conversation logs and the automations all live inside one SaaS, leaving means rebuilding all of it somewhere else. The lock-in is not the contract. It is that your support logic has no existence outside the vendor's schema.
Self-hosting forces the opposite shape. The retrieval layer points at your content. The tools the agent can call are your API endpoints. The logs are in your database. If you stop working with whoever set it up, the system keeps running, because nothing about it is secret or proprietary to them. That is worth designing for even if you never exercise it, the same way you keep your data exportable even when you have no plan to migrate.
What you take on when you self-host, honestly
This is not free. Running your own agent means you own the operations: the instance, the model updates, the monitoring, the on-call when a tool call starts failing at 9pm. A hosted product absorbs all of that for you, and for a small team with no one to carry it, that trade can be the right one.
It also means the same engineering discipline a hosted vendor already invested in. The agent has to answer only from your data and refuse when it cannot, or you have swapped a vendor's guardrails for none. It needs typed tool-use with hard limits, a refund ceiling it cannot exceed, and an escalation path that hands a human the full context instead of making the customer repeat themselves. You do not get those for free by choosing open models; you build them.
When each one is the right call
If you have no one to operate infrastructure and residency is not a hard requirement, a hosted support AI inside your existing tool is the pragmatic start, and I would not talk anyone out of it. If your data has to stay in a specific jurisdiction, if per-resolution billing fights your margins, or if you want the support logic to be something you own rather than rent, self-hosting on an open model is the setup that matches those constraints. The engineering is real either way. The only question is who holds it, and where your customers' data sits while they do.
I build sovereign AI support agents for French e-commerce: self-hosted in France on an open-source stack, for the pre-sale questions that lift conversion and the after-sale ones that decide whether a customer comes back. More on the approach at Bynevo Labs and on sovereign AI customer service. If you are weighing a hosted tool against running your own, I keep a factual Intercom alternative comparison up to date.
