Every Architecture Has a Tax. Composability Moves Yours Upstream.

A little while ago I wrote about why Salesforce bought Contentful, and what "composable" actually means once you strip the marketing off it. The short version, in case you're arriving cold: composable architecture means the pieces of your system come apart. Content, search, pricing, catalog — each holds its own structured data, each replaceable without disturbing the others. That's the opposite of a monolith, where everything is woven together and moving one wall is a whole project. Composability has been around for a long time. What's new is that agents strongly prefer the pieces over the blob — they can retrieve exactly what they need, recombine in ways nobody pre-built, and trust each piece is current. (The longer version is over here if you want it.)

That piece was about the product. This one is about the practice — and about a decision that is older than AI, that AI has quietly made more urgent, and that a lot of organizations are about to make by accident.

This was always a change-management choice

Here's the thing worth saying first, because it reframes everything after it: the monolith-versus-composable decision has nothing to do with AI. It never did. It's a change-management choice, and it's always come down to a single honest question — where do you want to pay?

There is no free architecture. Every one of them taxes you. The only question is which tax, and when it comes due.

Choose the monolith, and you pay downstream and later. It's easier to stand up — everything arrives pre-wired, you don't assemble anything. But the tax is deferred, not avoided: when you outgrow it, when you need to move a wall, when you're locked in and the vendor drifts away from your mission or your budget, the bill arrives all at once, and usually under duress.

Choose composable, and you pay upstream and now. The tax comes due early, in the discipline of deciding what the pieces are, how they're modeled, what's true, what's current. You pay it on your own schedule, on your own terms, before anything depends on it.

Neither is free. Neither is wrong. They're just different payment plans for the same underlying cost. This is the part the marketing on both sides papers over: "composable is more flexible" and "the monolith is simpler" are both true, and both incomplete, because neither one is explicit about the tax. You're not choosing whether to pay. You're choosing when, and under what conditions.

What AI actually changed

So if the choice is old, what's new?

Just one thing — but it's a big one. Agents prefer composable so strongly that composability is now a more compelling choice than it has ever been. For years, composable lost to the monolith on the one axis that tips most decisions: ease. It was powerful and slow and expensive to stand up, so teams kept retreating to the easier pre-wired build. Agents change that math, because suddenly there's a powerful, growing reason to want the pieces apart — the thing operating your system increasingly is an agent, and an agent is far more capable when paired with structured pieces than with a fused blob.

Here's the risk hiding inside that good news. When a choice gets this much pull behind it, organizations stop making it and start drifting into it. You adopt agents because everyone's adopting agents. The tooling nudges you toward composable. The vendors nudge you toward composable. And one day you look up and you've taken on the upstream tax — except you never decided to pay it, so you never actually did the upstream work. You backed into the architecture and skipped the discipline that makes it worth anything.

That is the worst way to take on any tax burden: by accident, without the work that justifies it. Which is exactly why you need to understand what composability does to the flow of your work before the pull carries you there.

Composability moves the work upstream

So let's trace it. When you ship a monolith, a lot of the labor lives downstream. You build the rendered page, compile the user-facing documentation, produce the finished artifact a person looks at. The structure underneath can be a little loose, because a human stands at the end of the line to absorb the mess — to read the awkward page, interpret the stale paragraph, figure out what was meant.

Composability pulls that labor in the other direction. When the pieces have to come apart and be individually addressable, the hard work moves upstream: deciding what the pieces are, how they're modeled, what's true, what's current, how they fit. The downstream act of assembly — the part that used to eat your time — collapses toward automatic, because the agent assembles now. What's left, carrying all the weight, is the upstream judgment about how the thing was structured in the first place.

The structuring is the work. That's not a slogan; it's the literal relocation. The work didn't disappear when assembly got automated. It moved to the front and got more consequential, because there's no longer anyone downstream to catch what you got wrong.

