When support AI becomes infrastructure, write the exit kit first

A customer messages your support line on WhatsApp at 9:14 on a Tuesday. She's annoyed, but specific: she was charged for a plan tier she swears she downgraded last month.

No human reads it first. An AI agent does. It pulls her account, sees the downgrade request was submitted but never processed, finds the relevant clause in your billing knowledge base, and starts drafting a refund explanation. Then it hits a flag on the account: renewal in eleven days, contract value above the threshold your team set for "do not let this churn." So instead of resolving the ticket itself, the agent posts a summary into a Slack channel, tags the account owner, and tells the customer a specialist will follow up within the hour.

Resolve, escalate, or hand off. Three paths, decided in under a second, inside a single thread, by a system that learned your policies and your account-risk rules. Nobody on your team watched it happen.

That quiet customer-facing decision is the thing this article is about. The moment your support tool starts making it, the tool stops being a place where tickets live. It becomes part of how your business runs. And the question you should be able to answer before that point is simple: if you had to leave this vendor in 90 days, what would you actually own?

What two announcements told us in the same 48 hours

On June 15, 2026, Salesforce signed a definitive agreement to acquire Fin, formerly Intercom, for approximately $3.6 billion, subject to purchase price adjustments. The framing in Salesforce's own release is worth reading closely, because it describes how much these tools now do.

Salesforce says Fin's AI Agent resolves complex customer queries end-to-end across live chat, email, WhatsApp, SMS, phone, and Slack. It says Fin examples show AI agents resolving, on average, 76% of support volume end-to-end. It says the deal brings a global customer base of more than 30,000 companies, and that its own Agentforce product reached $1.2 billion in ARR in Q1 FY27, up 205% year over year.

Treat those as Salesforce claims, not independent proof. Vendor numbers in an acquisition announcement are marketing first, measurement second. But notice what's being sold. Not a chat widget. A system that talks to customers across six channels and closes a large share of the work without a human in the loop.

Roughly a day later, on June 16, a developer going by jackjayd posted a Show HN for Opencom, which positions itself as "the open-source alternative to Intercom": self-hosted live chat, product tours, tickets, and AI agents. The repository was created in January 2026, is AGPL-3.0 licensed, written in TypeScript, and had roughly 44 stars when we checked. Small. New. Not a Salesforce competitor in any commercial sense.

What's interesting is the author's framing. The Show HN post explicitly ties the timing to the Fin acquisition and argues that customer communication is important infrastructure that should have a credible open-source option. The author asks readers which Intercom-style features they would want before using it in production.

So within two days you had the same idea arriving from opposite ends of the market. A $3.6 billion acquisition and a small open-source repo both saying, in effect: the place where you talk to customers is infrastructure now. One is betting you'll consolidate onto a hosted AI suite. The other is betting you'll want to hold the keys yourself.

Both camps point to the same operator question: whichever way you lean, can you leave without rebuilding your support function from memory?

Why switching support tools stopped meaning what it used to

Migrating a support tool used to be tedious but bounded. You exported tickets, imported them somewhere else, rebuilt a few canned responses, retrained the team on a new UI. A week of grumbling and you were done. The tool was a filing cabinet with a chat window bolted on.

An AI support agent is not a filing cabinet. Look back at the WhatsApp scene and count what the system was actually carrying:

• Channel reach. It was reachable on WhatsApp, and would have answered the same way on email, SMS, phone, or Slack. The customer's entry point is now a configuration, not a constraint.
• Policy knowledge. It cited a real billing rule, pulled from a knowledge base someone wrote and the agent was trained on. That training is an asset, and assets can be stranded.
• Identity and account context. It knew who she was, that she was verified, and that her account carried a renewal flag with a dollar threshold attached.
• A resolution decision. It chose not to refund automatically. It followed a rule about what an agent is allowed to settle versus what a human must approve.
• A handoff. It escalated to a named owner through a specific channel, with a summary, on a clock.
• A record. Somewhere, ideally, it logged what it saw, what it decided, and why.

Every one of those is a piece of operating logic. Some of it you authored. Some of it the platform learned. And almost none of it lives in the ticket export.

That's the trap. When you decide to move because you got acquired into a suite you didn't choose, pricing changed, you want to self-host, or the agent did something you can't explain, you discover the tickets were never the valuable part. The valuable part was the behavior: the rules, the routing, the thresholds, the knowledge sources, the audit trail. If those only exist inside the vendor's runtime, you're rebuilding your support operation live while customers keep messaging in.

