Connector maintenance cost: the integration engineering tax nobody budgets for

How much does it actually cost to keep your agent connectors working? Most engineering leaders can quote the build cost — a sprint or two per product, maybe a quarter for the harder ones. Almost nobody can quote the maintenance cost. That's the line item that breaks agent projects at portfolio scale, and it's the one that gets buried under "platform engineering" headcount until somebody asks where the budget went.

Our view: connector maintenance is not an incremental cost. It compounds. Every new product, every API version, every auth change, every model update adds load to the same team. Treating it as a one-time integration project is what turns a $200K build into a $6.8M annual integration debt line.

This piece breaks down where the cost actually lives, why the standard playbooks (rewrite the API, build bespoke per product, wait for the platform vendors) all underprice it, and what an honest connector economics model looks like across a five-year window.

Where the cost actually lives

When a head of engineering signs off on a connector project, the estimate almost always covers four things: discovery, build, test, ship. Discovery is the engineer reading the API docs and the source code. Build is the connector code itself. Test is the integration test suite. Ship is the deployment and the runbook. Call it 6–10 weeks per product, depending on auth complexity and surface area.

That's the part you budget. It's roughly 20% of what you'll actually spend over the connector's life.

The other 80% is maintenance, and it splits across four categories most teams don't track as a single line:

• API drift. Your product's API changes — new endpoints, deprecated fields, renamed parameters, changed response shapes. The connector has to track every change. If it doesn't, agent calls start returning silently wrong data, which is worse than failing loudly.
• Auth lifecycle. Tokens expire. OAuth scopes get tightened. SSO providers change endpoints. Service accounts get rotated. Every auth change is a connector change, and every connector change needs to ship without breaking the live agents using it.
• Schema and behaviour changes. A field that used to be required becomes optional. A boolean becomes an enum. A synchronous call becomes async with a webhook. The agent doesn't know any of this happened — the connector has to absorb it.
• Model and protocol updates. Anthropic ships a new tool-calling format. OpenAI tightens its Responses API schema. A Model Context Protocol (MCP) revision — for example, the 2026-07-28 release lifting tool input/output schemas to full JSON Schema 2020-12 — changes the tool definition contract. Each one is a small change you'd ignore for a regular SDK, and a forced refactor for an agent connector.

None of these are catastrophic in isolation. The problem is they're constant, parallel, and not visible until something breaks in production.

Why the standard estimates are wrong by an order of magnitude

Most connector cost models are wrong because they're built on a single-product assumption. One team, one product, one connector. At that scale, maintenance feels like background noise — the same engineer who built it can patch it on a Friday afternoon.

Now imagine the same team with eight products, each with its own API generation, its own auth model, its own deprecation cadence. Each connector still only needs a Friday afternoon. But there are now eight Fridays per cycle, and the cycles overlap. Two of the products are mid-migration. One is being sunset. One just hired a new platform team that's rewriting half the surface. The Friday afternoons turn into a full-time job for two engineers. Then three. Then the project gets a name and a Jira board, and somebody starts calling it the integration engineering tax.

The widely cited MuleSoft Connectivity Benchmark numbers make the same point at scale: IT teams spend roughly a third or more of their time on custom integrations rather than innovation work (39% in the 2025 report, 36% in the 2026 update), and integration debt costs the average organisation around $6.8M per year. Those numbers come from the pre-agent world, when integrations meant connecting third-party systems. The agent era adds a new category — integrations between agents and your own products — on top of the existing load. The percentage doesn't go down. It goes up.

The second reason the estimates are wrong: connectors are usually owned by whoever built them, not by a platform team with a maintenance SLA. When the original engineer moves teams or leaves, the connector becomes orphaned code. The next person to touch it spends a week reading what the previous person wrote, then patches the symptom rather than the cause, because they don't know the system well enough to do anything else. Compounding interest on technical debt is real, and connectors generate it faster than most internal services.

The three options every team considers, costed honestly

There are essentially three ways to get agents access to your products at portfolio scale. Each has a connector maintenance cost profile. The trick is to look at the five-year total, not the first-year build.
‍

