The GTM Engine · Owlbound

↻The GTM engine

A loop, not a funnel.

A GTM engine is the repeatable machine that produces revenue by turning signals into action. It is the operational layer beneath the strategy: routing rules, enrichment logic, stage definitions, handoffs, cadences. Its five parts run as a loop across the whole arc, not a funnel that stops at closed-won. If you cannot map all five, you have activities that happen to coexist. We run all five, and the GTM Brain they read from, in one GitHub repository.

The full arcunknowndiscoveredevaluatedpurchasedadoptedrenewed & expanded

Illustration. The loop runs on its own, and every change it learns is a commit you can read, review and keep.

01System of Context & Record

GTM Brain

GTM BrainRecord · Truth, proof, positioningFoundation · Three-layer ICPFoundation · Skills repository
company truth proof positioning messaging personas ICP definition skills repository the brain outcomes write back
Illustration. One linked brain: company truth, proof, the ICP and the skills are written once, every agent reads from them, and outcomes write back.

Every agent you deploy starts with the same problem: it knows nothing about you. It can write, but it does not know who you sell to, what you have already proven, or which plays you retired last quarter. So it guesses, and the guesses read well. The engine as a whole has the same problem. Inputs, decisions, actions, outcomes and feedback loops all need one record to read from and write back to, or each part guesses on its own.

The GTM Brain is that record, kept as plain linked notes rather than a prompt. Company truth, proof and positioning are written once, properly. The ICP sits beside them as the first foundation: the smallest, most specific set of customers for whom your current engine can produce repeatable wins at acceptable cost, speed and retention. Smallest, because it is a constraint, not an aspiration. Repeatable, because it rests on a pattern, not the one deal where the stars aligned. Current, because it fits the engine you run today and moves when the engine moves.

A loose ICP breaks the moment a system is built on it, so the brain holds it in three layers, and each one narrows the target. Firmographics say who they are: industry, size, geography, funding stage. Structural indicators say how they operate: centralised or distributed buying, sales-led or product-led, one stack or tool sprawl. Timing & triggers say why now: hiring, a funding round, a platform migration. Scored on fit and timing, the layers turn where you actually win into tiers, pain clusters and a 100-point score.

The second foundation is the skills repository: every play in this library, versioned, as instructions an agent can run. The notes are linked, so a change to the ICP updates the messaging that depends on it, and what worked writes back in. It is the record the rest of the system stands on, committed to GitHub, where every change can be read and reverted.

02System of Intelligence

Intent Signals Model

Intent Signals ModelInputs · Timing & triggers82 providers · 1,217 endpoints
blog visit hiring new VP intents stack routed, draft attached threshold day 1 week 1 week 2 week 3 day 30
Illustration. A blog visit, then hiring, then a new VP: each alone is noise, and the account is routed only when its intents stack past the threshold.

Demand enters the engine as inputs: leads, target accounts, website traffic, referrals, product signups, partner introductions and intent signals. They are raw material, not readiness. The brain already knows who fits. The intent signals model answers the harder question, why now, for every target account, without stopping. It is the timing & triggers layer of the ICP, run as a system instead of a hunch.

One signal is noise. A funding round alone, a new VP alone, a single blog visit alone: none of them is a reason to write. So the model listens across job postings, leadership changes, funding rounds, tech-stack changes, product launches, AI transformation moves, website visits and engagement with your content and your competitors', and it waits for the signals to stack.

Eighty-two providers and 1,217 endpoints feed it, already plugged in, with no keys to gather. Each signal is weighted. When enough of them land on one account, the account crosses the threshold and arrives ready to act on: the right personas inside it pulled, the owner for that industry attached, and the reason for the timing already written. The alert reaches Slack enriched, with a draft attached.

The best outbound teams are not better at writing emails. They are better at identifying triggers, and at reaching the right company while something is already happening inside it. That is not a knack. It is a system: fit from the brain, timing from the signals, and enough speed to still be relevant. The test is simple: accounts firing three or more intents should convert far above the rest. If they don't, the weighting is wrong, and we change it.

03System of Decision

Decision Layer

Decisions · Rules in plain EnglishRouting & prioritisationOwnership & escalation
leads accounts traffic signups decisions/ · versioned in the repo ICP tier 1? 3+ intents? owner named? no no no escalate route to owner nurture inputs who matters most why now who owns it next step
Illustration. Every account meets the same written rules in the same order, and every branch ends in an action: route it to its owner, send it to nurture, or escalate it.

