In-product AI actions: build or buy?

The build-or-buy question for in-product AI actions has become genuinely live in 2026: Gartner projects that around 40% of enterprise applications will ship task-specific AI agents this year, up from under 5% in 2025, and that most independent software vendors will embed AI capabilities by year end. But the question is usually asked badly, because two different surfaces get treated as one. The first is an assistant living inside your product that completes tasks for your users, "update this appointment," "generate last week's report." The second is your product's actions being available inside external AI hosts, so a customer working in ChatGPT or Claude can act on your system without opening your app. These need different answers. The first is increasingly a reasonable buy; the second is usually a build. This explains why, and where the line falls.

‍

Disclosure: we build the second category, so treat the section on it accordingly. The recommendation to buy the first is sincere and follows from how the tooling has matured.

‍

Surface one: the in-app assistant

This is the surface where buying has become genuinely compelling, and the tooling shift is recent. Platforms in this space have moved from "you write and maintain a tool call for every action" to inferring what a product can do by observing it and turning those capabilities into tools automatically. Frigade's Skills launch in July 2026 is a clear example, an assistant that learns a product's functionality and exposes it as actions with no code to write or maintain, keeping them working as the product changes. Their own framing is apt: for a product never designed with an agent in mind, the effect approximates an MCP server the team never had to write.

‍

For a large class of products, that is the right purchase. If the actions are standard product operations (change a setting, schedule something, generate a report), if the users are your own authenticated users inside your own UI, and if you have no unusual compliance constraints, building this yourself means reimplementing capability discovery, tool maintenance, conversation UI, and the plumbing that keeps it all working as your product evolves, for a feature that is not your differentiator. The industry lesson points the same way: LinkedIn's engineering team, presenting at QCon on multi-agent systems, concluded that teams should default to buying rather than building, and the Gartner projection that over 40% of agentic AI projects will be cancelled by the end of 2027 is largely a story about teams underestimating what production agent infrastructure requires.

‍

Surface two: your actions inside external AI hosts

This is a different problem wearing similar words. Here the customer is not in your UI, they are in ChatGPT, Claude, or Gemini, and your product's approved actions run inside that conversation. Everything changes: authentication happens against a host you do not control, each host has its own approval mechanics, UI rules, and publishing requirements, and the actions execute against your system from outside it. The AI Product Interface layer we build exists for exactly this surface, which is why we treat it as distinct rather than as a variant of in-app chat.

‍

Why this is usually a build: the questions it raises are specific to your business logic. Which actions do you expose to an external surface at all? How does your existing authorization apply when the request arrives through a third-party host? Which actions require visible approval before they run? What does the audit record look like when your product changed state on behalf of a conversation elsewhere? Those are not features you configure, they are decisions about your permission model, and they differ per product. Generic platforms can carry the protocol plumbing; they cannot decide which of your actions are safe to expose to an AI host or how your authorization should behave when the caller is a conversation. That is the reasoning behind exposing product actions safely.

‍

The layered answer

The framing that resolves most of the confusion is that this is not one decision, it is four, and different layers have different answers. The pattern the industry converged on:

• Model access: buy. Effectively settled. You use an API from a frontier provider and treat it as infrastructure.
• Assistant and conversation layer: usually buy. Conversation UI, capability discovery, session handling, undifferentiated work where platforms are now genuinely good, especially for the in-app surface.
• Integrations and authorization: build. No vendor knows your systems, your permission model, or your business rules. This layer is custom in nearly every serious deployment, which is the consistent finding across published build-versus-buy analyses.
• Deployment, telemetry, billing hooks: buy or configure. Metering, audit plumbing, and multi-channel delivery are standard infrastructure.

‍

Read that list and the practical answer for most teams is a hybrid: buy the layers that are the same for everyone, build the layer that encodes what makes your product yours. The teams that get into trouble are the ones that pick a side for the whole stack, either building conversation UI from scratch or expecting a platform to make their authorization decisions.

‍

What actually decides it for a given product

Concrete questions that move the answer:

• Are the actions consequential or reversible? Reversible, low-stakes actions inside your own UI are a good fit for a bought assistant. Actions that send, pay, delete, or commit externally need approval flows and audit tied to your own authorization, which pushes toward build.
• Where does the user start the task? Inside your product, buy the in-app assistant. Increasingly starting in an AI conversation and never opening your app, that is the external-host surface, and it is a different project.
• What are your compliance constraints? Regulated data, residency requirements, or an audit standard you must meet narrow the field considerably. Some platforms offer self-hosting with your own model keys, which is worth checking before assuming build.
• Is this a differentiator or table stakes? If every competitor will ship an in-app assistant this year, building yours slowly is a poor trade. If the actions themselves are your product's core value, custom is the point.
• Do you have the disciplines? Production agent infrastructure spans platform, ML, observability, and security engineering. Published analyses put first-year internal build costs around $300,000 and identify state management and observability as the underestimated line items, LinkedIn reportedly built two separate observability systems because standard APM tooling did not work for non-deterministic agent flows.

‍

The takeaway

Split the question before answering it. An in-app assistant that takes actions for your users inside your product is increasingly a sound buy, since platforms now infer product capabilities and maintain the tooling, and that layer is rarely a differentiator. Your product's actions running inside external AI hosts is a different surface, and it usually requires building, because it turns on your authorization model, your approval flows, and your audit trail rather than on configuration. Most successful deployments are layered: buy model access, buy the conversation layer, build the integrations and authorization, configure the deployment plumbing. The teams that struggle are the ones that answer build-or-buy once for the entire stack instead of per layer.

‍

If the surface you need is your product's actions working safely inside ChatGPT, Claude, and Gemini, that is exactly what our AI Product Interface work delivers.

‍

FAQ

Should I build or buy in-product AI actions? Split the question by surface. An assistant taking actions inside your own product for your own users is increasingly a reasonable buy, since platforms now infer capabilities and maintain the tooling. Exposing your product's actions inside external AI hosts like ChatGPT is usually a build, because it depends on your authorization model and approval flows.

‍

What is the difference between an in-app AI assistant and an AI product interface? The in-app assistant lives inside your UI and helps your authenticated users complete tasks there. An AI product interface makes your product's approved actions available inside external AI hosts (ChatGPT, Claude, Gemini), so customers act on your system from a conversation without opening your app. Different surfaces, different requirements.

‍

Why do so many agentic AI projects fail? Gartner projects over 40% of agentic AI projects will be cancelled by the end of 2027, largely because teams underestimate production infrastructure: state management for long-running workflows, observability for non-deterministic flows that standard APM tools do not handle, and the security engineering around agent permissions.

‍

Which layers should I buy and which should I build? Buy model access (settled) and generally the conversation and assistant layer (undifferentiated). Build the integrations and authorization layer, since no vendor knows your systems, permission model, or business rules. Buy or configure deployment, telemetry, and billing plumbing.

‍

How much does building in-house AI agent infrastructure cost? Published analyses put first-year internal build costs around $300,000, with ongoing maintenance beyond that. The underestimated items are state management and observability rather than the initial integration, and the work spans platform, ML, observability, and security engineering disciplines.