Why Salesforce Needed Contentful (and What Composable Means for You)
On June 1, Salesforce bought Contentful for a rumored $1B+. The headlines covered the price tag and the players. I want to ask (and hopefully answer) a different question, because the answer is the part that actually matters if you run technology for a mission-driven organization.
Why buy Contentful at all?
Salesforce already owned a content layer. Salesforce Knowledge has been the platform's answer to governed, structured content for years. It’s deeply embedded into Service Cloud and well-proven across a range of uses. Salesforce also already had Headless 360, which means its CRM, Agentforce, Data Cloud, and Slack are all callable by other systems without a person logged into a browser. The cheap move was sitting right there: put a modern API in front of what they already had, call it agent-ready, and move on.
They didn't make the cheap move. They spent real money on a composable content vendor instead. That choice tells you something about what an agent actually needs, and it's worth understanding before you make your own decisions about where the agentic wave touches your stack.
The cheap move they didn't make
Let’s first establish some concepts and add a few words to our vocabulary.
A monolith design pattern is a system where the pieces are built together and assume each other's presence. The content, the data, the logic that decides what to show, and the screen it shows up on are all woven into one stack. Salesforce Classic is a monolith. That's not an insult! Monoliths are often easier to run, because everything is already wired together. You don't assemble anything; it comes assembled. The cost is that moving a wall is high effort — it's going to be a whole project.
Now put a door on it. A door is an API in front of the monolith. The building still stands exactly as it was, but you've cut a new entrance so something outside it (an agent, another app) can reach in and call the logic without a human clicking through screens. That's what Headless 360 is. The building didn't change. The walls are where they always were. You just made them penetrable.
Here's the thing about the door: it's the easy half of the connection. Any vendor can expose an API and call itself modern. Lots of platforms ship the door and stop there. What the door gives an agent is reach. What it does not give an agent is the ability to swap out one room without disturbing the rest of the house, or to pull back one precise piece of content instead of a whole rendered page.
Reach is not the same as the right unit of work. And the agent needs the right unit of work.
The expensive move they made
Composable is the opposite construction philosophy. Instead of one building with a new entrance, you have separate pieces (content, search, catalog, pricing), each holding its own structured data, each replaceable without touching the others. You assemble the experience from those pieces rather than inheriting a fixed stack.
There's a clean test for whether something is genuinely composable: can you replace any one piece without disturbing the rest? If yes, it's composable. If pulling out the content layer breaks three other things, it's a monolith with a door, no matter what the marketing says.
Making the pieces genuinely come apart is the hard half of the work. They have to be built meaningfully, with the appropriate context. That's where the cost sits, and it's also where the payoff sits. Salesforce paid for the hard half on purpose, because an agent needs it.
Why an agent needs the pieces, not the blob
An agent works by calling functions and assembling a result. It is far happier with discrete, structured, individually addressable pieces than one fused stack that it has to operate through a single narrow opening. Three mechanical reasons the door-on-a-monolith falls short:
A door returns a blob; an agent needs fields. Monoliths hand back rendered chunks (a page, an article). The agent then has to parse the meaning back out of that chunk, which is lossy and unreliable. Composable stores content as structured, separately addressable fields the agent can retrieve precisely and trust.
Assembly requires combinations the monolith never anticipated. A monolith only renders the fixed combinations its designers built in advance. The whole value of an agent is assembling combinations nobody anticipated, on the fly, in response to a real question. It can only do that if the pieces come apart.
Governance has to live with each piece. The agent needs to know each piece is current and approved at the level of the piece, not at the level of the page. Composable carries that metadata per piece. That's what lets an agent assemble a trustworthy answer instead of reciting a stale blob.
Let’s make this concrete with an example from commerce. Say a customer asks a commerce agent for "a few business-casual outfits, warm enough for a January work trip to Denver, under $300, that I can buy right now."
A monolith with a door hands the agent product pages. The agent has to scrape warmth out of marketing prose, guess whether the price it parsed is still current, and check availability somewhere else entirely. Every inference stacks on the last one, and the errors compound. The agent can fetch pages that exist, but it can't build the combination that was asked for, because that exact combination was never a page anyone built.
A composable stack lets the agent query the catalog (formality, warmth rating), pricing (live), inventory (ships before the trip date), and content (approved styling copy, tagged current) as discrete fields. It recombines them into outfits that satisfy every constraint, and it can stand behind the answer.
That gap, between fetching a page and building an answer, is the whole reason Salesforce paid for the hard half.
The grid that keeps people from talking past each other
Here's where most conversations about this go sideways. People hear "composable" and "single vendor" as opposites, like you're either all-in on one platform or you're stitching together ten best-of-breed tools. Those are two different decisions, and conflating them is the most common mistake in the room.
Architecture (monolith to composable) and procurement (concentrated to diversified) are independent axes. You can pick your position on each one separately.
Composable vs Monolith, Diversified vs Concentrated as a Matrix
I know they're independent because BrightHelm's own stack proves it: we are composable and concentrated. Wall-to-wall Salesforce, deliberately, and still composable underneath.
The empty corner is the tell. Monolith-and-diversified barely exists, because it's the worst of both worlds. You get the rigidity of a fortress and the integration tax of many vendors, with none of the upside of either. Nobody chooses it. The fact that one corner is empty is the proof that these really are two different axes and not one axis wearing two names.
Composable is the architecture. Single vendor is a procurement choice layered on top of it.
What this means if you steward a mission-driven org
Favoring composable, even though it's more work, is a sustainability value with a precise name: low exit cost. Sometimes also referred to as anti-lock-in. Composable lets an organization break up with any one vendor without throwing over the whole stack.
There's an honest tension in that, and I won't paper over it. Composable lowers your exit cost but raises your entry and maintenance cost. You pay an ongoing integration tax to preserve cheap optionality. For a mission-driven organization, that tradeoff is sharper than the generic "composable is greener" line you'll hear at conferences. If you have long time horizons and thin switching budgets, then it’s a real risk to be captured by a tool that drifts away from your mission or your wallet. So the argument isn't "composable is better." The argument is that composable protects an organization that can't afford to be captured.
Now the caveat that matters most, and the one I'd want you to leave with.
Composable has always lost to the monolith on one thing: ease of implementation. The industry pushed hard toward headless architectures, then pulled back, because teams kept retreating to the easier monolith-style build. Composable is powerful but it has been expensive and slow to stand up, and adoption tends to come down to ease over power every single time. For this reason, composable architecture has historically been the niche choice.
So the real bet Salesforce just made is whether agents plus a clean content layer can finally make composable feel as simple as the monolith. If they pull that off, headless stops being the hard road and becomes the default one.
Until they do, here's the honest answer for most nonprofits, public sector, and higher-ed teams BrightHelm works with: composable only becomes relevant to you once it gets monolith-easy. The ease tax is exactly why Salesforce Knowledge, used as-is, is plenty for most of you right now. The signal worth watching isn't the acquisition price or the press release. It's whether Salesforce actually solves ease.
That's the question that decides whether any of this reaches your desk.
And it raises a second question, one that doesn't stay confined to the content layer: if composability moves where the human work happens, where does the human work go? Because it doesn't disappear. It moves. That's the next conversation, and it's the one I think actually changes how we do our jobs.
