When an AI-run GTM system gets something wrong, the first useful question is not what went wrong. It is where. The architecture separates the work into four planes, and the main reason is not tidiness. It is that each plane fails in its own way, and you can only diagnose a failure if you know which plane it came from.
Read the planes from the top down
- Cognition reasons. It decides what to do and in what order.
- Tool is everything the system can do, exposed as one universal MCP surface.
- Execution is the infrastructure those capabilities run on.
- Data holds the state your business owns and the sources it reads.
Each plane fails differently
- A reasoning failure is a bad decision made with good tools.
- A tool failure is a correct decision that cannot be carried out.
- An infrastructure failure removes capability, whatever the reasoning.
- A data failure is confident action on a wrong picture of the customer.
Diagnosis starts with asking which plane is at fault. That question has an answer only if the planes were separated on purpose. In a stack where reasoning, tools and records are tangled together, every failure looks like every other one.
Each plane changes at its own pace
The planes also move at different speeds, and that is the basis of composability.
The shape of the Data Plane is the most stable thing in the system. The Tool Plane turns over fastest, because the ecosystem around it is still maturing. Keep them apart and a tool swap stays routine.
Couple them and the cost changes completely. Let one vendor’s database become your master customer record, and a routine tool swap turns into a migration project.
What this means for your stack
Ask two questions of anything you add. Which plane does it belong to? And does it try to own something that belongs to a slower plane? A tool that wants to become your record of the customer is asking to be very hard to replace.
Separate the four planes because they fail differently and change at different rates. The stable planes protect your business record; the fast-moving ones absorb the churn.
Read the full section: The shape of the architecture
Cite as: revWorx (2026). A Composable Reference Architecture for Autonomous GTM Operations, First Edition, §7. revworx.ai.