The question the reboot answers by accident
This series began with a system everyone routes around. Part 1 explained how a CRM becomes a system of resistance, and why rip-and-replace re-platforms the mess. Part 2 rebooted the layers; containers under the record, open CDC streaming its data into PostgreSQL and OpenSearch, modern screens on the workflows that matter. Part 3 put intelligence inside: permissions-aware retrieval joining records with documents, open models running where the data lives.
Step back and look at what you have built. It is not a modernized legacy system. Somewhere along the way, the thing quietly changed category. The record became a service. The data became a stream. The screens became a layer. The intelligence became a layer. Nothing is welded to anything.
There is a name for this, and it is where the series has been heading all along: the composable CRM.
From monolith to composition
The CRM you started with was a monolith in the truest sense: the record, the business logic, the screens, the reports, and the roadmap all in one box, all from one vendor, all ageing at the same speed. That coupling is why it resisted, you could not change one part without fearing for the rest.
The rebooted architecture inverts every one of those couplings. The record does one job; being the trusted, rule-enforcing system of record and everything else composes around it through open interfaces: the replica for reading at scale, the record’s own APIs for writing, open frameworks for the screens, open retrieval and open models for the intelligence.
Composable means exactly this: each capability is a part you can swap, upgrade, or replace on its own schedule, without a migration, without permission. The parts are held together not by a vendor’s product boundary but by interfaces you control.
The composable CRM
The standards arrived just in time
For years, the honest objection to composition was integration: every part you own is a part you must connect. The agent era has answered it and, unusually for enterprise IT, answered it with open standards rather than another proprietary platform.
Two protocols now anchor the landscape. The Model Context Protocol (MCP) has become the de facto standard for connecting AI agents to tools and data - thousands of servers, every major model provider behind it. Its complement, Agent2Agent (A2A), standardizes how agents discover and coordinate with each other. And the structural fact that matters most for this series: both are now governed by the Linux Foundation’s Agentic AI Foundation, with Anthropic, Google, Microsoft, and AWS at the same table. These are not one vendor’s protocols. They are infrastructure, which is precisely what makes them safe to build on.
For the rebooted CRM, the implication is direct. Put an MCP server in front of the record and its replica, and your twenty-year-old CRM becomes a first-class citizen of the agent ecosystem: any agent, from any framework, can read its knowledge and with the right authority, act through its APIs. The system everyone routed around becomes the system everything connects to.
The two-layer standard
Where agents fit and where they do not
Our first series earned its conclusions by being skeptical about AI theatre, and the finale will not abandon that discipline now.
Agents extend the Part 3 assist from answering to doing: registering the return order, scheduling the engineer, drafting the customer communication; multi-step work that today consumes an agent’s afternoon. The two-layer architecture keeps this sane. Vertically, MCP connects an agent to the record, the replica, and the knowledge corpus with the same permissions the CRM already enforces. Horizontally, A2A lets your service agent coordinate with the logistics agent or the finance agent without either exposing its internals.
But the guardrails from both series still hold. Writes go through the record’s own APIs, so every rule the CRM enforces still applies, the record remains the governor. Consequential actions carry approval boundaries: the human confirms; the agent executes. And every action is logged against the record, which means agent work is auditable in the same place human work is. Autonomy is not the goal. Leverage under governance is.
Buy versus build, honestly
Here is what has changed in the buy-versus-build question since Part 1: the major vendor agent platforms now speak MCP and A2A too. That is good news in both directions.
If you buy, the standards are your insurance: insist on open-protocol access to whatever you adopt, and a future exit remains an engineering task rather than a hostage negotiation. If you build, the standards mean your work composes with everything else, including the things you buy later. The question from Part 1: how much of the stack around your record do you want to own - finally has a precise answer: own the record’s interfaces, the data, and the knowledge, because they are your differentiation. Rent what is commodity. The standards make the seam between the two clean.
A shorter roadmap of capabilities, not migrations
So, what does the five-year CRM roadmap look like after the reboot? It stops being a list of version upgrades and starts being a list of capabilities: expose the record through MCP this quarter. Add the returns workflow to the assist next. Give the field-service team their wave. Swap the model when a better one ships - it is a part, not a platform. Retire the last batch export. Each item lands in weeks, pays back on its own, and none of them requires the word "migration."
That is the arc of both series, closed. Enterprises that win with AI treat it as a way of thinking, not a project, and enterprises that win with their systems of record treat them as a foundation to compose on, not a monument to replace. The resistant CRM was never the enemy. It was the asset, waiting for its layers to be set free.
The composable CRM is not something you buy. It is something you assemble and own.
The five-year roadmap, rewritten