Signals say an account may be ready. They do not say what to do about it. Who matters most, which action to take, who owns it, when to escalate: that is the logic layer, and it is where most GTM engines quietly fail. Nothing looks broken. Sequences still send and dashboards still fill. But actions without good decisions upstream are organised noise.

So routing and prioritisation are written down as rules in plain English, each with a condition and an action. If an account is tier 1 and fires three or more intents, route it to whoever owns that industry, draft attached. If it fits but nothing is firing yet, send it to nurture. If nobody owns that industry, escalate it instead of letting it sit. The rules live in GitHub, in the same brain every agent reads.

Before a rule fires, the account is scored against the three layers of the ICP: who it is, how it operates and why it would buy now. What reaches a rep has passed all three, so the list is short and specific. The rules also run only on data the system can actually get. A field that cannot be captured automatically or enriched reliably never becomes a core dependency for routing or scoring.

The rules change as the system learns, and every change is visible. It lands in the repository as a commit, such as “hiring + funding on one account now routes to its AE owner”, and you can roll it back. Routing logic that used to be a setting buried in a tool, or a habit in one rep's head, becomes something your whole team can read. It is yours, in writing.

04System of Action

Action Engine

Actions · Allbound EngineDemand engineInbound engineOutbound engine
demand engine · content, events, webinars inbound engine · visitors, signups, forms outbound engine · seats, sequences routed toan owner one pipeline build the audience catch the hand-raisers meetings
Illustration. Demand, inbound and outbound run as three engines and converge on one pipeline, where whatever arrives is routed to an owner.

A decision is worth nothing until something moves. Routing a lead, enrolling a contact in a sequence, booking a meeting, sending a proposal, starting an onboarding workflow: actions are the part most teams obsess over, because they are visible and they feel productive. They are also where the tools live. The CRM, the sequencer and the automation platform are action infrastructure. They matter, but they are not the system. They carry out whatever was decided upstream.

That is why swapping tools rarely fixes a broken motion: you replace a part while the design stays flawed. So we design the motion first and fit the tools to it. The Allbound Engine runs that motion as three engines, each with its own scoreboard, all firing from the same brain and the same rules, so the message an account hears is consistent wherever it hears it.

The demand engine builds the audience before anyone is sold to: SEO and GEO content written to rank and to be cited by answer engines, thought leadership by vertical, webinars and events. The inbound engine catches what that demand produces. The companies behind your web traffic, product signups and profile visitors are filtered for ICP and routed to an owner with an SLA, while the moment is still warm.

The outbound engine goes after the accounts that never raise their hand: private sending infrastructure, one campaign per seat, hundreds of narrow campaigns launched from the command line, and every reply read by a human. Across nine live campaigns it reported a 6.3% reply rate on 7,123 contacts, and nobody called a tag a meeting.

05System of Learning

Every output improves the next

OutcomesFeedback loops
the system that learns outcomes write back a stack that forgets week 1 month 2 month 3 month 5 month 6
Illustration. Outcomes write back into the brain, so the system keeps climbing, while a stack that forgets stays flat.

Outcomes are what the business actually counts: meetings booked, pipeline created, deals won, customers retained, expansions closed. They are also lagging. By the time a number lands, the conditions behind it were set weeks or months earlier, in a list, a score or a routing rule. Most GTM stacks read the number and forget the rest. A campaign ends, the spreadsheet is archived, and next quarter starts from the same assumptions as the last. The system of learning is the part that remembers.

Feedback loops are how the system learns. They are the part most teams skip, and they decide, more than anything else, whether an engine gets better over time or just gets older. Ours start with the reply. Every reply is read by a human and coded into one of four buckets: real positive, relevant but not a yes, hard no, do not contact. Wrong-person replies become introductions. Do-not-contact replies are fed back, so a bad list is never bought twice.

Closed-won is not where the learning stops. The loop follows each account through adoption, renewal and expansion, because a customer who signs and then leaves teaches something a reply never could. Conversion rates, velocity, loss reasons and cohort retention all feed it. Source truth is fixed at creation, so channels are judged on one opportunity set and leadership plans without a shadow spreadsheet. An ideal customer is one you can win repeatably and keep, so a segment that signs but does not stay stops being called ideal.

Then outcomes write back into every part of the system. The ICP in the brain tightens, signal weights move, routing rules are rewritten, weak angles are retired and winning plays become the default. Wins and losses drive those changes, and so do renewals and expansions. Each one is a commit in your repository. That is what closes the loop, and why the system is worth more in month six than in week one. All of it stays in the repository, readable by anyone who works on it.