Integration Debt, Part 3: Acting Without the Receipts

Most business decisions wait for a business case. Integration debt doesn't offer you one, and by now that shouldn't be a surprise. Part 1 laid out a mechanism that holds up under scrutiny: the combinatorics of connecting systems, the ownership vacuum between them, the silent way failures propagate. Part 2 showed the dollar figures attached to that mechanism mostly don't hold up, on either the cost side or the consolidation side. So what do you do with a well-evidenced mechanism and statistics you can't trust?

Three things that follow regardless of which tools you use

Every new tool is a decision about the whole system, not just the team adopting it. The marginal cost of adding tool number twelve isn't the price of tool twelve. It's the combinatorial cost of however many new connections it creates with the eleven tools already in place. Nobody budgets for this because nobody owns it, which is exactly the vacuum the term integration debt describes. The practical fix isn't a tool. It's a habit: whoever approves a new SaaS purchase asks who's going to own its connections to everything else, before the purchase, not after the first sync failure.

Assume you're already carrying debt you can't see. Part 1's most important point was that broken integrations usually fail silently rather than loudly. If your systems have been running without visible errors for a year, that's evidence of nothing. It's consistent with everything working, and equally consistent with a slow accumulation of duplicate records or dropped events nobody has looked for yet. The move that actually fixes this isn't more monitoring dashboards. It's periodic reconciliation: does the record count in system A match system B, does the total in the CRM match the total in the accounting system, checked on a schedule, not assumed.

Treat consolidation as a reasonable bet, not a proven cure. The logic holds up on its own terms: fewer systems produce fewer connections, and that follows directly from arithmetic, not opinion. But Part 2 showed plainly that no rigorous case study exists proving a specific percentage improvement from consolidating, on either side of this topic. Treat it the way you'd treat any sound architectural principle without a controlled study behind it: reasonable to act on, not proven by the numbers, because those numbers don't currently exist.

Where this is headed

One more thing matters before deciding anything: AI agents are currently making this worse, not better. A 2025 MuleSoft and Deloitte benchmark of 1,050 IT leaders found that AI-agent adopters run more applications on average, 1,103, than non-adopters, 762. The instinct that AI will finally tie every system together isn't wrong long-term, but the near-term evidence says agent adoption is expanding the integration surface, not shrinking it.

The most credible standardized answer so far is MCP, the Model Context Protocol introduced by Anthropic and now backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg through the Linux Foundation. It gives AI agents one standard way to reach enterprise tools and data instead of bespoke glue per agent per tool, and Anthropic's own adoption numbers suggest this is more than an announcement. But the governance questions it raises, who's allowed to connect an agent to what and how it's audited, are the same ownership question integration debt has always posed, just pointed at a faster actor than a human integration builder ever was.

Where we sit in this

We build custom ERP deployments, which puts us on one specific side of the tradeoff this series has been describing, so it's worth being direct about what that does and doesn't mean.

The honest case for consolidation isn't that it eliminates integration debt. Nothing does, as this whole series has tried to show. It's that it changes what kind of debt you're carrying, from something you don't control (a vendor's task-metering scheme, an undocumented sync behavior) to something you do: code your own team, or whoever you hire, can actually read, version, and fix when it breaks. That's a real advantage, but not a free one. It trades rented complexity for owned complexity, and owned complexity still needs someone competent maintaining it. A self-hosted ERP with unmaintained custom integrations isn't meaningfully better off than a pile of unmonitored Zaps. It's just a different kind of unmonitored.

The point where this becomes a genuine engineering decision rather than a philosophical one is when a team's automation layer has grown past what anyone can reason about: dozens of workflows, no one person who understands all of them, and the first silent-failure incident that cost real money. That's when it's worth asking whether the fix is a better-governed middleware layer, or whether enough of the business logic belongs inside one system you own outright. We don't think that's the right call for every company at every stage. Plenty of teams are well served by Zapier or Make for a long time. But it's a real inflection point, one we've helped clients think through directly, without pretending the decision is backed by better numbers than actually exist.

What this series was really about

Integration debt is a useful name for something every growing company already feels and rarely discusses precisely: the accumulating, unowned cost of connecting systems that were each adopted for good local reasons and never designed to work together. The mechanism behind it isn't speculative, and the vendors' own documentation confirms pieces of it directly. What's still missing, a decade after the term was coined, is the case-study literature that would let anyone put a confident number on it, on either side. That's not a reason to dismiss the concept. It's a reason to keep asking, every time a new tool gets added to the stack, who's going to own the connection it just created, and to be honest about the difference between a mechanism you can verify and a statistic you can't.