The rewrite option is the one CFOs hate and engineers respect. It's the right answer if you have one product and a two-to-five-year horizon. It's the wrong answer if you have eight products and a board meeting in March. The bespoke connector option looks cheap on day one and turns into the integration engineering tax by year two. Generation changes the slope of the maintenance curve — that's the actual claim worth evaluating, not the year-one savings.

What "automated maintenance" actually has to do

It's easy to say connector maintenance can be automated. It's harder to specify what that automation has to actually do, because the failure modes are subtle.

At minimum, automated maintenance has to:

1. Detect API drift before it reaches production. When your product's API changes — through a code change, a schema change, or a behavioural change — the maintenance system has to notice. Not after an agent call fails; before. That means scanning the codebase or the spec on every change, not waiting for a deprecation notice.
2. Regenerate the affected tools without manual rewrites. Detecting drift is half the job. The other half is updating the connector to match, automatically, and shipping it through the same CI and test infrastructure as the rest of your product code. If a human has to hand-edit the connector every time, you haven't automated maintenance — you've just added an alert.
3. Preserve behavioural contracts during regeneration. The agent has expectations of what the tool does. Regeneration can't silently change those expectations. The maintenance system needs to surface breaking changes as breaking changes, not absorb them into the connector and let them propagate to the agent.
4. Keep auth state coherent across regenerations. Tokens, scopes, and identity propagation have to keep working through a regeneration cycle. If the auth lifecycle resets every time the connector regenerates, you've created a worse problem than the one you started with.

This is the gap between "we generate connectors" and "we maintain connectors." Generation is a one-time act. Maintenance is a continuous discipline. Vendors that only do the first are leaving the harder, more expensive half of the problem on your team.

How to model your own connector maintenance cost

If you want to make this a budget conversation instead of a hand-wave, here's the model worth running. It's rough — the point is to get the shape right, not the decimal place.

For each product you need agent access to, estimate:

• Build cost (one-time): engineer-weeks to research, write, test, and ship the connector. Multiply by fully loaded weekly cost.
• API change cadence (annual): how many times per year the product's API surface changes in a way that would affect a connector. Look at your last 12 months of release notes; the answer is usually higher than people expect.
• Maintenance cost per change: engineer-days to detect, patch, test, and redeploy the connector. Don't forget the time spent figuring out which downstream agent broke and why.
• Drift detection lag: how long, on average, between an API change and somebody noticing the connector is out of date. This is the silent-failure cost — it usually shows up as a customer escalation, not a monitoring alert.

Multiply across your product portfolio and across a five-year window. If the number doesn't shock you, you're undercounting one of the four. The most common omission is the drift detection lag, because it doesn't show up in any tracked metric until it does. The second most common is auth lifecycle work, which gets booked to "security" rather than "integration."

Once you have the number, the question stops being "should we build connectors?" and starts being "which option has the lowest five-year total cost given our product count?" That's a much more honest conversation.

How Pontil fits

Pontil is a Tools-as-a-Service platform. We make SaaS products accessible to AI agents, and we treat connector maintenance as the actual product, not a side effect of generation.

The maintenance model matters because the alternative — bespoke connectors maintained product by product — is exactly the line item this article is about. Generation that ships and then drifts is a worse problem than no connector at all, because the agent keeps calling and the data keeps getting subtly wrong. We operate on the systems you own, against the APIs that exist, with tools that stay current as your products change. Your CI, your tests, your observability — they all still apply.

If you want to see what that looks like against your own portfolio, book a walkthrough. The conversation usually starts with a five-year cost model, not a feature list.

What does honest connector economics look like in your portfolio?

The connectors you build this quarter will still be running, or rotting, in 2031. The question isn't whether to build them. It's whether the team building them is also the team maintaining them, and whether anybody has costed that work out past the first invoice.

Most agent project budgets stop at the build line. The teams who get to production are the ones who keep going — who put a number on the maintenance curve, compare options on five-year totals, and decide which slope they can actually afford to climb. That's not a tooling decision. It's a financial one, and it's overdue at most companies building agents on their own products today.

If you walk out of your next planning meeting with a five-year connector cost number on a whiteboard, the rest of the agent strategy gets a lot easier to argue.