Agentic Data Engineering Resources

Resource

SaaS Integration Strategy: Build vs Buy

Decide which SaaS integration layers to build or buy for AI agents, and how governance, scale, and cost change that decision.

Pedro Lopez

June 5, 2026

Last updated October 16, 2026

Summarize with AI:

Most teams treat build vs buy for SaaS integrations as one decision. For AI agents, that framing usually fails because integrations are not one layer of work. They are a stack of commodity and differentiating layers with different maintenance costs, governance risks, and effects on answer quality.

Teams often make the wrong tradeoff in both directions: they overbuild commodity infrastructure such as auth and API connectors, or they buy too much and lose control where permissions, retrieval quality, and domain fit matter most. A better strategy is to decide ownership layer by layer.

TL;DR

Treat SaaS integration strategy as a layer-by-layer portfolio decision.
Buy commodity layers like authentication, connectors, ingestion, and connection setup UX in most cases.
Build or customize context delivery and domain-specific normalization where they most affect answer quality, permissions, and domain fit.
Revisit ownership decisions as governance requirements, integration count, and team scale evolve.

Why Does Build vs Buy Fail as a Binary Question?

At least six layers sit inside integrations, from authentication and API connectors through normalization, ingestion, context delivery, and product UX. Each layer brings its own engineering cost, maintenance burden, and effect on how your product performs in the market.

Teams that build every layer often spend months on commodity auth management, including token refresh logic, provider-specific OAuth quirks, and credential vaults. That work takes time away from the agent logic that shapes answer quality and user experience. Teams that buy every layer can lose control of context delivery and permission enforcement, which affects whether an agent returns accurate, authorized answers.

The Connector-vs-Platform Distinction Matters More for Agents

Building one API wrapper involves a different scope of work from building the surrounding platform. The platform work includes auth management across providers, error handling frameworks, observability, and multi-tenancy with execution isolation.

Agent workloads add more on top of that baseline. Model Context Protocol (MCP) introduces context-window and operational costs, while embedding generation, permission propagation, and agent-level observability add more systems to run than a traditional Extract, Transform, Load (ETL) setup. Teams that start by building "just a few connectors" often end up building an integration platform.

Which Integration Layers Should You Build vs Buy?

The practical question is not whether to build integrations in general. It is which layers deserve custom ownership and which layers should stay bought infrastructure.

Integration Layer	What It Includes	Default Recommendation	Build When...	Buy When...
Authentication & credential management	OAuth flows, token refresh, credential vaults, multi-tenant auth	Buy	Auth logic contains proprietary security requirements (e.g., custom zero-trust enforcement, air-gapped environments)	Almost always, because auth management across many SaaS providers is commodity infrastructure with high maintenance burden
Connectors & API abstraction	API wrappers, schema mapping, rate limit handling, error retry	Buy for breadth, build for depth	A specific source requires proprietary business logic or the connector is core to product differentiation	You need multiple source connections and your engineering team should focus on agent logic, not API maintenance
Data normalization & enrichment	Schema unification, metadata extraction, entity mapping, embedding generation	Hybrid	Your domain requires custom ontology or proprietary entity relationships that generic normalization misses	Standard SaaS categories where canonical schemas are well-established
Ingestion & freshness orchestration	Batch sync, Change Data Capture (CDC) pipelines, incremental updates, scheduling	Buy	You require custom CDC logic for proprietary databases or need freshness that no platform supports	Agent workloads need fresh data from standard SaaS sources. Platform-managed incremental sync and CDC cover most cases
Context delivery & retrieval	Vector store delivery, permission-aware routing, MCP server interfaces, tool-call formatting	Hybrid: highest custom-build value	Permission logic is complex and domain-specific, or context assembly requires proprietary ranking or filtering logic	Standard retrieval patterns with well-defined permission models where off-the-shelf MCP servers and retrieval pipelines exist
Product UX & connection management	Self-service connection flows, integration configuration, source management UI, tenant settings	Buy	You need deeply custom UX that differs fundamentally from standard connection flows	Pre-built connection flows let users connect sources without custom engineering per integration

Commodity platforms make the strongest case in auth, connectors, ingestion, and product UX. Normalization and context delivery more often justify custom work because they shape retrieval quality, permissions, and domain-specific behavior.

Authentication Is Almost Always Commodity

