GTM engineering: what it is, the stack people use, and how to run the loop with AI agents

Nearly every article on the first results page for "GTM engineering" is written by a company that sells to GTM engineers, and nearly every one of them ends on "how to hire one". This page is written by one too, and says so: Tulina is an agentic RevOps workflow builder, and its own section is below, clearly marked. What the other pages leave out is the part a GTM engineer actually spends the week on: building one loop, end to end, on real tools with real limits. That is the middle of this page. The definitions come first, because the question people type is still "what is it".

Every vendor fact below was read on the vendor's own page on 26 October 2026, and the two measurements in the agent section were run that day.

What is GTM engineering?

GTM engineering is the practice of building automated revenue systems: the pipelines that find companies showing a buying signal, enrich them, score them against a profile, write the outreach and log the result in the CRM, without a person doing each step by hand. Clay, which says it coined the term in 2023, defines it as "the practice of building automated revenue systems using AI, data enrichment, and workflow automation". ZoomInfo's guide puts it as "the discipline of building, automating, and scaling the systems that turn buying signals into revenue motion". Both definitions are on their authors' pages: Clay's and ZoomInfo's.

The clearest description is not a vendor's. The top answer on r/gtmengineering lists what a rep used to do to reach 500 prospects: search LinkedIn or a database with filters, export to a spreadsheet, enrich the rows with another tool, write personalised outreach, load it into a sequencer and send. A GTM engineer, in that answer, "builds systems that connect all of those steps together so they run automatically (or close to it)", stitching Clay, Apollo, Make or n8n and a model together. The thread is here.

The vendors agree on the shape underneath. Clay describes three rungs: a data foundation (clean, deduplicated CRM records), data modeling (scores and profiles that predict who will buy) and data activation (the workflows that act on them). ZoomInfo describes the same three as layers of the stack: data, orchestration, execution. The useful reading is that the role exists because the middle layer became cheap. Research that took an analyst a week can be done by a model in minutes, and the person who wires that into the sales motion is the GTM engineer.

What does GTM stand for in engineering?

GTM stands for go-to-market: the plan for how a company reaches and sells to its customers. In "GTM engineering" it has nothing to do with Google Tag Manager, which shares the initials and confuses the search results. A GTM engineer builds revenue systems, not tag containers.

What does a GTM engineer do?

A GTM engineer builds and maintains one loop, in several variants: find the companies that showed a signal, enrich them, decide whether they fit, find the right people, write to them, and record what happened. ZoomInfo's guide breaks the job into five responsibilities, and they are the loop read in order: build the enrichment workflows, operationalize buying signals, wire AI tools into the stack, design and run revenue plays, and keep the data clean.

The role sits next to RevOps and is not the same job. ZoomInfo's framing, which Norwest's and Clay's pages echo, is that RevOps improves the output and GTM engineers build the machine: if the deliverable is a process or a report, that is RevOps; if it is a working system, that is GTM engineering. Most people in the role did not start in it. ZoomInfo's guide, quoting Norwest, calls RevOps a proving ground for it, and the common entry is an SDR or ops person who automated their own work and kept going.

The demand is visible in the postings. On 26 October 2026 we asked TheirStack for US job postings with "GTM Engineer" in the title opened in the previous seven days: 45 postings, at 36 companies. Clay's page says about 100 GTME listings go live every month, without saying where it counts; the two counts use different filters, so they do not add up to one figure, but both say the role is being hired for weekly.

What tools does a GTM engineer use?

A GTM engineer uses a signal source, an enrichment database, a place to orchestrate the steps, a model to judge and write, a sequencer, and the CRM. The names change by company and the layers do not. Clay's own FAQ names Clay, a CRM, an email platform and signal providers; ZoomInfo's stack section names Apollo, Clay and Cognism for data, n8n, Zapier, Make, Workato and Clay for orchestration, and HubSpot, Outreach, Salesloft and the CRM for execution. For the tools in each layer with their prices read on the vendors' own pages, see GTM tools, layer by layer.

The orchestration row is where the money and the arguments are. Clay bills in two currencies, read on its pricing page on 26 October 2026: actions, which cover running a table, calling a model or sending data out, and data credits, which buy records from its marketplace. The price card lists Launch at $167 a month for 15,000 actions and Growth at $446 for 40,000; the FAQ on the same page says Launch starts at $185 and Growth at $495, so read the card and the FAQ as two offers and ask which one you are on. Data credits start at $0.05, actions start under $0.01, top-ups cost a 30% premium, and actions do not roll over. Scheduled enrichment runs start on Launch; webhooks, CRM sync and HTTP API calls start on Growth. None of that is a complaint. It is the thing to know before a table becomes the system of record for a play.

