The most consequential choice in a GTM stack is not which tools you buy. It is where your master customer record lives, and who controls the connection to it. Get that right and almost every other tool becomes something you can rent, swap and retire without a migration project.
Two paths for the CRM
One path integrates a commercial CRM through whatever agent surface its vendor offers. The other connects an all-in-one CRM to the agent through an MCP server you control, and keeps the master record yours. The architecture takes the second path, and the reasoning applies well beyond the CRM.
The pricing model gives it away. An architecture whose point is capability without proportional headcount fits badly with a cost model that charges per person. Add the overhead of an agent surface you do not control, and the lock-in of keeping your customer record inside someone else’s database structure, and owning the record wins.
What should you own, and what should you rent?
- Own your master records and the connection to whatever holds them.
- Rent the systems that provide commodity capability.
That rule is also what keeps the stack composable. Rented capabilities can be swapped freely, because none of them holds the record.
Seven clusters, grouped by what they do
The Tool Plane is organized into 7 functional clusters, grouped by what each capability does for your business, not by vendor. A cluster is a stable idea with changing membership. That is where the architecture absorbs most of the ecosystem’s churn: tools come and go, the cluster stays.
Capability is the unit, not the dashboard
The SaaS unit of purchase is a product: you buy it and get everything it does, whether you need it or not. The MCP unit is a capability: one addressable function, called when needed. Adding reputation monitoring means switching on one more capability, not evaluating another product.
The same logic reaches conversations. Self-hosting the transcript pipeline moves the full record of what your customers actually said onto the side of the line you own, instead of renting it back from a vendor’s cloud.
Spending money needs a gate, not a policy
Paid media is where an agent first spends real money. The question is not whether to allow it but where the approval lives. An instruction in a prompt is a request. An approval gate in the tool layer is a constraint. The architecture puts operator confirmation inside the tool itself, so no drift in the agent’s instructions can route around it, and login credentials are supplied at the moment of each call rather than held by the agent.
Make the infrastructure addressable
The seventh cluster turns a capable system into an extensible one. Setting up servers, deploying software, managing code and updating domain records all become things the agent can call. One half gives the agent hands: control of the machines it runs on. The other half lets it pick up new ones: a gateway and a curated catalog from which servers are added and removed mid-session.
Group tools by business function, own what holds the record, put spending approvals in the tool layer, and make the infrastructure addressable. That last step is what makes the system extensible rather than merely capable.
Read the full section: The Tool Plane
Cite as: revWorx (2026). A Composable Reference Architecture for Autonomous GTM Operations, First Edition, §9. revworx.ai.