The hidden cost of bespoke agent connectors

The first bespoke connector is a project. The second is a pattern. The tenth is a crisis.

Building connectors product by product to expose your platform to AI agents looks tractable at the start. One connector, one sprint, done. The problem emerges over time, as the number of products grows, as the products themselves change, and as the engineering cost of keeping everything current accumulates into something nobody budgeted for.

This piece maps that accumulation — the hidden cost that doesn't appear on the initial estimate but shows up reliably in year one.

The initial estimate problem

When a team proposes building bespoke connectors, the estimate is almost always scoped to the build. How long does it take to write the connector, test it, and ship it? For a single product with a reasonably documented API, that estimate might be two to four weeks.

That number is real. It's also incomplete. It doesn't include:

• Ongoing maintenance as the underlying API changes
• The cost of discovering and debugging silent drift
• The engineering time spent coordinating with product teams on breaking changes
• The opportunity cost of the engineers doing this work instead of building differentiated product
• The cost of doing the same work again for the next product in the portfolio

These omissions aren't dishonesty — they're how estimates work when the scope is scoped to the build. The problem is that the build is only a fraction of the real cost.

The maintenance burden that accumulates

A connector is a dependency. It depends on the shape of the API it was built against. When that shape changes — a field renamed, an endpoint deprecated, a response structure updated — the connector breaks.

API changes happen constantly in active SaaS products. Some are communicated well; many are not. A product team updating a controller method doesn't necessarily know that an agent connector was built against it. The change ships, the connector fails, and someone discovers it when users report that the agent isn't working.

The engineering cost of fixing a broken connector isn't large in isolation. It might be a few hours of investigation and a small code change. But across ten products, over twelve months, with each product changing at the pace of an active SaaS team, those few hours add up. In our experience, the annual maintenance burden for a portfolio of bespoke connectors tends to run on the order of 20–30% of the initial build cost per product — and it doesn't decrease as the products mature. It increases, because mature products accumulate more connector surface that can break.

The compounding problem

Bespoke connectors don't compound. Each connector you build is a standalone artefact that must be maintained independently. The tenth connector doesn't benefit from the work done on the first nine. The patterns you learn building connector one don't meaningfully reduce the cost of building connector ten if the products have different tech stacks, different auth models, and different API structures — which they do, because that's what a heterogeneous product portfolio looks like.

This is the fundamental economics of the bespoke approach: the costs are additive, not amortised. Engineering work on integrations doesn't compound into a platform. It accumulates into a liability.

Compare this to an investment in a generation layer: the work done to generate connector one produces a pattern, a toolchain, and a maintenance mechanism that applies to connector ten at significantly lower marginal cost. The first unit is expensive; subsequent units are cheaper. That's the economics of a platform, not a series of bespoke projects.

The opportunity cost

The engineers building and maintaining bespoke connectors are not building differentiated product. This is obvious, but it's worth stating explicitly because it often gets lost in project accounting.

Integration work is treated as a feature — it shows up on the roadmap, it gets sprint points, it gets shipped — but it doesn't compound into competitive advantage the way product features do. A better onboarding flow, a more accurate recommendation engine, a faster data pipeline: these accrue. A bespoke connector for product seven doesn't make the connector for product eight easier to build or the product more defensible in the market.

The opportunity cost is the work that didn't get done while the connector got built. For most product teams, that cost is real and visible — it shows up in roadmap slippage, in features that were planned and didn't ship, in the gap between what was promised and what was delivered.

A note on the MuleSoft integration cost figure

The figure often cited in this context comes from MuleSoft's 2025 Connectivity Benchmark Report, which estimates that integration challenges cost the average organisation approximately $6.8M annually in lost productivity and delayed projects. We've referenced it here as directional context. The specific number at any given company depends on team size, portfolio complexity, and how aggressively the connector approach has been applied. The pattern is consistent even when the number varies.

What the alternative requires

Getting off the bespoke connector treadmill requires treating tool generation as a platform problem, not a project problem. That means:

Generation from the codebase. Connectors shouldn't require manual specification for each product. A generation layer that reads the codebase and produces tool definitions is the mechanism that makes the economics work across a heterogeneous portfolio.

Maintenance aligned with the SDLC. Tool updates should be triggered by the same CI that ships product changes, not discovered when a connector breaks in production.

Runtime that handles the reliability concerns centrally. Auth lifecycle management, rate limiting, failure handling — these shouldn't be rebuilt per connector. They belong in a shared runtime layer that every connector benefits from.

The bespoke approach produces none of this. Each connector is an island. The platform approach turns the connectors into a surface that compounds — and the maintenance that was a liability becomes manageable overhead.