Why this is a risk argument, not just an efficiency one

Here's the part I think most people miss, and it comes from a previous career.

Before Salesforce, I served in the Navy as an aviator, and one of my jobs was what we called Evaluator. I taught the instructors how to instruct, and inspected for safety and mission performance. That role came with a lot of training in what we called human factors and performance: everything from the limits of the human body, to the machine-human interface, to how you build procedures that manage the risk both of those introduce. The job, in one line, was inspecting checklists and procedures for the ways they fail under real conditions, and then working upstream to craft practices that prevented those failures — and the frequent  resulting losses of life and limb.

One of the most durable findings in that field is mundane and ruthless: people fail when they have to re-parse under uncertainty. When a procedure is inconsistent — the same thing named two ways, the structure shifting between steps, a format you can't trust to mean what it meant last time — the human operating it has to stop and re-interpret. That pause is where errors get in. Consistency isn't an aesthetic preference. It's a risk control. It removes the moments where someone has to guess.

An agent fails the exact same way. This is the engine under everything in this piece, so it's worth being precise about the two ways it bites.

Failure mode one: don't choose composability, and feed agents blobs. Hand an agent rendered pages and fused stacks, and it has to parse meaning back out of them — re-parsing under uncertainty, exactly like the human with the bad checklist. The errors compound, and the agent is unreliable. This is why agents prefer the pieces in the first place. It's the whole case for composable.

Failure mode two: take on composability without the discipline. This is the one the agent-pull sets you up for. You get the addressable pieces, but because you backed into the architecture instead of doing the upstream work, the pieces are inconsistent — named two ways, modeled three ways, current here and stale there. So the agent re-parses under uncertainty anyway, just at a different layer. Composability without the structuring discipline is how you end up with agents wildin' — confidently assembling wrong answers out of smaller blobs you never made consistent, logical, and trustworthy. You bought the architecture and skipped the judgment that makes it safe.

Same failure mode on both sides of the choice: re-parse under uncertainty. Same fix: consistent, addressable, well-modeled structure. That's the point. Giving agents what they want — composability — obligates you to a specific kind of risk control. The architecture is the easy half; the discipline is the half that determines whether your agents are trustworthy. If you adopt agents and don't understand that, you will get this wrong, and you'll get it wrong in the most expensive way: live, in production, with an agent speaking for you.

We chose this on purpose

I'll keep this short, because this isn't a piece about us. But it's the cleanest illustration of the alternative to falling backward. At BrightHelm we run composable on purpose — not because it's fashionable (for a long time it wasn't, and for most small organizations it still isn't worth it), but because choosing composable means choosing to do the upstream work deliberately rather than inherit someone else's downstream assembly and hope it holds. We decided to pay the tax upstream, on our own terms, with the discipline that makes the architecture actually safe for agents to operate on.

You don't have to make that same bet. The point isn't the choice. The point is that it's a choice — and that the worst outcome is making it without knowing you did.

Find the mechanism. Trace the direction.

So here's the move, and it's bigger than composability.

If you can see the direction a mechanism moves the work, you can choose deliberately instead of getting swept. Composability moves the work upstream — toward modeling, toward judgment, toward the discipline of getting the structure right before anything assembles on top of it. Right now the pull of agents is pushing whole organizations in that direction whether they've reckoned with it or not. The ones who reckon with it first pay the tax on purpose, do the upstream work, and get trustworthy agents. The ones who don't get carried there anyway — and pay the tax late, under duress, with agents already hallucinating in production.

"AI moves the work" is a shrug. Knowing which way a specific mechanism moves it — and that it's moving you whether you decided or not — is a map. Composability is one mechanism, traced end to end. It is not the only one; the same pattern shows up everywhere once you know to look for the vector. But it's a clean one to start with, because you can see every step: the product, the practice, the tax, the direction, the choice.

Find the mechanism. Trace the direction. Then decide — before the pull decides for you.