n8n and Zapier sit in the same row for a different reason: they hold logic as nodes rather than columns, and an n8n instance keeps an execution log with the result of each node, where a table shows you the filled cells. What neither holds is judgement. A branch in a flow is a rule someone wrote; a branch on "does this company fit" is a model call, which is why Clay sells Claygent, its research agent, inside the table, and why the Reddit answer lists OpenAI next to Make.

Where Clay tables and n8n flows run out

A table is the right tool while the loop is being discovered. It is the wrong tool the day the loop has to run every morning, read the CRM before spending, and explain why a company was skipped. Three things stop it, and the same three stop a flow of nodes.

The first is cost visibility. In a table, every row is an action and some rows are credits, and what a play cost is a number on a usage dashboard, not something next to the play. The second is judgement. "Is this company a buyer, yes or no, and how sure" is a question a model answers with a probability, and a flow treats that answer as text to parse. The third is memory. A table does not know that another rep claimed this account on Tuesday, and a flow only knows it if someone added the lookup. ZoomInfo's own list of common GTM engineering mistakes ends on the same point: "Assuming no-code tools have no ceiling", with multi-object CRM updates and agent orchestration with conditional branching as the examples of what needs code.

How do you build a GTM engineering loop yourself, with AI agents?

You can build the loop today with Claude Code, MCP connectors to your tools, and a scheduled task, without buying a GTM platform. It is real work, it has limits that matter, and the limits are listed after the steps. Everything here about Claude Code was read on its scheduled tasks documentation on 26 October 2026, which was last modified two days earlier. For the whole motion run from a Claude chat rather than one loop, see how to run GTM from Claude.

1. Write the loop as a procedure, in plain text, before any tool. Which signals count (a posting for which roles, which tools adopted), what the rubric asks (closed questions: is this a buyer, which segment, how well does it fit on a scale), which CRM checks stop a company (customer, open deal, claimed by another rep, person already in a sequence), how many people per company, and what the opener may say. ZoomInfo's guide gives the same advice in its own words: validate the signal by hand for a week first, and "if you can't make it work as a Google Sheet and a daily 15-minute review, automation won't save it". The text is the system of record; every later step reads it.
2. Connect the tools through MCP. Claude Code adds a remote MCP server with claude mcp add, and connectors added on claude.ai are available in Claude Code automatically. One server per tool means one credential each: the signal source, Apollo, the CRM, the sequencer, Slack. Keep the credentials in the connector, never on the workstation, because the scheduled run has no workstation.
3. Run it by hand once, in a session. Paste the procedure, ask for yesterday's signals only, and read every tool call. This is where you find that a company name is case-sensitive in one API, that a reveal comes back minutes later through a separate call, or that a campaign created through an API can be born running. Fix the text, not the run.
4. Turn it into a scheduled task. /schedule in Claude Code, or claude.ai/code/routines, creates a task from a prompt, optional repositories and connectors, running in Anthropic's cloud on a schedule, on an API call to the task's own endpoint, or on a GitHub event. Make the prompt a pointer: "load the procedure, run it for yesterday, report what you could not do", not a copy of the procedure. The task's documentation says all your connected connectors are included by default, so remove the ones this loop does not need: during a run the agent can call any tool they expose.
5. Give the run somewhere to write. A table with one row per company per morning: the signal and its quote, the score and its probability, which check stopped it, who was added to the campaign. The task's run status says whether the session ended cleanly, and the documentation is explicit that this is not the same as whether the work got done: blocked requests and missing tools show up in the transcript, not in the status. The table is how you read a month of runs without opening a transcript each time.
6. Keep the send out of the loop. Add people to a paused campaign and let a person launch it. The run proves nothing left by reading the campaign's own report after it adds people.

Here is what that build cannot do, as of the pages read for this article:

• It cannot run more often than hourly on a schedule. Cron expressions that fire more than once an hour are rejected, and a run set for the hour can start several minutes late. A signal that needs a reaction in minutes goes through the API trigger instead, and the text you post with it arrives labelled as untrusted data that the prompt must opt in to reading.
• It belongs to one person. A scheduled task runs under one claude.ai account, acts as that person in every connector, and counts against that account's usage. There is no service account, so the loop leaves with the person who built it unless someone rebuilds it.
• It keeps no idempotency. Each trigger starts a new session; a retried webhook is a second run. Deduplication is the procedure's job: check the table and the campaign before writing.
• It shows usage, not cost per step. Runs draw down subscription usage like any session. What one company cost to source, judge and enrich is something your table has to compute from the connectors' own counters, and some providers do not return one.
• The tools' own limits stay. Enrichment coverage is partial on small companies, a phone reveal is asynchronous, a bulk match saves calls but not credits, and a model asked "does this fit" in prose gives you prose to parse. Those are listed under the limits section below, because they apply to the Tulina path too.

