Shiny protocols and slick decks: how the wrong AI architecture gets chosen

In most organisations, the decision about how to build an AI-enabled application is not made in one place. It is made in two. Engineers make a version of it from below, looking at the ecosystem and picking up what looks current. Executives make a version of it from above, looking at the market and buying from whoever brings the most convincing pitch to the meeting. The two decisions are rarely reconciled, and both are vulnerable to failure modes that happen to be at their worst precisely now.

The engineer's failure mode is chasing. A new protocol lands and looks like the answer. Then another lands and looks like a better answer. Then another. The team rebuilds around each one, feeling productive the whole time, and arrives after eighteen months with a codebase that has been rebuilt three times and has less functionality than the first attempt. If you have ever watched a group of seven-year-olds play football, you have seen this behaviour: the ball moves, everyone swarms to it, nobody holds a position, and at the end of ninety minutes there is a great deal of running and not very much football. The chasing feels like staying current. It is staying in one place and redecorating.

The executive's failure mode is buying. A software company sends a polished deck that promises to solve every AI-related concern the organisation has — governance, observability, agent catalogues, a control plane, a unified fabric — in one product, integrated with tools the organisation already uses. The pitch is good because the people giving it are good at giving pitches. The product is also good, in the specific ways the deck emphasises. What the deck does not say is that the product defines the shape of the AI-enabled applications the organisation will build, in ways that are difficult to undo and align primarily with the vendor's interests. The purchase feels like a strategic choice. It is a strategic commitment, which is not the same thing.

Both failures are happening now. Both will look, in 2028, like the obvious mistakes they already are.

The engineer's failure mode, closely

The engineering side of the pattern is the easier one to name because it has a long history. Every generation of software engineers has chased the technology of the moment. The chasing is not irrational — a new tool is often genuinely better than the previous one — but the cumulative cost of chasing is usually underestimated, because each individual step looks small and each individual step is usually defensible.

In the AI case, the cost is higher than in previous cycles because the protocol surface is central to the application in a way that, say, a build tool is not. If you adopted webpack in 2016 and replaced it with Vite in 2023, your application's domain logic did not change. If you built your AI application around the Claude API in 2023 and rebuilt it around MCP in 2024 and are now being asked to handle A2A inbound and outbound, the thing that changed is the heart of your application. Each step was a full architectural reorganisation disguised as a migration.

The engineers are not wrong to want to use the new protocol. MCP is a good protocol. A2A is a good protocol. Whatever comes next will probably also be good. The mistake is allowing any of these to become a central commitment. What is wrong is not the protocol choice; it is the architecture that makes the protocol choice structural. An architecture that requires a rewrite every time the ecosystem's centre of gravity shifts is an architecture that is in the wrong business. Its job is to serve the application's domain. Its job is not to be in fashion.

The executive's failure mode, closely

The executive side of the pattern is stranger, because the executives in question are often experienced, competent, and sceptical of their own impulses. How does a good deck beat their scepticism?

Three reasons, roughly.

The first is that the deck maps onto a familiar shape. Every enterprise of any size has bought an ERP, a CRM, a content management system, a DevOps platform — broad categories of software that promise to absorb a domain and hand back a governed version of it. The AI-governance deck arrives and fits the same slot in the executive's mental model: buy one thing, get governance over a messy domain, issue one invoice. The mental model is not wrong for ERP. It is wrong for the AI case, because the AI case is not yet well-enough understood for a single product to responsibly absorb it, and the vendors doing the absorbing have their own reasons to standardise the absorbing on their own terms.

The second is that the deck answers questions nobody else is answering. The engineers have been saying "we're building it" for eighteen months and asking for patience. The vendor says "we have the thing you're trying to build, and it works today, and the Fortune 500 uses it, and here are the logos." The executive chooses decisiveness. It feels responsible. Responsibility to a shareholder presentation is a different thing from responsibility to the organisation's five-year flexibility, but the two are easy to confuse in the moment.

The third — and this is the one most worth watching — is that the vendors making the best pitches have priced the sales motion into the product, and are therefore the loudest, regardless of whether they are the best fit. Loudness is a proxy for quality in many markets but a false proxy in this one. The product being pitched most aggressively is not usually the product built most carefully. It is the product backed by the organisation with the most commercial runway. The two are sometimes the same, but only sometimes, and not in a way that can be told apart from the deck.

What the two failures have in common

The two failure modes look different but share one property: both pick a direction before the direction is clear.

The engineer picks a protocol. The executive picks a platform. In both cases, the choice converts a technology that could have been a replaceable edge into a structural commitment. The engineer's rebuild-around-MCP choice makes MCP structural; when A2A arrives, MCP is no longer optional. The executive's purchase of an agent fabric makes the fabric structural; when the fabric's roadmap diverges from the organisation's needs, the fabric is no longer optional.

Neither of these choices is inherently wrong. A structural commitment to MCP would be fine if MCP were the final answer. A structural commitment to a vendor's agent fabric would be fine if that fabric were the final answer. The bet is that the thing chosen is the final answer. The bet is being made now, in a market that is nowhere near having a final answer, by people who cannot possibly know whether they are right. The bet often loses.

What actually survives

The architectures that are going to look sound in 2028 share one uncommon feature: they do not require anyone to pick the winner in advance. They treat the protocol as something that can change. They treat the platform, if one is present, as one component among several rather than as the environment the application lives in. They let engineers adopt the new protocol when it arrives without requiring a rewrite. They let executives buy a vendor component without making the vendor a prerequisite for everything the organisation does. The concrete shape this takes is the subject of a separate piece — Your AI application has the wrong shape — and is worth reading alongside this one.

This posture is neither exciting nor sellable. It does not produce a keynote-worthy announcement. It does not produce a decisive executive moment. It produces an application that keeps working, quietly, through several cycles of ecosystem change, at the cost of not being in the keynote and not having a vendor's logo at the top of it.

That is, in fact, what a good architecture usually looks like in a market that is still figuring itself out. It is unexciting in proportion to how well it is doing its job.

The question to ask, in both directions

For the engineer about to adopt the new protocol, the question is not "is this the right protocol?" The question is "does my architecture require me to know?" If yes, the architecture is wrong. If no, adopt the protocol with pleasure; it is now a small edge component that can be replaced when the next one arrives.

For the executive evaluating the platform pitch, the question is not "is this the right platform?" The question is "does my organisation's AI architecture require a platform choice to be made?" If yes, the architecture is wrong, and the right response to the deck is to fix the architecture before making the platform choice. If no, the platform becomes a component, usable where it helps, ignored where it does not, replaceable when something better appears. The invoice becomes optional. The roadmap dependency evaporates.

The version of the AI-enabled organisation that survives the next five years is the one that is indifferent to which protocol wins and which vendor sells the best. It is not indifferent because it does not care; it is indifferent because its architecture makes the question irrelevant. That indifference is the strategic asset. Everything else is motion.