Intercom Fin, Freshdesk Freddy, or a custom AI support agent: how to choose

Use Intercom Fin or Freshdesk Freddy if your customers' questions are answered by your help centre alone and you are happy for the agent to live inside that vendor's product. Build a custom agent when resolving a case means acting in other systems, such as billing, a dev tracker or Slack, when you want the agent on your own site or inside your product, or when you need to choose the model and keep the data in your own accounts. I build custom agents for a living, and I still tell people on the scoping call when the vendor's agent is the better fit.

What the vendor agents are good at

Both vendor agents are quick to switch on if you already use the helpdesk. They read your help centre, answer questions on chat and email, and hand over to a person when they cannot help. You pay per use rather than for a build.

As of October 2026, Intercom prices Fin at $0.99 per outcome, which its pricing page counts when a customer confirms the issue is resolved, does not ask for more help after Fin responds, or when Fin completes a workflow, including handoffs. A minimum monthly commitment applies for some customers. Intercom also says Fin works alongside other helpdesks, including Salesforce, HubSpot and Freshworks, so it is no longer only an Intercom choice.

As of October 2026, Freshdesk's pricing page includes the first 500 Freddy AI Agent sessions on its Growth, Pro and Enterprise plans, and charges $49 per 100 sessions after that. A session is a unique interaction between a customer and the AI agent; for email, it is a 72-hour window from the customer's first email.

If most of your tickets are how do I questions with answers already written, those prices are hard to beat with a build. I say as much on the services page on this site: for answers from a help centre inside one product, with no actions in other systems, the vendor's agent will be faster to switch on and cheaper to run.

Where a custom agent earns its cost

The support agent I run in production for a B2B software vendor with two product brands is a useful example of the other side. Its job is the whole front-line job, not only the reply. Before it speaks it checks the customer's billing account in FastSpring and the dev board in monday.com to see whether engineering already knows about the issue. It can extend trials and apply discounts through an approval step, file bugs for engineering, escalate to the right person in Slack, follow up when the customer goes quiet, and close the case. It has 20 tools across those systems. It also drafts missing knowledge-base articles and briefs the team each morning on emerging issues.

Four things pushed that project towards custom.

First, actions in other systems. Most tickets were answerable from documentation, but answering was only part of the work. Someone still had to check the account, check the dev board and remember to follow up. An agent confined to the help centre could not do those parts.

Second, its own widget. Live chat had become an intake form for tickets, and the chat's built-in AI, the weakest responder, sat in front of the strongest. The agent now runs a first-party chat widget on the marketing site and inside the client's apps, with signed sessions, streaming and an origin allowlist, and escalates by opening a ticket where the team already works.

Third, model choice. Production runs on Claude, development on Gemini, and others are available through OpenRouter, in two tiers, standard and light. The light tier does cheap work like topic labels and reranking. The agent is not tied to one vendor's model, and cost per model shows up in the console's analytics.

Fourth, rehearsal. Every action can be run in dry-run first, a master switch stubs every external system, and each integration has its own write gate, so the systems went live one at a time. Any ticket can be replayed to see exactly what the agent would have done. For actions that move money, that matters more than the reply quality.

Questions I would ask before choosing

Pull the last few hundred tickets and sort them roughly by what resolving them took. If the answer is mostly finding the right article, start with the vendor agent. If a meaningful share needed someone to look something up in billing, change an account, or tell engineering, the vendor agent will hand those to a person, and that might be fine, or it might be exactly the work you wanted to stop doing by hand.

Ask where your customers actually write to you. If it is inside your product or on a site the helpdesk vendor does not control, check whether the vendor's widget fits there before assuming it will.

Ask who should own the data and the prompt. With a custom build the code sits in your repositories and runs in your cloud accounts. With a vendor agent you are renting their decisions, which is often a reasonable trade.

Finally, ask whether your documentation exists. Neither route helps if it does not. An agent grounded in nothing has nothing to say, and writing the first set of articles is sometimes the better first project.

The trade-off on cost is roughly this: the custom route costs more up front and less per ticket, and you own it. The vendor route costs nothing up front and is priced per outcome or per session. The table below sets the two side by side.