Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.
When a company with deep AI expertise buys a support product, the decision deserves attention. It challenges a common assumption in agent projects: if a team can build the model integration, it should build the entire application around it.
In a February 2025 vendor-hosted interview, Anthropic's product-support leader discussed choosing Intercom's Fin and balancing automation with human expertise. That is an attributed account of a particular operating decision, not independent proof that every company should buy the same product. The useful lesson is how to separate technical capability from the responsibility of running a support operation.
Define the system you are actually buying
A support agent is one component of customer service. The broader operation needs identity context, conversation history, routing, escalation, knowledge management, reporting, access controls, and a place for humans to work. Each piece must continue functioning when a model answer is uncertain or a tool is unavailable.
A prototype often demonstrates only the most visible layer: a customer asks a question and receives a plausible response. The production decision concerns everything around that exchange. How will a complaint reach the correct owner? How will a changed policy propagate? How will the team investigate an incorrect action six weeks later?
List these requirements before comparing products with a custom build. Otherwise a vendor's full application may be compared with a homemade demo, making the custom option appear artificially cheap. Conversely, a product with many unused features may be unnecessarily expensive for a narrow workflow.
Ask what differentiates your business
Some capabilities are strategic. A company may have proprietary diagnostic logic, unusual customer permissions, or a workflow that existing products cannot support. Owning those elements can create meaningful value. Other capabilities, such as a conventional support inbox, may be necessary without being distinctive.
A useful architecture can combine both. Buy the general support platform, then build a bounded integration or specialized decision aid around the company's unique process. The relevant question is not whether the company is a “builder” or a “buyer.” It is which responsibilities it should own.
Use a differentiation test: if this component worked exactly like a competitor's, would customers care? If the answer is no, investigate whether a reliable purchased option exists. If the answer is yes, identify the exact difference rather than assuming every layer must be custom.
Calculate the full build cost
Include discovery, integration, security review, evaluation, knowledge preparation, and human workflow design. Then add ongoing maintenance, incident response, model changes, API changes, and the opportunity cost of engineering attention. The initial implementation is only one part of ownership.
For an illustrative comparison, imagine a custom project needing several months of engineering effort plus continuing operational support. A subscription may look expensive beside its model bill but inexpensive beside that full commitment. The reverse can also be true at a particular scale or with unusual requirements. The conclusion depends on the actual workload.
Do not count all released staff time as cash savings. If engineers move to other projects, the benefit is capacity and prioritization. If support employees handle a growing customer base, the benefit may be avoided future hiring. Those are legitimate outcomes, but they should be named correctly.
Calculate the full purchase cost
Purchased software has integration and operating costs too. Consider seats, usage, add-ons, communication channels, implementation, training, and content maintenance. Verify the current billing definition rather than assuming every vendor charges for the same event.
Ask how the product handles your difficult cases. Test handoffs, account-specific questions, missing knowledge, and actions requiring approval. A broad feature list does not establish a good fit for your policies or customer population.
Examine exit and portability. Can you export knowledge, conversations, and relevant configuration? What happens to pending work during a migration? A low initial subscription price may not compensate for a poor exit path or a dependency that prevents future operational changes.
Run a comparable pilot
Give the purchased and custom options the same task definition and evaluation set where feasible. Judge verified quality, human review effort, latency, and operating cost. Keep the test narrow enough to complete but broad enough to include realistic exceptions.
Measure the human system around the software. A tool that answers more questions but creates confusing handoffs may increase total effort. A product with a lower automation rate may still be preferable if its escalations are accurate and its operations are easier to manage.
Include the people who will operate the system in the evaluation. Support leads, policy owners, security staff, and frontline reviewers see different failure modes. Their involvement should produce explicit requirements and evidence, not an informal veto based only on preference.
Read the case with appropriate caution
The Anthropic interview is useful because it describes a real buy decision by an organization that could plausibly build sophisticated AI systems. It does not disclose a complete cost model, establish an independent return on investment, or prove that the same choice fits a smaller company.
A service business can build around this lesson by helping customers select, configure, integrate, and evaluate existing tools. That is a proposed monetization model, not an assertion of partner or resale rights. Any such rights must be verified separately with the vendor.
The practical takeaway is to buy or build at the level of responsibility. Own the pieces that create durable differentiation and that you can operate well. Purchase the pieces whose economics, maturity, and fit make ownership unnecessary. Revisit the boundary as the business and available products change.
Sources and evidence
Intercom pricing: Observed US$0.99 per outcome; definition includes specified handoffs, not only explicit customer-confirmed resolution. Pricing and outcome definitions can change; consult the current quote.
Research checked October 26, 2026. Business designs and illustrative calculations in this article are editorial proposals, not documented earnings or guarantees. Recheck current product terms before implementation.
Leave a Reply