How do you run the loop as a scheduled agent, with Tulina?

With Tulina, the loop above runs as a hosted agent on a schedule or a webhook, through connectors to TheirStack, Apollo, Jev, HubSpot, Lemlist, FullEnrich, Serper and Slack, with every step, every tool call and its cost in the run's trace. The procedure is text your team edits; the agent reads it on every run. A person still decides the rubric, the playbook, and when the campaign launches: the run adds people to a paused campaign and never sends.

Once TheirStack, Apollo, Jev, HubSpot and Lemlist are connected, paste this into Claude or ChatGPT:

Run signal-based outbound for yesterday. Never send anything: add
people to our paused Lemlist campaign only.

1. Build the universe. In TheirStack, search job postings opened
   yesterday in [our countries] for [the roles that mean a company
   needs what we sell], and companies that started running [the tools
   we plug into]. Keep a stack detection only when more than one
   posting backs it. Merge both lists on the company domain.
2. Score every company with Jev on one rubric, in batches, sending
   only name, industry, headcount and the signal: is this a buyer
   (yes/no), which of [our segments], fit on a 0 to 4 scale. Keep fit
   probability above 0.8, park below 0.4, and list the band between
   for me with the reasons. Store the score, the probability and the
   model name on each company.
3. Before anything is bought, check HubSpot by domain: a customer by
   lifecycle stage leaves; a company with an open deal leaves and its
   owner gets one line in Slack. Then check our claims table: claimed
   by another rep inside [the claim window] leaves.
4. For each company left, read its postings in full and search the
   last month's news with Serper. Keep each signal with the exact
   sentence it rests on and its date. Name which of [our buyer roles]
   the signal points at.
5. Search Apollo people one domain at a time with those roles, keep
   two people per company, and match them by identifier. Send the
   misses to FullEnrich as one job, work emails only. Drop anyone
   already in any Lemlist campaign in our workspace.
6. Write one opener per person: two sentences at most, the signal
   first, one question, in their language, nothing the sources did
   not say.
7. Add each person to campaign [id], which stays paused, with the
   opener as the first-step variable. Read the campaign's report to
   prove nothing was sent. Add one note per company in HubSpot with
   the signal, score and play. Post one recap in Slack: what each
   source returned, what passed, who was added, and every company
   that stopped with its reason.

The process behind that prompt, with every step and the tools it uses:

Le processus dans Tulina

Outbound à partir de signaux d'achat

Déclencheur · Planifié

Planification quotidienne

Chaque matin l'exécution démarre sur les signaux de la veille, pour qu'une entreprise qui a adopté mardi l'outil auquel vous vous branchez soit en séquence mercredi.

Claude exécute la suite en autonomie

1. 1

   Construire l'univers sur la stack et le recrutement

   TheirStack

   TheirStack

   Les entreprises qui ont commencé à utiliser les outils auxquels vous vous branchez, étayées par plus d'une offre, et celles qui recrutent pour le problème que vous résolvez reviennent en une liste avec les détections derrière.

   Apollo.io

   Apollo.io

2. 2

   Noter sur votre grille

   Jev

   Jev

   Chaque entreprise est notée sur votre profil écrit en questions fermées, avec une probabilité à côté de chaque réponse, et la bande du milieu va à une personne plutôt qu'à une étiquette.

3. 3

   Écarter ce que le CRM ou une séquence détient

   HubSpot

   HubSpot

   Un client, un deal ouvert, une réservation d'un autre commercial, une entreprise en délai de repos ou une personne déjà dans une séquence quitte la liste avec sa raison, avant tout achat.

   Lemlist

   Lemlist

4. 4

   Lire pourquoi maintenant, désigner l'acheteur

   TheirStack

   TheirStack

   Les offres et l'actualité de chaque entreprise reviennent en signaux avec la phrase exacte derrière, et le signal désigne auquel de vos rôles acheteurs écrire.

   Serper

   Serper

5. 5

   Trouver les acheteurs, enrichir leurs emails

   Apollo.io

   Apollo.io

   Deux personnes par entreprise reviennent avec un email professionnel vérifié, les fausses affiliations purgées, et quiconque est déjà en séquence arrêté.

   FullEnrich

   FullEnrich

6. 6

   Choisir la tactique, écrire chaque accroche

   Votre playbook outbound décide à combien de personnes écrire et dans quel ordre, et une accroche par personne est écrite à partir du signal, avec seulement des chiffres citables.

7. 7

   Remplir la campagne, mettre le CRM à jour

   Lemlist

   Lemlist

   Chacun qui a un email rejoint la campagne en pause avec son accroche, chaque entreprise reçoit une note avec son signal et sa note, et l'équipe reçoit le récap avec chaque entreprise écartée et pourquoi.

   HubSpot

   HubSpot

   Slack

   Slack

