Most GTM stacks aren't stacks. They're collections.
A CRM here. An intent platform there. An email sequencer, a call intelligence tool, an enrichment provider, a lead scoring model that someone built eighteen months ago and nobody's touched since. Each tool was purchased to solve a specific problem. Each one does solve that problem, more or less. And yet the system as a whole doesn't behave like a system, it behaves like a pile of tools that happen to be in the same category.
When I try to diagnose why a revenue team's tooling isn't working, the answer is almost never "they have the wrong tools." It's almost always "they have the right capabilities with no defined interface between them." They have skills with no orchestration. They have context with no way to feed it into execution. They have signals flooding in from every direction with no shared state to evaluate them against.
This post is an attempt to describe a GTM stack the way you'd describe a software system, in terms of layers, interfaces, and state management. If you build software and you're thinking about GTM architecture for the first time, or you're a GTM engineer trying to explain to a backend team why this is actually their problem too, this is the mental model I keep coming back to.
The Four Layers
The four-layer GTM stack maps cleanly onto a pattern you'd recognise from most well-designed software systems: a data/state layer, a logic layer, a coordination layer, and an execution layer. The naming conventions differ in GTM, but the architecture is the same.
Layer 1: Context
This is the data layer. Everything the system needs to know before it can make a decision about anything: your ICP, your buyer personas, your messaging, your positioning, your playbooks, your product use cases, your historical win/loss data, your proof points mapped to segment and objection type.
In software terms, this is your application state, the persistent store everything else reads from before acting. In most GTM stacks, this layer doesn't formally exist. The context lives in a Notion doc, or a slide deck, or the founder's head, or scattered across seventeen different tools in fragmented form.
The consequence is that every tool in your stack is essentially stateless with respect to company knowledge. The outreach tool doesn't know your positioning. The scoring model doesn't know why you lost the last three deals to a specific competitor. The qualification layer doesn't know your ICP has evolved since the sheet it was originally trained on.
Context without a home means every tool in your stack is guessing, quickly, confidently, and often wrong.
Layer 2: Skills
Skills are discrete, reusable units of sales logic. A skill takes inputs (account data, signals, context) and produces a typed output: qualify or disqualify, prioritise or skip, recommend outreach angle, flag deal risk.
In software terms, skills are pure functions. Given the same inputs and the same context, they should produce the same output. They're individually testable, individually improvable, and composable.
Some examples of what a skill looks like when it's actually encoded properly:
Qualification skill: Takes account data + ICP rules as input, returns a scored qualification result with the conditions that passed and failed and a confidence level
Prioritisation skill: Takes a set of qualified accounts + live signals + capacity constraints, returns a ranked list with reasoning attached to each ranking decision
Persona routing skill: Takes a qualified account + available contacts, returns the recommended first point of contact with a suggested outreach angle grounded in context
Deal risk skill: Takes a deal record + recent activity signals, returns a risk score with the specific factors driving it
The reason skills matter as a named concept is that it forces you to be specific about what judgment you're encoding and what it depends on. "Score accounts" is not a skill. "Evaluate whether a company meets qualifier conditions A, B, and C while checking for disqualifier D, then weight the result against recency of signals E and F", that's a skill.
Layer 3: Orchestration
Here's where most implementations quietly fall apart.
Orchestration is the layer that decides which skill runs, when it runs, on which input, and what happens with the output. It's the coordination layer that turns a shelf of functions into a working system.
Without orchestration, skills are capabilities gathering dust. You've written a qualification function that works perfectly. It runs when someone remembers to call it. That's not a system, that's a manual process with a helper function attached.
Orchestration handles:
- Trigger routing: When a signal fires, which skills are relevant? A funding event routes differently from a champion job change, which routes differently from a repeat pricing-page visit.
- Dependency resolution: Some skills depend on the output of other skills. Prioritisation depends on qualification. Persona routing depends on prioritisation. The orchestrator manages that dependency graph.
- Conditional branching: What happens when a skill returns a disqualify result? What happens when confidence falls below a threshold? Those decision paths need to be explicit, not left as runtime surprises.
- Output routing: A qualification result needs to go somewhere, into the queue, into the CRM, back to the context layer as new data. The orchestrator manages those handoffs.
Skills without orchestration are capabilities gathering dust. Orchestration without skills has nothing to coordinate. They're genuinely co-dependent, and most teams who skip the orchestration layer end up with the former problem: real logic that only runs when a human remembers to trigger it.
Layer 4: Execution
Execution is the layer that converts decisions into actions in the tools your team actually uses, your CRM, your email platform, your LinkedIn workflows, your calendar system, your enrichment providers.
The key design principle here is that execution should be integration-based, not rip-and-replace. The point isn't to swap out your CRM; it's to give the CRM something better to work with. Execution pushes the orchestrator's outputs into the existing toolchain as structured data those tools can act on, a task created, a sequence enrolled, an account priority updated, a deal risk flag set.
If execution is the only layer you have, if you've built integrations but no orchestration, no encoded skills, and no shared context, you have a very sophisticated set of data pipelines that move the wrong information quickly to the wrong places. Speed without direction is just faster failure.
Signals Are Inputs, Not a Layer
This is the clarification I find myself making most often in architecture conversations: signals are not a layer in the stack. They're event inputs.
A signal, a VP of Sales hire, a pricing page visit, a funding announcement, a shift in email engagement, is the event that triggers the orchestration layer to evaluate. It's the equivalent of an inbound request to your API surface. The signal doesn't do anything by itself; it kicks off a chain of skill evaluation that runs against the context layer and routes output to the execution layer.
The reason this distinction matters: if you treat signals as a layer, you end up building a dashboard. You route signals to a place where humans look at them and decide what to do. That's better than not having the signals, but it's still a human-in-the-loop system at the exact moment where speed matters most. The window between a signal firing and an action being taken is measured in hours, sometimes minutes. A dashboard doesn't close that window.
Signals become valuable when they flow through the full stack, evaluated by skills, coordinated by the orchestrator, grounded against context, and pushed to execution within the response window. Until that flow exists, you have intent data and a place to look at it.
The Revenue Brain as Shared State
The architectural problem that ties all of this together is state management.
In a distributed system, you need a shared state store, a single source of truth that every service reads from before acting and writes to after acting. Without it, services drift. They work from stale or inconsistent data. They can't learn from each other's outputs. The system as a whole becomes less coherent over time rather than more.
GTM stacks have exactly this problem. Your enrichment provider has one version of an account. Your CRM has a different version. Your intent platform has a third. Your outreach tool has whatever it was seeded with at setup. None of them converge, and none of them contain the thing that matters most: your company's accumulated knowledge about how to sell.
The Revenue Brain is what the shared state store looks like in a GTM context. It holds three things simultaneously and keeps them current: the company's context (ICP, messaging, playbooks, history), the encoded sales judgment (the skills that represent how you actually evaluate and act on that context), and the live signal log that shows what's happened recently and when. Crucially, it writes back, every execution result feeds into the store, so the context layer gets more accurate over time rather than staying frozen at the moment someone last updated the Notion doc.
Without this shared state, each layer in your stack operates independently and the system can't compound. With it, every layer has something consistent and current to read from, and every action produces data that makes the next action better.
The Interface Contract Between Layers
If you're building against this model, or evaluating tooling against it, the interface between each layer is where the actual design decisions live. A few worth specifying explicitly:
Context → Skills: Skills should receive context as typed inputs, not as a free-text blob. "Here is the full ICP document" is not a usable interface for a qualification skill. The interface should be specific field names, expected types, confidence scores where applicable, and a timestamp indicating when the context was last validated.
Orchestration → Skills: The orchestrator should pass skills the minimum context they need for the specific decision being made, not everything in the store. Overly broad context injection creates ambiguity. Treat skills like microservices: narrow inputs, typed outputs, no side effects.
Skills → Execution: The output of any skill chain should be a structured action specification, not a recommendation for a human to interpret. "This account qualifies and should receive outreach using persona routing result X with messaging angle Y" should be a typed object the execution layer can consume directly, not prose for a rep to read and decide whether to act on.
Execution → Revenue Brain write-back: Every execution event should write back a structured log entry: what action was taken, on which account, at what time, with which skill outputs as justification. This is the data that makes the context layer more accurate over time.
One thing that surprises people when they start specifying these interfaces: you end up discovering that a lot of what you thought was a tooling problem is actually an interface problem. The tools often have the right data. The problem is that nothing has defined how that data should flow between them in typed, consistent form.
Where Does Your Stack Keep State?
Here's the question I'd genuinely like to hear answers to in the comments: where does your GTM stack keep state today?
Most teams I've worked with answer this one of three ways: "in the CRM" (which means it's as accurate as the last time a rep updated a field), "in Notion or Confluence" (which means it's static and no tool reads from it automatically), or "in our heads" (which is at least honest).
The shared state problem is the hardest part of this architecture to solve, and also the part that most GTM tooling conversations skip entirely. I'd be curious to know how others are approaching it, whether you've solved it, partially solved it, or decided it's unsolvable and built around it.
If you want to go deeper on what the memory layer actually needs to hold, the Revenue Brain post covers the structure of shared state in GTM in a way this architectural overview can't do in the space available. Worth reading alongside this one if the state management question is the one that's stuck.
Top comments (0)