OAuth variation across SaaS tools creates a maintenance burden that scales poorly with custom implementations. Provider-specific differences in token behavior, scopes, and terminology mean each provider becomes its own integration target.

Concurrency during token refresh shows why this layer is usually commodity work. When multiple agent requests detect token expiration at the same time, each may trigger a refresh. That race condition requires coordination beyond a simple database update. Unless authentication is your core product or you operate in isolated environments, buy it.

Context Delivery Is Where Custom Investment Pays Off

Context delivery sits closest to agent quality because it decides what the model sees and under what permissions. It sits between your ingested data and the context window of the large language model (LLM).

Traditional integration architecture has no direct equivalent because this layer combines three retrieval problems. It must retrieve enterprise documents for Retrieval-Augmented Generation (RAG), conversation history and agent state for memory, and tool descriptions through MCP. Generic platforms may not support the permission models or retrieval patterns your domain requires.

Context engineering often becomes the highest-value custom layer for exactly this reason. The closer a layer sits to permission-aware retrieval and answer quality, the stronger the case for direct ownership.

When Does Governance Override Cost and Speed?

Governance requirements such as Access Control List (ACL) enforcement, data residency, audit trails, and permission-aware query routing can outweigh cost and speed tradeoffs. A team may build custom permission enforcement even when a platform is cheaper and faster because the platform cannot guarantee the access-control granularity their compliance profile requires. In other cases, governance supports buying because the platform already satisfies the required controls and reduces the amount of custom infrastructure inside the audit boundary.

Governance points toward buying when teams work within standard compliance frameworks, standard multi-tenant Role-Based Access Control (RBAC), row-level ACLs as a platform feature, and audit logging that meets regulatory requirements. Governance points toward building when teams need custom Attribute-Based Access Control (ABAC), non-negotiable on-premises deployment, or immutable audit trails where vendor-controlled logs do not satisfy retention requirements.

Permission-Aware Routing Is a Forcing Function

Access rules should restrict agents to the data each end user is authorized to see. Platforms with built-in ACLs work well when the permission model is simple, role-based, and built on well-defined scopes.

Complex permission models change the implementation work. Attribute-based models can depend on temporal context, cross-source relationships, or organizational hierarchy, and generic integration platforms may not enforce that logic consistently across all sources. An enterprise AI assistant that queries Salesforce, Jira, and internal HR systems illustrates the problem. A sales rep should see only assigned accounts, while a manager sees the team's data. The permission model must propagate the calling user's identity through the agent to each downstream system. A jira agent connector propagates the calling user's identity to Jira at query time, so a rep sees only their issues while a manager sees the team's.

How Should Your Strategy Evolve as You Scale?

Ownership should change with integration count, team maturity, and governance pressure. The common mistake is treating the first decision as permanent.

Stage	Typical Profile	Integration Strategy	What to Buy	What to Build (If Anything)	Primary Risk
Proof of concept (few integrations)	Small engineering team, validating agent concept	Buy everything possible	Pre-built platform connectors, managed auth, hosted ingestion	Nothing. Focus all engineering time on agent logic and demo quality	Over-investing in custom infrastructure before validating product-market fit
Production pilot (several integrations)	Growing team, first paying customers	Buy-heavy with selective customization	Platform connectors, auth management, ingestion orchestration	Custom normalization for top sources where generic schemas lose critical data	Underestimating governance requirements as customers add real data
Growth (broader integration estate)	Multiple customer segments	Governed hybrid	Breadth connectors, auth infrastructure, product UX widgets	Custom context delivery, permission-aware routing, domain-specific enrichment	Fragmented integration estate with inconsistent governance
Scale (large integration portfolio)	Mature compliance requirements	Platform standardized with custom layers tied to product differentiation	Platform infrastructure for all commodity layers, compliance oriented pipelines	Proprietary context assembly, custom MCP servers	Platform lock-in without data portability planning

The pattern is straightforward. Teams usually waste effort by over-building at the proof-of-concept stage and under-governing at the growth stage. Complexity and governance demand matter more than any fixed integration count.

Start With Bought Infrastructure, Then Shift Custom Work Where It Matters

Start with bought infrastructure so your team can learn from real usage data which layers deserve custom work. Teams that build first often discover they invested in the wrong layer.