Voir le processus complet

Two measurements from building this, so the cost claim has a denominator. On 26 October 2026, one company (a synthetic record of a 24-person marketing agency with a fresh "GTM Engineer" posting) was sent to Jev with two questions, buyer yes or no and fit on a 0 to 4 scale. The answer came back as a buyer probability of 0.74 and a fit of 3.66 at confidence 0.72, from model typesafe/jev-1.13-20260917, for 488 input tokens and $0.000020. The same day, a TheirStack search for US postings with "GTM Engineer" in the title, opened in the previous seven days, returned 45 postings at 36 companies; the three rows we fetched were estimated at three credits, because TheirStack returns no credit counter and the estimate follows its published rate card. That is what "every step and its cost visible" means in practice: a number next to the step, with the tool version and the date, not a dashboard total.

A few of the process's choices come straight from running its tools. The CRM is read four times before anything is bought, because two reps paying for the same company is the failure a shared loop exists to prevent. Companies are matched on the domain property and never the display name. The campaign is kept paused and its own report is read after the run adds people, because a Lemlist campaign created through the API is born in the running state whatever its status label says, which was verified live on 31 August 2026. And the rubric's middle band goes to a person with the reasons rather than being forced to a label, because a probability near 0.5 means "as likely as not", not "medium".

What GTM engineering with agents can't do, and what gets you in trouble

• Make a bad signal good. A posting is a dated, public statement of intent, and a single posting that mentions a tool is one job ad, not a stack. The loop keeps a detection only when more than one posting backs it, and it still finds companies whose signal means nothing for you. Validate the signal by hand first; ZoomInfo's advice and ours agree on that.
• Cover every company. TheirStack's coverage is partial on small companies, and an empty answer is a normal result, not an error. Apollo's free platform quota is daily and small; reveals of phones and personal emails need your own key, cost extra credits, and a phone number arrives minutes later through a separate call. Apollo withholds personal emails for people in GDPR regions, and so should you.
• Send for you safely. Nothing in this page sends. The run adds people to a paused campaign, and a person launches it. Deliverability, consent and the rules of the countries you write to are yours, and an agent that sends on its own initiative is a liability, not a feature.
• Replace the rubric. A model answers the question it is asked. "Is this a buyer" written as a closed question with both answers described gives a probability you can threshold; "is this a good lead" gives a paragraph. The rubric is the GTM engineer's work, and it is the part no tool does.
• Hide its cost. Each step has a price: a company record on TheirStack, a match on Apollo, a judgement on Jev, a verified email on FullEnrich. The loop is designed so that nothing expensive is bought for a company that already failed a cheap test, and the recap names every company that stopped and why. If a run cannot tell you what it spent, that is the first thing to fix.

Is GTM engineer a good job?

It is a well-paid job with more postings each month, and it suits people who like building systems at least as much as selling. The pay figures on the first page of results come from two sources. ZoomInfo's guide, updated 6 October 2026, cites Bloomberry's analysis of GTM engineer postings: a median advertised salary of $127,500, SQL and Python each in 38% of the 1,000 postings analysed, and 205% more GTM engineering and RevOps postings from January to September 2025 than in the same months of 2024. Apollo's career guide gives a range of $132,000 to $241,000 depending on experience. Both are their authors' estimates from job postings, not surveys of people in the role.

How to become a GTM engineer?

Build one loop and show it. Clay's hiring section looks for technical fluency, commercial bias, curiosity and an experimental mindset, and assesses candidates with a business problem, a systems sketch and a mini build challenge. ZoomInfo's guide says a working enrichment workflow or a signal-triggered play with measurable outcomes "makes the case better than a certification". The steps in the do-it-yourself section above are that portfolio piece: one signal, one rubric, one paused campaign, and a table that shows what each morning cost.

GTM engineer vs RevOps: which one does a small team need first?

A team under about fifty people usually needs the loop more than the title. Clay's page says most companies embed the role inside RevOps first and federate it outward later; ZoomInfo's says to hire the engineer when engineering capacity is the bottleneck, not before. For an agency or a startup running its own outbound, the honest order is: write the procedure, run it by hand for a week, schedule it, and hire when the number of loops outgrows the person maintaining them.

For the process this page embeds, with every step and connector, see outbound from buying signals. The prospecting half of that loop, step by step and measured on one segment, is in the AI prospecting guide. For what each connector can read and do, see TheirStack, Apollo, Jev and Lemlist for Claude and ChatGPT. For the same agents beyond outbound, across support, finance and product, with the controls that keep them safe, see AI agents for business.