Your Integration Backlog Is a Protocol Problem

Every integration backlog is a queue, and a queue has two rates. Enterprises spend all their energy on the one they can see — how fast items get finished — and almost none on the one that decides whether the queue ever empties.

The spreadsheet comes out once a quarter, and by now everyone in the room recognises the ritual. There are somewhere between forty and a few hundred rows on it, each one a request to connect two things that do not currently talk: the claims system to the document store, the CRM to the pricing engine, the new analytics tool to the four systems it needs to be useful, the assistant someone in operations was promised to the six places its answers would have to come from. Each row has an owner, an estimate, and a priority that has been renegotiated so many times it no longer means anything. Somebody points out that the team shipped more integrations last year than in any year before it, and somebody else points out that the list is roughly the same length it was twelve months ago, and the meeting moves on without anyone naming the contradiction, because naming it would require admitting that the last twelve months of extremely competent work did not change the thing everyone was trying to change.

That contradiction is the whole story, and it is not a story about capacity. A backlog is a queue, and a queue's length is not governed by how hard the people serving it work. It is governed by the relationship between how fast items arrive and how fast they leave. An organisation that doubles its integration throughput and finds the list unchanged has not failed to work hard enough; it has discovered, without quite processing the discovery, that its arrival rate rose to meet its service rate. Every intervention the enterprise reaches for — a bigger platform team, a systems integrator on retainer, a middleware purchase, a heroic quarter where the backlog gets driven down to eleven items and somebody sends a celebratory email — is an intervention on the service side. None of them touch arrivals. And in a queue where arrivals are the binding constraint, service-side heroics buy you a temporary dip and nothing else.

Where the arrivals actually come from

To attack the arrival rate you have to be honest about what generates it, and the honest answer is uncomfortable, because it implicates the way connections get built rather than the people building them. Every row on that spreadsheet is a request for a bespoke translation. Two systems need to exchange something, and because neither was designed with the other in mind, someone has to sit down and work out what this system calls a customer and what that system calls an account, which field carries the identifier that is actually stable, what the authentication handshake looks like on each side, what the pagination semantics are, what happens when one side returns partial results, and how all of that gets encoded into a piece of code that exists solely to sit between these two particular parties. That artefact is not a general capability. It is a private treaty, negotiated between two counterparties who each invented their own conventions, and its terms apply to nobody else.

Once you see each item as a private treaty, the arrival rate stops being mysterious. New treaties get demanded every time a new party appears in the room, because nothing that was agreed previously carries over. A new SaaS purchase arrives with its own conventions and needs treaties with everything it touches. A new consumer — an analytics layer, a portal, an assistant — needs its own treaties even to reach systems that have been integrated a dozen times already, because those dozen integrations were negotiated for other counterparties and are not available to this one. The organisation is not connecting systems; it is accumulating pairwise agreements, and pairwise agreements do not compose. That is why a team can genuinely be getting better at building integrations, quarter over quarter, while the backlog refuses to shorten. Skill improves the service rate. The absence of shared convention is what sets the arrival rate, and it is completely indifferent to how skilled anyone has become.

There is a second, quieter source of arrivals that most backlog reviews never account for, which is that finished integrations do not actually leave the system. They graduate into maintenance and then re-enter the queue under different names. A vendor deprecates an endpoint and a treaty has to be renegotiated. A field that used to be optional becomes mandatory. An identifier changes meaning after a migration that nobody thought to flag to the twelve pieces of glue code depending on its old meaning. A rate limit tightens and a batch job that had worked for three years starts failing silently at month-end. None of these show up on the spreadsheet as integration requests, but they consume the same engineers, from the same finite pool, and they arrive at a rate proportional to the number of treaties already signed. Which produces the genuinely vicious property of this particular queue: every item you complete permanently raises the floor of your future arrival rate. Working through the backlog faster is not neutral with respect to the backlog. It is, in a real sense, how you build a larger one.

Why a quarter of heroics restores itself

This explains the pattern that experienced platform leaders recognise instantly and rarely have language for. A team clears the backlog — really clears it, with a war room and a freeze on new requests and a genuine push — and for a few weeks the list is short enough to read on one screen. Then, without any single dramatic event, it comes back. Not because the team relaxed, but because the freeze was a temporary suppression of arrivals rather than a change in what generates them, and the moment it lifted, the same generator resumed at the same rate, now with a larger installed base of treaties feeding maintenance re-arrivals into it. The backlog is not a pile of work with a bottom. It is the visible surface of a process, and processes restore themselves.

The economic consequence is that integration cost behaves like a subscription the enterprise never consciously bought, and it is a subscription whose price rises with the size of the estate. This is a large part of why ambitious programmes stall in ways that get attributed to the wrong cause. When Gartner predicted that more than forty percent of agentic AI projects will be cancelled by the end of 2027, it pointed at escalating costs and unclear business value, and in a great many enterprises the escalating cost is precisely this: a project that was scoped as a reasoning problem turned out to be a request for two dozen new private treaties, each of which had to queue behind everything else already in flight. The model was never the expensive part. The negotiations were, and they were expensive because every one of them started from nothing.

A protocol changes what a new connection costs to ask for

The reason protocols matter here has nothing to do with elegance and everything to do with which rate they act on. When two parties share a convention, a new connection is no longer a negotiation; it is a registration. The work of deciding how tools are described, how they are discovered, how they are invoked, how results and errors come back, and how a session is established gets done once, in public, and every subsequent participant inherits it instead of reinventing it. That is what the Model Context Protocol is: an open protocol that gives AI applications and the systems they need to reach a shared way of exposing and consuming tools and data, so that a system publishes its capabilities once against a common convention rather than repeatedly against each counterparty's private one.

The effect on the queue is structural rather than incremental. Under private treaties, the arrival of a new consumer generates a request against every system it needs; under a shared convention, it generates none, because the systems it needs are already speaking a language it already understands. The arrival rate stops scaling with the number of relationships in the estate and starts scaling with the number of systems that have not yet been exposed — a set that is finite, enumerable, and shrinking, which is exactly what the old backlog never was. This is also why the practical question for most enterprises is not whether the protocol is sound but how the existing estate joins it, since the systems generating the most backlog are usually the ones nobody wants to touch. Capabilities like StudioX's Instant MCP exist to answer that question by turning APIs an organisation already runs into Model Context Protocol servers, which matters less as a convenience than as the moment the arrival-rate curve bends — the point at which a system stops being a permanent source of new integration requests and becomes something that new consumers can simply use. The wider argument for why this reorganisation of enterprise plumbing precedes any serious autonomy programme is made at length in the category's body of work on the autonomous enterprise, and its core claim is the one this queue has been demonstrating all along: the constraint on enterprise AI is rarely intelligence and almost always connection.

The mental model worth leaving with is that backlog length is a vanity metric, in the same way that a fever reading tells you something is wrong without telling you anything about what. The number that predicts your next three years is the arrival rate — how many new bespoke translations your architecture demands per new system, per new consumer, per vendor change — and the only interventions that move it are the ones that replace private negotiation with shared convention. Judge any proposal by that test. If it makes your team faster at signing treaties, it is a service-rate intervention and the list will be the same length next year no matter how much faster they get. If it means the next connection does not have to be negotiated at all, it is the only kind of work that ever empties a queue.