- GTM Motion Diagnostic — the framework and go/no-go filter
- GTM Intelligence Stack in 2026 — the market research
- The GTM Intelligence Platform — the architecture (you are here)
- Deal Risk Monitor — the app (coming soon)
I built the manual version of this system inside a large cloud platform. A progression model tracking over a thousand enterprise accounts. A strategic subset focused on the highest-value deals. Consumption intelligence assembled from telemetry data. Operating cadences that became the scaffolding for a field organization of fifteen hundred people.
It worked. It was not elegant. And it taught me something I did not expect: finding the right insight was rarely the problem. The harder job was enabling the organization to act on it. Getting fifteen hundred people aligned, informed, and moving in the same direction, at the same time, based on the same picture of reality.
That is the system I am now encoding as software. This post covers the architecture: what it is, why it is structured this way, and what I am building first.
The next layer
The previous essay mapped what exists and where the gaps are. The observation and recommendation layer is real and valuable. Gong, Clari, Monaco, Actively AI — these tools surface what is happening in a deal and suggest what to do next. That is a meaningful layer. It is also where most of the market is today.
The platform I am building adds the layer above that. Not to replace what already works, but to close the loop those tools leave open. The gap is not seeing the signal or making a recommendation. The gap is taking action, learning from the outcome, and updating what everyone does because of it.
Three things a VP of Sales genuinely needs, and does not have today in one system:
A clear picture of the business across the full portfolio. Which accounts are financially healthy and which are quietly slipping. Where the team is on quota. How customers are responding, not how reps are reporting. Which deals are actually progressing and which just look that way on a dashboard. The current tools give slices of this. None give the whole picture in one place, connected.
A system that acts, not just advises. A risk signal should trigger a next action. An escalation should happen. A rep should receive a specific recommendation, not a dashboard alert. The intelligence needs to connect to execution, not sit beside it.
A learning loop that compounds. Every deal that closes or stalls contains information about what worked. That information currently dies in a transcript or a closed opportunity. Nothing reads it systematically, nothing updates the playbook because of it. The system that closes that loop, automatically, changes the economics of running a sales organization.
The platform architecture
Three layers, each with a distinct job. The diagram below shows how they connect and where data moves between them.
The platform sits beneath the existing stack, not beside it. It reads from Salesforce, Gong, Clay, and others through decoupled ingestion and derives signal across all of them that no individual tool can see on its own. A deal's risk does not live in Gong or Salesforce alone. It lives in the pattern across both, over time.
The context graph
The intelligence spine is a temporal context graph of the customer relationship. Not a CRM table. Not a snapshot. A structure that accumulates context across every interaction, deal, and outcome.
The key distinction is trajectory versus state. "Champion is engaged" is a data point. "Champion engagement has been declining for three weeks and response time is trending up" is a signal. One tells you where you are. The other tells you where you are going.
At the core of the graph is an action-outcome event log. Every action taken on every deal, and its downstream outcome, gets recorded from day one. Not because everything reads it yet. Because that log is the training data the learning loop will eventually need. Building it in from the start is what separates a product from a platform.
The five apps
Five apps come out of the GTM Motion Diagnostic. Each maps to a diagnostic section, passes the go/no-go filter, and has a data gate that must hold before the app produces reliable output. The sequence is not arbitrary. Each app builds the foundation the next one needs.
| App | Goal | Data Gate |
|---|---|---|
| Account Priority Scorer Next | Score accounts continuously from CRM, intent signals, and firmographic data. Surface who to target and why. | ICP definition must be settled first. Garbage in, garbage out. |
| Deal Risk Monitor Building now | Detect stall signals before a deal dies. Champion going dark, dropped activity, too long in stage. | Fails if CRM hygiene is poor. Manageable starting point. |
| Next Best Action After App 1 | Triggered by a risk signal. Tells the rep the specific move, not a category. | Requires Deal Risk Monitor running first. One system, two outputs. |
| Customer Expansion Intelligence Later | Detect expansion signals, surface comparable accounts, generate Art of Possible blueprints. | Most data-intensive. Product telemetry must be connected. |
| Discount Governance Later | Flag discount depth in real time, enforce thresholds, surface pricing patterns across the team. | Process first. Pricing authority must be defined before the app is useful. |
What I'm building first
The Deal Risk Monitor. Not because it is the most ambitious app in the set, but because it passes all four gates in the go/no-go filter cleanly. The data gate is manageable. The output is specific enough to act on. It proves the system-of-work pattern. And it creates the foundation everything else needs.
Input: a deal, the active flag signals on that deal, and how long it has been in the current pipeline stage. Output: a risk score, which flags are active, and a recommended action. Not a category. A specific move the rep or manager can take today.
The app detects seven flag types: too long in the current stage, no stakeholder response, champion going dark, competition emerging, commercial pressure, technical incompatibility, and weak POV or discovery. Each maps to a recommended action: escalation, executive sponsorship, program intervention, or adjusting the deal's probability and size.
The thin graph slice for this first build covers four of the seven node types: Deal, Person and Champion, Flag, and Action. Enough to prove the pattern. Narrow enough to ship fast.
The event log runs from day one. Nothing reads it yet. That is the point.
How this works in the real world
Any system like this has to navigate a set of real-world conditions before it reaches production. These are not edge cases. They are the standard environment for enterprise AI deployment, and the architecture is designed with them in mind.
Process-level learning needs volume before patterns are statistically meaningful. The starting point is encoded practitioner expertise as the prior. The system learns from live outcomes from day one and improves as data accumulates. The learning loop is a later capability. The architecture supports it from the start.
Enterprise platforms increasingly restrict direct API access. The architecture uses decoupled ingestion, CDC event streaming or data lake staging, rather than live API calls. This is also the safer pattern: it insulates the system of record from agent-driven traffic and keeps sensitive data behind the organization's existing security boundary.
Real-world CRM data is messy. Duplicate contacts, inconsistent naming, incomplete records. The system is designed to surface data quality issues as flags, not to hide them. A bad POV or insufficient discovery is itself a signal the app detects. The goal is to make data quality a visible, actionable problem rather than a silent one.
The hardest part of deploying any intelligence system inside a sales org is not the technology. It is getting the field to trust it. Reps act on recommendations they understand. Managers update playbooks they helped build. The product is designed for this: every recommendation includes an explanation, confidence scores make uncertainty visible, and manager approval gates sit between intelligence and playbook updates. Trust is built through transparency, not authority.
The next post will be the app itself. The Deal Risk Monitor, running on real data, doing the job described here.
The architecture in this post is the frame it is built inside. Not the full platform on day one. A thin slice that proves the pattern and starts accumulating the data the rest of the system will need.