A team may start with a managed platform for third-party SaaS connectors, hit a cost ceiling when applying it to high-volume first-party data, and then shift ownership for that layer while keeping custom transformation logic. Enterprises hitting the same ceiling on a heavyweight iPaaS licence often begin by shortlisting a MuleSoft alternative. Bought infrastructure exposes observability and governance gaps through real data instead of guesswork. That evidence makes later build decisions more accurate.

The Fragmentation Trap at Growth Stage

Teams with a growing integration estate often carry a mix of custom connectors, platform connectors, and ad hoc scripts accumulated through decisions made by different engineers at different times. Each connector may handle permissions differently, log to a different system, or depend on code written by someone who has since left.

That fragmentation often appears first as permission drift. Access controls set at build time can diverge from organizational policy as roles change and upstream systems update. Without a cross-system enforcement layer, the drift can stay invisible until an incident surfaces it.

What Does Agent-Specific Total Cost of Ownership (TCO) Actually Look Like?

Existing TCO models for integration platforms may not account well for agent workloads that are continuous, stateful, and non-deterministic relative to scheduled batch ETL. Agent workloads change standard pricing assumptions in three places:

High-frequency tool calls against per-operation billing. Some platforms charge per MCP tool call, which creates a structural cost multiplier for agentic invocations. Production agents can require multiple calls per documentation query and additional model calls for multi-domain tasks.
Continuous data sync for context stores. Agents need persistence, active data pipelines, and integration middleware that runs continuously. Unlike batch jobs, agents maintain state over time, and that always-on posture changes the cost profile materially.
Platform rate limits as hard architectural ceilings. Some enterprise platform tiers impose API-call ceilings that budget cannot solve. If your workload exceeds a platform's sustained throughput limits, that platform may be the wrong fit regardless of willingness to pay.

To evaluate agent-specific TCO, identify the billing model of any platform you are considering, estimate your agent's consumption pattern at current scale and at higher scale, and compare that with the loaded cost of engineering time to build and maintain a custom equivalent. On the custom-build side, include API change management, provider-specific bug investigation, and on-call rotation in your calculation.

What Is the Right Build-vs-Buy Strategy for Your Team?

The strongest build-vs-buy strategy for AI agents is not ideological. Buy the layers that are expensive to maintain and hard to differentiate on: auth, agent connectors, ingestion, and product UX. Build where permissions, context quality, and domain behavior directly affect outcomes. Revisit those decisions as governance requirements and integration sprawl increase.

Airbyte's agentic platform covers that commodity side of the stack: agent connectors, data preparation, Managed Auth, and schema normalization. Teams keep context delivery, retrieval quality tuning, and domain-specific permission logic in their own codebase. Governance stays under team control through row-level and user-level ACLs and audit logging.

Talk to sales to see how Airbyte's agentic platform supports production AI agents with agent connectors, auth, data preparation, and access controls for enterprise data, or try Airbyte's agentic platform today.

Frequently Asked Questions

How often should teams revisit build-vs-buy decisions?

Build vs buy is an ongoing strategy, not a one-time architecture choice. The right ownership model changes as integration count, team size, and governance requirements grow. Teams should revisit their layer-by-layer ownership allocation as their agent product matures and operational constraints become clearer.

Which integration layer matters most to own for AI agents?

Context delivery and retrieval usually matter most to own because that layer shapes what the model sees and under what permissions. Permission-aware routing, context ranking, and MCP design most directly affect answer quality at that layer. That does not mean every team should build all retrieval infrastructure from scratch, but it is the layer with the highest custom-build value.

Is there a specific integration count where buying becomes the obvious choice?

No universal integration count justifies buying a platform on its own. The decision depends more on the maintenance burden per integration and your team's opportunity cost than on a raw count. Complexity, governance, and operational support load matter more than a simple connector total.

Can multiple platforms fit a hybrid strategy?

Yes. Many scaling teams use one platform for breadth connectors and ingestion while maintaining custom code for domain-specific normalization and context delivery. The main risk is fragmented governance, so permission enforcement and audit behavior need to stay consistent across both sides.

How does governance change the build-vs-buy calculation?

Governance can override cost and speed tradeoffs in both directions. Complex, domain-specific permission models may force custom builds even when platforms are cheaper. Standard compliance frameworks can push teams toward platforms with built-in controls instead of engineering that infrastructure from scratch.