Open source doesn't exempt you from this, which is the honest caveat the Opencom enthusiasm can paper over. Self-hosting gives you the right to keep running the software. It does not, by itself, hand you clean job definitions, documented escalation logic, or a portable receipt format. Opencom's own materials describe a serious feature set: shared inbox, tickets, an AI Agent trained on docs with confidence scoring and human handoff, plus security primitives like RBAC, HMAC identity verification, audit logs, and webhook signatures. Good ingredients. But ingredients you've configured into a working support process are still your operating logic. If you've never written that logic down outside the tool, self-hosting won't save you when you want to change something fundamental.

This isn't a Salesforce-bad, open-source-good story. Hosted suites and self-hosted alternatives both demand the same discipline, for the same reason: the intelligence moved out of the people and into the platform, and platforms change hands, change prices, and change behavior.

The support AI exit kit

So write the thing down. Before an agent resolves real tickets, and definitely before you sign with or migrate away from any vendor, assemble what we call the support AI exit kit.

It's a living packet that captures the operating logic of your support function in a form you own, independent of whoever is running the software this quarter. Think of it the way an ops team thinks about a runbook: someone other than the original author can pick it up and keep the lights on.

The exit kit is not a breakup plan. It is proof you still own the customer engine.

The useful side effect: assembling the kit forces clarity you want anyway. You can't document an escalation rule you've never actually decided on. Most teams find the gaps while writing the kit, not during a migration. That is the point of writing it early.

What goes in the packet

Each section below is meant to be copied into a real document and filled in. Give every section an owner and update cadence. Otherwise the packet will rot within two quarters.

Packet section	What it must contain	Why it is portable, not optional
Conversation archive	Full message history across every channel, with timestamps, customer identity, and which messages the AI sent versus a human, in an export format you have actually tested.	This is the section vendors most reliably hand you, and even here, "we have an API" is not the same as "we ran the export and the data was complete."
Knowledge source map	Every document, article, and policy the AI was trained or grounded on, where the canonical version lives, and who owns updates.	If the agent's answers come from sources you don't control, you can't reproduce its behavior anywhere else. Own the sources, not just the answers.
Resolution policy	The job definition: what the agent is allowed to resolve on its own, what it must never decide, and the dollar or risk thresholds in between.	This is the agent's actual job, written in plain language. Most teams have it only as scattered settings inside the tool. See process automation mapping.
Handoff and escalation map	Every trigger that moves a conversation to a human, who receives it, through which channel, and the expected response clock.	The WhatsApp renewal flag lives here. Lose this and your resolution rate means nothing, because you can't reproduce the escalations that mattered most. Pair it with an approval queue.
Identity and permissions	How customers are verified, what the AI may read versus write, and the access boundaries on sensitive data.	Identity verification, RBAC, HMAC, and similar controls are migration requirements, not implementation trivia. Frame them with your data security and read/write/approve boundaries.
Audit and receipt log	A per-decision record: what the agent saw, what it decided, why, and with what confidence, in a schema you defined.	When an agent does something surprising, the receipt is your path to understanding it. Define the shape before the vendor's log format defines it for you. More on this in agent receipts.
Channel inventory	Every channel the agent operates on, including chat, email, WhatsApp, SMS, phone, and Slack, plus the per-channel rules and limits.	A migration that quietly drops a channel quietly drops customers.
Analytics baseline	Your current resolution rate, escalation rate, CSAT, and response times, measured before you change anything.	Without a baseline you can't tell whether the new system is better, worse, or just different. See how we think about a quality lane.
Rollback owner	A named person responsible for the migration, the documented revert trigger, and the fallback if the agent misbehaves customer-side.	Every other section is a document. This one is a human who can pull the cord, with guardrails that tell them when. See customer-facing AI guardrails.

You'll notice the kit is mostly things you should be able to produce on a normal Tuesday, not just during a crisis. That's deliberate. Teams that stay free treat these nine sections as standing documentation, reviewed when the policy changes, not when the contract ends.

It also doubles as a buyer's test. When a vendor pitches you, hosted suite or open-source project, walk the nine sections and ask which ones their platform lets you export, define, and own. The answers sort serious tools from comfortable traps faster than any feature comparison.

Where to start this week

Don't try to write all nine sections at once. Pick the one support workflow you'd least want to lose, usually the escalation path that protects at-risk accounts, and write its handoff map and resolution policy first. One workflow, fully documented and owned, teaches you the format for the other eight and surfaces the gaps that matter most.

If you want a second set of hands on that first pass, that's exactly the work we do. Map one customer support workflow with us and draft your support AI exit kit. We'll sit with your team, trace one real conversation end to end, and hand you a filled-in packet for that workflow that you can extend yourself.

The Fin acquisition and the Opencom launch are the same signal from opposite directions: the place where you talk to customers is becoming infrastructure, and infrastructure you can't leave is infrastructure that owns you. Write the kit while things are calm, and it stops mattering which way the market consolidates next. The customer engine is still yours to run.