Platform integration
Agent infrastructure
Build vs buy integrations in the agent era: a current decision framework covering cost, maintenance, auth, coverage, and when each path actually wins.
You are running engineering at an established B2B SaaS company. A product team has spent six months building an agent on top of your platform. The demo lands. Then someone asks the obvious question: how do we ship this to customers? And the answer keeps coming back to integrations — to your own product, to the systems your customers already use, to the surfaces your agent needs to reach.
Now you have to decide. Build the integrations in-house, or buy them from a platform.
The old build vs buy framework was written for a world of system-to-system data pipes. It doesn't survive contact with agents. This piece gives you a current framework for the decision, the dimensions that actually matter, and an honest read on when each path wins. Short version: build wins when the integration is the product; buy wins when it's the surface the product needs to reach.
Building in-house means your engineers own the full lifecycle. They write the client code that calls each target API, model the data, handle auth, retry on failure, observe in production, and update everything when the target changes. The integration lives in your repo, ships through your CI, and inherits your test coverage and observability.
For agent projects, this usually means writing a tool layer by hand: one connector per target product, one auth flow per identity provider, one error-handling pattern per API quirk. If you are building agents on your own product, you are also writing connectors against your own APIs — which is where it gets uncomfortable, because most established SaaS APIs were built for the UI and expose a fraction of what the product can do. Engineering teams end up extending the API surface, building new endpoints, and maintaining two contracts: one for human developers, one for agents. That work is real, it compounds, and it doesn't ship customer value directly.
Buying means you pick a platform that has already solved the connector problem for the systems you care about. The vendor owns the connector code, the auth flows, the maintenance, and usually the runtime. You configure rather than implement. When a target API changes, the vendor updates the connector and you inherit the fix.
The market splits along category lines, and the categories matter more than the feature lists. Embedded iPaaS vendors like Workato Embedded, Paragon, and Prismatic connect third-party systems into your product — useful when your customers want their CRM talking to your platform, less useful when your agent needs to act on your own product. API gateways front APIs that already exist; they don't generate the tools agents need. MCP gateways sit between agents and Model Context Protocol (MCP) servers, governing what already exists rather than creating new surface area. And Tools-as-a-Service platforms generate, run, and maintain the tool layer that lets agents reach into a product's full capability set.
Each of those categories is a different bet on what the integration problem actually is. Picking the wrong category is more expensive than picking the wrong vendor inside the right category.
Most build vs buy frameworks compare features. That's not the decision. The decision is about ownership, compounding cost, and where the integration sits relative to your core product.
A few of these deserve more than a row.
Maintenance is where build economics break. A connector isn't built once. It's built, then maintained against every upstream change, every auth provider rotation, every rate-limit adjustment, every schema migration. Per MuleSoft's 2026 Connectivity Benchmark Report, IT teams spend roughly 36% of their time on custom integration work rather than new product development — a figure worth taking seriously even if you discount it. The cost isn't the first build. It's the next five years.
Auth and identity is where buy decisions get serious. If your agent acts on behalf of an authenticated user, the integration layer has to honour that user's permissions — not run as a shared service account that can see everything. Most generic integration platforms model identity loosely, designed for system-to-system data movement where a single service account is fine. For agents acting as users, that model leaks data. Check this dimension carefully on any platform you evaluate.
Coverage is asymmetric. Vendors look impressive in the demo and thin at the edges. Ask which of your specific target systems are supported, at which depth, with which auth flows. A platform that supports Salesforce at read-only depth is not the same as one that supports the full action surface your agent needs to call.
Build when the integration is part of your product's differentiation. If the way your platform talks to a specific external system is something customers pay for — a deeply optimised sync, a proprietary data model, a workflow that competitors can't replicate — that integration is product engineering, not platform engineering. It belongs in your codebase.
Build when you have one or two integrations to maintain, the target APIs are stable, and your team has bandwidth. The maintenance overhead of two well-chosen connectors is manageable. The overhead of forty is not.
Build when you have hard requirements that no vendor meets. Self-hosted deployment, specific compliance constraints (regulated industries, sovereign data residency), or unusual auth models can force the decision. Verify the requirement is hard before you accept the cost — engineering teams routinely overestimate how unusual their constraints are.
Build when the agent is acting on your own product and your APIs already expose the capability. If your API covers what the agent needs, writing tools against it is straightforward and you keep full control. The trap is that for most established SaaS, the public API covers only a small fraction of what the UI exposes — bulk operations, admin actions, complex queries, and workflow steps that live in the frontend often have no API equivalent — and the build path quietly turns into a multi-year API rewrite project. That's not building integrations any more. That's rebuilding the product.
Buy when you need breadth fast. If your agent needs to reach ten or twenty external systems and you don't have a year of runway to write connectors, a platform is the only realistic path. The economics of in-house don't survive double-digit connector counts.
Buy when the target APIs change frequently and you'd rather not staff a team to chase them. Vendor connector maintenance is the most underrated line item in the comparison. It's the difference between an integration layer that holds and one that quietly rots.
Buy when the integration is supporting infrastructure rather than core product. Connecting to HubSpot, Stripe, Slack, or Google Workspace is table-stakes plumbing for most B2B SaaS. Writing it in-house ties up engineers on work that doesn't differentiate you.
Buy when the problem is agent-specific. This is the case the old framework misses. Agents acting on your own product need a tool layer that runs as the authenticated user, fails predictably, and stays current as the product evolves. That's a different category of buy than the iPaaS most teams already know — and picking iPaaS for an agent problem is a category error, not a vendor error. We covered this distinction in more depth in our piece on SaaS integration in the agent era.
The build vs buy decision gets harder when the integration target is your own product. Most established SaaS APIs were built for the UI and expose only a fraction of what the product actually does. So the in-house path quietly turns into an API rewrite — two to five years, no customer value shipped along the way. The buy path mostly offers iPaaS or API gateways, neither of which generates the missing tool surface.
Pontil sits in the gap. We are a Tools-as-a-Service platform: we generate, run, and maintain the tool layer that lets agents reach into a product's full capability set, working from the codebase you already have rather than waiting on a spec rewrite. The runtime executes as the authenticated user, so permissions and audit trails work. Maintenance is automated as the product changes. We've written more on why teams hit this wall in why agent projects stall.
For most established B2B SaaS teams building agents in 2026, the honest answer is: buy the supporting integrations, build the differentiating ones, and treat agent access to your own product as a separate problem from either.
The trap is conflating those three. Teams that try to build everything spend two years writing connectors and ship nothing. Teams that try to buy everything end up with a generic integration layer that doesn't honour user identity and can't reach the capabilities their agent actually needs. The framework only works when you decide, per surface, which category it falls into.
If one number changes the answer, it's the count. One integration: build it, own it, move on. Five: think hard. Twenty: buy. And if the integration target is your own product and your API doesn't cover what the agent needs — neither build nor buy in the traditional sense is the right path. That's the problem Tools-as-a-Service exists to solve.
Stay up to date on the ever changing agentic landscape.
