---
title: The Tool Plane
url: https://revworx.ai/architecture/9/
date: 2026-10-20T14:59:15+00:00
modified: 2026-11-08T03:08:05+00:00
lang: en_US
---

Section 9 · Part two

# The Tool Plane

The Tool Plane is everything the system can actually do, exposed as one MCP surface and reached through progressive disclosure. It is organized into seven clusters grouped by what each capability does for your business, not by vendor. A cluster is a stable idea with changing membership, which is where the architecture absorbs most of the ecosystem's churn.

In this section

[9.1Own the record, rent the capability](#9-1)[9.2Capability as the unit of integration](#9-2)[9.3Spending money needs a gate, not a policy](#9-3)[9.4Making the infrastructure addressable](#9-4)

Part two

[§7The shape of the architecture](/architecture/7)[§8The Cognition Plane](/architecture/8)

§9The Tool Plane

[§10The Execution Plane](/architecture/10)[§11The Data Plane](/architecture/11)

[Download the PDF →](/wp-content/uploads/2026/10/composable-reference-architecture.pdf)

In brief

The Tool Plane is everything the system can do, exposed as one MCP surface and reached through progressive disclosure. It is organized into seven clusters by what each capability does for your business, not by vendor. Own what holds the record, put spending approvals in the tool layer and make the infrastructure addressable.

Figure 7 shows the seven clusters. Six of them do the work of go-to-market. The seventh, Infrastructure, is what lets the system extend itself, and Section 10 returns to it. Beneath the clusters sits a separate idea: the channel surfaces through which the system reaches a prospect. They are provided by the clusters rather than being tools in their own right, and Section 13 gives them the attention they need.

![Figure 7 — The Tool Plane: seven clusters and the channel surfaces they provide](https://revworx.ai/wp-content/uploads/cra-figure-7-tool-plane.png)

*Figure 7 — The Tool Plane: seven clusters and the channel surfaces they provide*

## 9.1Own the record, rent the capability

The most consequential choice in the Tool Plane is what the CRM is. 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. This architecture takes the second path, and the reasoning generalizes.

Per-seat pricing 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 master customer record in someone else's database structure, and owning the record wins.

The general rule is to own your master records, and the connection to whatever holds them, and rent the systems that provide commodity capability. That rule is also what keeps the Tool Plane composable: rented capabilities can be swapped freely because none of them holds the record.

Current implementation

**GTM Operations**: an all-in-one CRM, reached through an MCP server we built that gives the agent one clean way to talk to the CRM and hides its two underlying interfaces; WooCommerce, driven through the same WordPress surface the content agents use; a second server we built for the in-venue lead-capture tooling; LinkedIn extraction with waterfall enrichment; self-hosted social scheduling. Those two servers are the only custom-built components in the stack. Everything else is off the shelf.

## 9.2Capability as the unit of integration

Data intelligence is where the MCP model differs most from the SaaS model. The SaaS unit of purchase is a dashboard: you buy a product and get the twelve things it does. The MCP unit is a capability: one addressable function, called when needed. Adding reputation monitoring therefore means switching on one more capability, not evaluating a product.

Conversational intelligence adds one more reason to own the record. Self-hosting the transcript pipeline moves the full record of what your customers actually said onto the owned side of the Data Plane, instead of renting it back from a vendor's cloud.

Current implementation

**Conversational Intelligence**: Vexa, fully open source and self-hosted with a native MCP server, providing full meeting transcripts rather than summaries, plus action-item extraction; a chat widget server running the WEB Agent, the public AI concierge, as a surface of the same Agent Zero instance that serves operators.

**Data Intelligence**: scraping servers for reputation, social, property records and directories; self-hosted Umami for site behavior; a keyword research server; and one search-listening tool reached through browser automation, the only non-MCP path in the stack.

## 9.3Spending 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. This architecture enforces operator confirmation inside the tool itself, so no drift in the agent's instructions can route around it. Login credentials are supplied at the moment of each call and never held by the agent.

Scope matters too. A paid-media tool that also manages measurement and product feeds lets a campaign launch create its own conversion tracking in the same pass, and lets a catalog price change reach shopping placements without anyone opening a platform console. Splitting those across tools produces campaigns that run for a week before anyone notices the conversion event was never created.

Workflow automation sits alongside in two modes. One exposes your existing workflows as tools the agent can call. The other lets the Cognition Plane write and deploy new workflows in conversation. The first makes automation available; the second lets the system create it.

Current implementation

**Channel Execution and Workflow**: PaidSync as the primary paid-media tool, with write access to Google, Meta and LinkedIn Ads plus Tag Manager, GA4 and Merchant Center; Pipeboard for Reddit and Snap in a later phase, with campaigns paused by default; Lob for premium direct mail; n8n in both modes. Email, SMS, partner portal and surveys come from the CRM rather than from separate channel tools.

## 9.4Making the infrastructure addressable

The seventh cluster turns a capable system into an extensible one: infrastructure exposed as MCP servers. Setting up servers, deploying software, managing code, running builds and tests, updating domain records and administering the MCP gateway itself all become things the Cognition Plane can call.

Two ideas here sound alike and do different work. *MCP for the infrastructure* gives the agent control of the machines it runs on: start, recreate, inspect, manage storage and networks. *Infrastructure for MCP* is the plumbing that runs the MCP servers themselves: a gateway between agent and servers that supplies credentials and enforces limits, and a curated catalog from which servers can be added and removed mid-session. The first gives the agent hands. The second lets it pick up new ones.

What composes hereEvery server in every cluster. With progressive disclosure, a server is added or removed by changing configuration, with no cost to the context or to the rest of the system. This plane changes fastest, and is built to.

Key takeaway

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.

Cite as: revWorx (2026). A Composable Reference Architecture for Autonomous GTM Operations, First Edition, §9. revworx.ai/architecture/9
