There is a quiet pattern in boardrooms. A respected company adopts an architecture, writes a conference talk about it, and within eighteen months that architecture becomes the default answer everywhere — regardless of the question. Microservices. Serverless. Event mesh. And now, agentic AI. The pattern is no longer chosen because it fits the workload. It is chosen because it is what serious companies are seen to do.
That is architecture as fashion. And it is one of the most expensive forms of misdiagnosis a CEO can fund — because the bill does not arrive as a single line item. It arrives slowly, as rising cost, slowing delivery, and a platform that fights every change you ask of it.
Why fashion-led architecture is so expensive
An architecture decision is not reversible at the speed it was made. A pattern adopted in a quarter takes years to unwind. When a company splits a perfectly coherent system into thirty microservices because microservices are what scale-ups do, it does not get scale — it gets a distributed monolith, where every release now requires coordinating thirty deployments and a network call sits between two functions that used to be one.
The cost shows up everywhere except the slide that proposed it:
- Delivery slows, because change now crosses service and team boundaries that did not need to exist.
- Cloud cost rises, because chatty network traffic, duplicated data and idle services are now billed individually.
- Reliability falls, because there are far more things that can fail and far more seams where they can fail silently.
- Hiring pressure increases, because the system now needs specialists to operate complexity it never needed.
None of those are microservices failing. They are microservices applied to a workload that never asked for them. The pattern was not wrong. The diagnosis was.
An architecture pattern is a treatment. Prescribing a treatment because it is fashionable — rather than because the workload demands it — is malpractice, whether in medicine or in technology.
Workload classification comes before pattern selection
The discipline that breaks the fashion cycle is unglamorous and decisive: classify the workload before you choose the architecture. Every workload has a shape, and the shape — not the trend — dictates the right pattern. Five dimensions do most of the work.
- Latency. Does this path need a sub-100ms response, or is it a background job where minutes are fine? The answer rules whole families of patterns in or out.
- Throughput. Is this ten requests an hour or ten thousand a second? Constant load and spiky load want completely different shapes.
- Durability. If a message is lost, is it an inconvenience or a financial and legal event? That determines whether you need guaranteed delivery — and the cost that comes with it.
- Criticality. Does the business stop if this fails, or does it degrade gracefully? Criticality sets your resilience budget, not your taste.
- Cost shape. Is the workload steady (favouring reserved, owned capacity) or bursty (favouring elastic, pay-per-use)? The wrong cost shape quietly doubles a cloud bill.
Run a workload through those five questions and the architecture stops being a debate about reputation. A steady, high-throughput, low-latency core transaction path and a bursty, latency-tolerant batch report are not the same problem, and the same pattern cannot be right for both. Fashion ignores this entirely — it applies one answer to every shape.
Agentic AI is the newest fashion — and the same trap
Agentic AI is now travelling the exact path microservices travelled a decade ago. A demo is impressive, a board asks why the company doesn't have agents, and suddenly agents are being prescribed for workloads that are deterministic, well-understood, and far better served by a simple rule or a single API call.
An autonomous agent is an architecture choice with a specific shape: it is non-deterministic, it is comparatively expensive per action, it is harder to test, and it needs governance the moment it touches anything that matters. For an ambiguous, judgment-heavy, genuinely variable task, that shape is exactly right. For a task that runs the same way every time, wrapping it in an agent adds cost, latency and unpredictability to something that was already solved. Same trap, new label.
Evidence-driven, not fashion-driven
This is precisely where prescription has to be earned rather than assumed. The Growth Transformation Tx™ treatment classifies workloads before it selects patterns — so the architecture that gets funded is the one the evidence demands, not the one the market is currently admiring. A pattern only enters the plan once a workload has been characterised by its real latency, throughput, durability, criticality and cost shape.
The result is an architecture that is frequently less fashionable and far more effective. Sometimes the right answer is a well-built modular monolith. Sometimes it is two services, not thirty. Sometimes the right AI decision is a deterministic pipeline with a model called at one specific step, not an autonomous agent. These answers do not make conference talks. They make systems that scale, stay affordable, and ship.
For a CEO, the test is simple. When someone proposes an architecture, ask one question: "Which workload demanded this, and what is the evidence?" If the honest answer is the name of a company that adopted it, or the phrase "it's where the industry is heading," you are about to fund fashion. If the answer is a classified workload with measured requirements, you are about to fund a treatment that fits the disease.
Before approving any architecture, demand to know which classified workload demanded it — if the justification is reputation rather than evidence, you are funding fashion, and you will pay for it for years.