Hyperlambda
Intercom renamed itself Fin in May 2026, after the AI agent that had become most of the company. A month later, on June 15th, Salesforce signed a definitive agreement to buy it for roughly $3.6 billion and fold it into Agentforce. The deal is signed, not closed, and Fin's pricing has not moved because of it. Yet.
Let me say the fair thing first. Fin is a genuinely good product. It runs on a support-tuned model of its own, it answers on chat, email, WhatsApp, SMS, phone and Slack, and it holds a 4.5 rating on G2 across nearly three thousand reviews. Nothing below argues that it does not work. What it argues is that the way Fin is priced makes it work against your budget precisely when it works for your customers.
One sentence of thesis before any table, because every number descends from it:
Fin meters the one thing that grows when it works. Magic charges for the machine.
What a resolution actually is
Fin costs $0.99 per outcome, on top of whatever Intercom seats you already pay for. An outcome, per Intercom's own pricing page, is any one of: the customer confirms the answer helped; the customer does not ask for more help after Fin responds; or Fin completes a workflow or hands the conversation off. Lead qualification is a separate outcome at $9.99. You are charged at most once per conversation, and there is a 50-outcome monthly minimum, so the floor is about $49.50 before a single seat.
Read the middle clause again. A customer who gets an answer, does not like it, and closes the tab is an outcome. Abandonment is billable. Intercom would say, with some justification, that most silent exits are satisfied customers. The point is that you cannot tell the two apart on the invoice, and the invoice does not try to.
The seats underneath are $29, $85 or $132 per seat per month on annual billing. If you would rather keep your existing helpdesk, Fin sells standalone at the same $0.99 with no seats and the same minimum.
The bill at five volumes
The table assumes Fin resolves half of everything it touches, which is roughly the midpoint of the measured range you will see in the next section, plus one Essential seat so someone can log in. Magic's column is the cloudlet price: $100 per month, flat. A $300 tier exists for double the machine, but a chatbot at these volumes does not need it, so the column stays at $100 all the way down.
| Conversations / month | Fin outcomes at 50% | Fin + one seat | Magic Cloud |
|---|---|---|---|
| 500 | 250 | $277 | $100 |
| 1,000 | 500 | $524 | $100 |
| 3,000 | 1,500 | $1,514 | $100 |
| 5,000 | 2,500 | $2,504 | $100 |
| 10,000 | 5,000 | $4,979 | $100 |
Two sentences, as promised. At 3,000 conversations the gap is fifteen to one, at 10,000 it is nearly fifty to one, and the Magic column is the same number whether your traffic doubles next month or halves. Self-hosting is cheaper still, since the runtime is MIT and runs on a $12 droplet.
The marketed rate and the measured one
Intercom advertises an average resolution rate of 76%. In the one independent test I could find that published its method, Builts AI ran Fin across four small businesses for sixty days, five hundred tickets a month combined, and measured 38%. The two clients with thorough, current documentation landed between 47% and 52%. The two with sparse FAQs landed between 28% and 31%. Their all-in cost per resolved ticket came to $1.40, and they concluded Fin paid for itself at two of the four companies.
That is a small sample, and I will say so again in the fine print. But notice what it does to the pricing model. A per-outcome bill is unpredictable in both directions: if Fin performs as marketed your invoice is double the table above, and if it performs as measured you are paying seats and minimums for an agent that hands two-thirds of conversations back to a human anyway. And the variable that decides which of those you get is not the model. It is your knowledge base. Fin cannot tell a current article from one that has been wrong for eight months, and neither can any other retrieval system, which is why I spent a day rebuilding Magic's around subject-scoped snippets and hybrid search. That work is the same work Fin's customers do in their help centre. The difference is who owns the result afterwards.
The matrix
| Feature | Intercom Fin | Magic Cloud |
|---|---|---|
| Pricing model | $0.99 per outcome, on top of seats | $100 per cloudlet, flat |
| Minimum | 50 outcomes per month, one seat | None; MIT self-host is free |
| Per-seat cost | $29 to $132 per seat per month | None; users are never counted |
| Abandoned conversation | Billable outcome | Not a billing concept |
| Channels | Chat, email, WhatsApp, SMS, phone, Slack | Web chat widget, MCP for agents, HTTP for everything else |
| Model | Apex, proprietary and support-tuned | Any OpenAI model, or a self-hosted one |
| Knowledge sources | Help centre, URLs, files, connected apps | Crawled sites, files, SQL databases, anything an endpoint returns |
| Retrieval control | Managed; you tune articles, not retrieval | Semantic, BM25 keyword, or hybrid; threshold and context budget are yours |
| Hallucination guard | Confidence check, clarifying question, then handoff | Answers only from a corpus you can open and read, at a threshold you set |
| Where the corpus lives | Intercom's cloud | Your cloudlet or your own server |
| Self-hosting | No | Yes, one copy-paste |
| Licence | Proprietary | MIT, all of it |
| Widget size | Iframe, several megabytes | Under 100KB |
| Helpdesk and inbox | Full product, a decade of it | None; not a helpdesk |
| Human handoff | Built in, with routing | One generated tool that emails a summary, plus a widget in the chat; shown in the video below |
| Agent story | Fin is the agent; you configure it | Native MCP with OAuth; agents generate their own tools at runtime inside RBAC |
| Vendor future | Salesforce acquisition pending; Agentforce roadmap | An open-source repository you can fork |
| Community | 30,000 customers, SOC 2, partner programme | Small |
Where Fin wins, stated plainly
Per the rules of this series: no rebuttals in this section. They live below.
Channels. Fin answers on six of them out of the box, and a phone channel is not something Magic pretends to have. If your support runs through WhatsApp or voice, this row alone may end the comparison.
A purpose-built model. Apex was trained for support conversations. Magic hands you a general model and a retrieval pipeline and expects you to do the rest. On tone, on knowing when to stop, on the thousand small behaviours a support bot needs, a support-tuned model is a real advantage.
The helpdesk. Fin sits inside an inbox with routing, assignment, SLAs, reporting and a decade of polish. Magic is not a helpdesk and is not trying to become one. If you replace Fin with Magic you keep, or find, a helpdesk somewhere else.
Handoff as a feature. When Fin gives up it hands the conversation to a human in the same inbox, with context. On Magic that handoff is something you build, and while the video below builds it in minutes, it is still a step Fin's customers do not take.
Assurance. SOC 2, a funded company, thirty thousand customers, people you can hire who already know it. Every one of those is a cost I carry on my side of this table.
Where the bets diverge
Metered success versus a fixed machine. Fin's pricing is honest about what it is: you pay for results. The trouble is that results are the thing you are trying to maximise, so a good month and an expensive month are the same month. Magic charges for a machine, and the machine does not care whether it answered three hundred questions or thirty thousand. The same argument applies to AI agents generally: a fixed runtime cost is easier to defend to a finance department than a variable one that grows with adoption.
A hosted black box versus a corpus you can read. When Fin answers wrongly you go and edit a help article and hope the next retrieval finds it. When a Magic chatbot answers wrongly you open the training data, see exactly which snippet was retrieved, adjust the threshold or the split, re-crawl, and ask again. Both systems are only as good as the documentation behind them. Only one of them lets you watch the retrieval happen.
A chatbot you rent versus an agent that builds. Fin is configured. A Magic agent can be handed an MCP connection and asked to add the capability it is missing, and the Hyperlambda it produces executes inside a runtime where every node must bind to a whitelisted slot, so it cannot exceed its permissions no matter what the prompt said. Nobody has collected the $100 bounty for proving otherwise. That is the difference between a support bot and a support system that grows.
What handoff looks like on Magic
The handoff row in the matrix deserves more than a cell, because it is the row most people will use to dismiss the comparison. Here is the whole thing built from nothing, including the escalation and the widget:
Two mechanisms are doing the work in that video, and both are worth naming.
Escalation is one generated tool. The agent is given a Hyperlambda file, produced from a sentence, that sends an email to your support address with the visitor's name and email as the reply-to, and a summary of the conversation as the body. The moment that file is saved it is exposed to the model as a tool. There is no registration step, no routing table, no plan tier. The model decides when a conversation has gone beyond what the documentation can answer, asks for a name and an address, and calls it. Your inbox gets a thread you can reply to, which is the handoff most small support teams actually want.
A widget is HTML the agent puts into the conversation. Magic's chat widget can render arbitrary HTML snippets inline, inside the chat itself, in their own shadow DOM so they cannot collide with your page. You write the snippet once, with [[placeholder]] tokens where the values go, and attach it to the model with a prompt describing when to use it. From then on the widget is a tool like any other: the placeholders become its parameters, and the model fills them in and shows it when the conversation calls for it. A contact form, a booking calendar, an order lookup, a product card with a buy button. Fin's answer to the same need is a workflow you configure in their builder and pay for as an outcome. Magic's is a file.
Neither of those is a helpdesk, and I said so above. But the distance between "you build the handoff" and "the handoff is built in" is the length of that video, and the bill afterwards is the same $100 it was before. Building it yourself is only cheap if the platform makes it cheap, which is the whole proposition Magic puts in front of AI agent builders.
The decision rule
Choose Fin if: your support runs on channels other than web chat; you need a helpdesk and want the agent inside it; handoff to humans has to be a feature rather than a project; you want a support-tuned model without owning a retrieval pipeline; or your volume is low enough that the minimum is your bill, in which case a few hundred dollars a month buys a lot of polish.
Choose Magic if: your conversations are in the thousands and climbing; you want the bill to stay flat when traffic does not; you want the knowledge base, the retrieval and the answers on infrastructure you control; you already have a helpdesk and only want the AI part replaced; or you expect the agent to do more than answer, and to be extended by people and by other agents.
The test that decides it in one question: when your traffic doubles, should your support bill double with it? If yes, Fin's model is fair and you should take it. If no, you want a machine, not a meter.
The fine print
Every Fin number above was verified on Intercom's own pricing page the day this was published: $0.99 per outcome, $9.99 per lead qualification, the once-per-conversation rule, the 50-outcome minimum, the $29, $85 and $132 seats on annual billing, and the definition of an outcome including the no-further-help clause. The 76% resolution figure is Intercom's own, and the 38% is one third-party test across four companies and sixty days, not a benchmark. Treat both as what they are.
The Salesforce agreement was announced by both companies on June 15th 2026, with closing expected before the end of Salesforce's fiscal 2027, subject to regulatory approval. Nothing in Fin's pricing has changed as a result so far. Pricing pages move, and acquisitions move them faster. If you are reading this months later, re-verify before quoting me, and I would rather you checked than trusted me.
Magic's rows are, obviously, written by the person who wrote Magic. Magic is MIT-licensed and open source. The repository is at github.com/polterguy/magic, and testing any of this yourself takes one copy-paste on a $12 DigitalOcean droplet, or a managed cloudlet if you would rather not.
FAQ
Is Magic Cloud an Intercom Fin alternative?
For the AI-answers-from-your-documentation part, yes: crawl a site, vectorise it, embed the widget, and the chatbot answers from that corpus at a flat monthly price. For the helpdesk, the inbox and the non-web channels, no. Magic replaces Fin, not Intercom.
What counts as a Fin resolution?
Per Intercom's pricing page, an outcome is billed when the customer confirms the answer helped, when the customer does not ask for more help after Fin responds, or when Fin completes a workflow or handoff. The second clause means a customer who leaves without replying is billed as resolved.
Can I keep Intercom's inbox and replace only Fin?
Yes. Intercom's seats include the inbox regardless of whether you use Fin, and a Magic chatbot is a widget that sits on your site independently. Whether that is worth running two products is a question for your volume, and the table above is the place to answer it.
How does a Magic chatbot hand off to a human?
With a generated tool that emails a summary of the conversation to your support address, using the visitor's name and email as the reply-to, and optionally a widget rendered inside the chat to collect those details. The video above builds both. There is no inbox on Magic's side; the handoff lands wherever your email does.
Does a Magic chatbot need an OpenAI key?
Not for retrieval. Keyword retrieval runs on BM25 inside SQLite and needs no embeddings at all, and with a self-hosted completion model the whole loop runs without an external API call. The details are in the RAG article.
What happens to Fin's pricing after Salesforce closes?
Nobody outside the two companies knows, including me. What can be said is that Fin will become part of Agentforce, which is sold per conversation and per seat, and that acquisitions rarely make a product's pricing simpler. If a pending change in ownership makes you nervous about a metered contract, that nervousness is rational.