What is a GTM decision layer?
The decision layer is the part of a go-to-market system that determines what should happen when something changes — which response, by whom, how quickly, and whether a human or a machine should do it. In most companies it does not exist as a designed thing. The defaults of whatever tools were bought become the decision policy by accident, and nobody can state what it is.
The layer that was never designed
Something in every company determines what happens when an account changes. In most, it is not a decision layer. It is the accumulated defaults of whatever tools were bought: a scoring threshold from an implementation four years ago, a routing rule written for a team that no longer exists, an agent's out-of-the-box cadence, and a set of habits.
Nobody chose that policy. Nobody can state it. And when results disappoint, there is nothing to inspect — only a vendor to blame or a rep to coach.
What it decides
A decision layer takes a detected change and produces an instruction. Four questions, all of which have to be answered for the instruction to be usable:
- Whether anything should happen. Most changes warrant nothing. A layer that cannot say no produces noise at the volume of its inputs.
- What should happen. The specific response, not a general instruction to follow up.
- Who does it — a named person or a specified agent, and how quickly.
- Human or machine. A deliberate assignment, made once per decision type rather than improvised per account.
An observation that arrives without those four is not actionable, however accurate it is. That gap is precisely why sales ignores intent data: the signal is fine, and it arrives as a number with no reason, no owner and no next step.
The test of a decision layer is not whether it fires. It is whether someone can state, in a sentence, what the company does when a specific thing changes — and whether the system agrees with them.
Why it has to be explicit
An implicit policy cannot be improved. If nobody can articulate the rule, nobody can identify which part of it was wrong when the outcome disappoints, so iteration attaches to whatever is visible instead — usually the copy, which is almost never the constraint.
An explicit rule is a claim about the market. It can be checked against outcomes, disagreed with by a rep who talks to those accounts daily, and corrected in a way the whole organisation inherits. That is the difference between a system that accumulates knowledge and one that accumulates settings.
Where it sits
Fourth of six. It depends on everything below it and constrains everything above:
- Data and state give it something true to reason about.
- Signal gives it a moment to reason at.
- Action executes whatever it concludes — well or badly, at whatever volume.
- Feedback tells it which of its rules were right.
This is why automating actions before designing this layer is the expensive mistake. The agent does not fail because it is a bad agent. It fails because nothing specified what should happen, so its defaults became the company's outbound policy by accident — the mechanism behind why AI SDRs fail.
Building one
Start narrow. Take the three or four changes that most reliably precede a real conversation, and for each write down what should happen, who does it, how fast, and why. Four sentences. Then check them against what the system currently does, which is usually where the surprise is.
Specifying this layer, including the deliberate assignment of work between humans and machines, is the fourth and fifth layers of the GTM Architecture Audit and a core deliverable of Architect. The wider question of which work belongs to a machine at all is covered here.
Isn’t this just lead routing?
Routing is one output of a decision layer — who receives something. The layer also determines whether anything should happen at all, which response is appropriate, how urgent it is, and whether a human or a machine should execute it. Routing rules that fire on form fills are a small, mostly inbound fragment of that.
Should decision rules be written by hand or learned?
Written first, in nearly every case. A stated rule can be read, argued with and corrected, which matters more than accuracy in the early stages because it is how the organisation converges on what it actually believes. Learned models are worth adding once a feedback layer exists to train them on real outcomes rather than on proxies.
Who should own this layer?
Whoever can be held to the outcomes it produces, which in practice means a revenue leader rather than a systems administrator. The failure mode is treating it as configuration: when the decision policy is owned as a tooling task, it drifts toward whatever the tools make easy rather than what the business decided.
How do we know if ours exists?
Ask three people independently what should happen when a target account hires a relevant executive, and how quickly. If you get three different answers, or the answer is a description of what a tool happens to do, there is no decision layer — there is a set of defaults nobody chose.