GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 4w ago
I’m hiring a Senior GTM Engineer to connect 3 things: pipeline generation plays, AI agents and production systems our sellers can depend on.
This is someone that can get into the weeds AND think strategically about the problem(s).
The work connects AI, data and revenue execution.
Here’s the 5-part scorecard:
𝟏/ 𝐁𝐮𝐢𝐥𝐝 𝐩𝐢𝐩𝐞𝐥𝐢𝐧𝐞 𝐠𝐞𝐧𝐞𝐫𝐚𝐭𝐢𝐨𝐧 𝐩𝐥𝐚𝐲𝐬
Turn prioritized plays into reusable agents, automations and workflows.
People set the plays.
Agents run them.
Humans stay in control.
𝟐/ 𝐒𝐡𝐢𝐩 𝐬𝐲𝐬𝐭𝐞𝐦𝐬, 𝐧𝐨𝐭 𝐝𝐞𝐦𝐨𝐬
Build production-grade systems our teams can depend on every day.
The simple prototype is not the job.
The complicated stuff is.
𝟑/ 𝐎𝐰𝐧 𝐭𝐡𝐞 𝐟𝐮𝐥𝐥 𝐝𝐞𝐥𝐢𝐯𝐞𝐫𝐲 𝐥𝐢𝐟𝐞𝐜𝐲𝐜𝐥𝐞
Design. Prototype. Build. Test. Evaluate. Release. Monitor. Improve.
You own the work from an approved requirement through field deployment.
𝟒/ 𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫 𝐟𝐨𝐫 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧
Evaluations. Human review. Observability. Permissions. Error handling. Rollback paths.
The controls are part of the product.
𝟓/ 𝐏𝐚𝐫𝐭𝐧𝐞𝐫 𝐚𝐜𝐫𝐨𝐬𝐬 𝐭𝐡𝐞 𝐛𝐮𝐬𝐢𝐧𝐞𝐬𝐬
Work closely with Engineering, Data, IT and Security.
Document what you build.
Teach the internal team how to operate it.
Make it maintainable after launch.
I’m looking for someone who can take an ambiguous pipeline problem and turn it into a reliable working system.
If you’re that person (not AI), apply and send me a connection request with your Github repo with projects you've got:
https://lnkd.in/g4Eb9H5H
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 2d ago
I can build a champion-movement signal in Clay. The part that makes me hesitate:
Same name, different person.
A move from three months ago.
Someone marked “champion” because they sat on a call but never used the product.
Those aren’t small data errors. They turn into an awkward first message.
Here are the vendors I’d consider buying from instead of building the signal myself:
𝐁𝐮𝐲
Champify
UserGems 💎
Common Room
Unify
Centralize
The Swarm 🔆
But I’m not sure it’s worth buying a solution for this yet. We have the customer and product data to engineer a signal around our own definition of a champion.
Here’s how:
𝐁𝐮𝐢𝐥𝐝
Use Snowflake to define a champion from customer and product history.
Use Clay to track job changes and check the new company.
Then a GTM engineer owns identity matching, source coverage, stale records and the checks that keep the signal alive.
Champion movement is the #1 signal I want to get right.
Does that make it worth building with internal GTM engineering resources, or is that exactly why I should buy from a company focused on this full-time?
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · today
GTM Engineers can build champion tracking in Clay. The harder question is whether you should. Here’s what Christian Kletzl @ UserGems brought up last week:
His team compared UserGems with Clay on job-change tracking. It’s a vendor-run comparison, but it raises a question worth answering: how much work does your team still own after choosing either option?
The play sounds simple. A champion leaves a top customer and joins a prospect account. But someone has to verify the person, catch the move, update the contact details and find the moves the system missed.
Building gives you control over that process. Buying could take some of that work off your team. Neither removes the need to check the results.
The right answer should come from testing the same champion list against both options. Compare accuracy, missed moves, speed and ongoing maintenance alongside the price.
For the GTM Engineers running this today: what made you build or buy, and would you make the same decision again?
PS: That’s Drew Colligan in the video, my AI digital twin, using an AI-generated version of my voice and likeness.
Christian’s original post: https://lnkd.in/geuxHHQr
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 7d ago
GTM engineers: Sculpt felt like a reunion. I left thinking Clay is becoming the new Salesforce ecosystem for our work.
I ran into people I hadn’t seen in 15 years.
I walked through the vendor area, met new companies, moved outside to the breakouts, then back in for the builder sessions.
Everywhere I looked, people were building around Clay.
The session that stuck with me the most:
Kyle Ketchum at Figma.
His sellers had hundreds of accounts. They could send an email in seconds, but researching one account took about an hour across six tools.
Kyle’s team pulled product data, CRM, enrichment and marketing context into one audience view. The system chose one play per account, notified the rep in Slack, and gave them a message to review. Their edits fed back into an evaluation loop.
The rep saw one useful action. Underneath it was an entire system that could be tested and improved.
𝐓𝐡𝐚𝐭 𝐰𝐚𝐬 𝐦𝐲 𝐛𝐢𝐠𝐠𝐞𝐬𝐭 𝐭𝐚𝐤𝐞𝐚𝐰𝐚𝐲 𝐟𝐫𝐨𝐦 𝐒𝐜𝐮𝐥𝐩𝐭:
The most powerful thing an enterprise can build is infrastructure for agents across Snowflake, Clay, Slack and GitHub.
The context, the play, the rep’s workspace, and a versioned way to improve it.
I came home wanting to build that.
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 5d ago
5 open GTM engineering roles. Wispr Flow, Heidi, Nectar Social, Vocca and Navan are hiring. The last one is on my team 👇
𝐅𝐄𝐀𝐓𝐔𝐑𝐄𝐃 𝐑𝐎𝐋𝐄
GTM Engineer @ Wispr Flow
San Francisco | On-site | $177,000–$213,000 USD salary
Build the account data, inbound routing and outbound workflows sales runs on. Run agents as production software: code in a repo, evals, monitoring, fallbacks and human review.
https://lnkd.in/gEXhZs-e
𝐇𝐄𝐈𝐃𝐈
GTM Engineer
New York | On-site | Employer-estimated base salary: $160,000–$180,000 USD
Own lead generation, HubSpot data models and integrations across Marketing, Sales and Customer Success.
https://lnkd.in/gzRcGaVm
𝐍𝐄𝐂𝐓𝐀𝐑 𝐒𝐎𝐂𝐈𝐀𝐋
Founding GTM Engineer
Pakistan | Remote
Build internal tools and outbound experiments using the company’s social data. Own adoption and reliability.
https://lnkd.in/gsGjquDR
𝐕𝐎𝐂𝐂𝐀
GTM Engineer
Paris | Hybrid, 3–4 days in office
Fluent French and professional English required.
Build sourcing, enrichment, ICP scoring and the workflows feeding Attio.
https://lnkd.in/gZCr8F27
𝐈’𝐌 𝐇𝐈𝐑𝐈𝐍𝐆 𝐀𝐓 𝐍𝐀𝐕𝐀𝐍
Senior GTM Engineer
Palo Alto / San Francisco | Four days in office
This is the role I’m hiring for.
Build production agents, connect Salesforce, Slack and internal data, and own the work from prototype through deployment. Evals, human review, monitoring, permissions and rollback paths.
If you’ve shipped systems people depend on, I want to see what you built.
https://lnkd.in/gSUHiFKY
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 3w ago
Every SDR and AE I talk to wants the same thing: tell me who to call next. The problem isn’t that we need more data for them. It’s that we haven’t architected the decision between the data and the rep. Here’s how I think about fixing it:
Instead, we give them five tabs, conflicting records, disconnected signals and AI-generated research. Then we ask them to figure out what is true, whether the timing is real and what to say.
The seller is still being used as the integration layer.
𝐈 𝐭𝐡𝐢𝐧𝐤 𝐭𝐡𝐚𝐭 𝐝𝐞𝐜𝐢𝐬𝐢𝐨𝐧 𝐡𝐚𝐬 𝐬𝐢𝐱 𝐩𝐚𝐫𝐭𝐬, 𝐢𝐧 𝐭𝐡𝐢𝐬 𝐨𝐫𝐝𝐞𝐫:
The Account.
The Signal.
The Intent.
The Person.
The Play.
The Message.
But the seller shouldn’t have to work through all six.
The system should turn them into three decisions:
𝟏/ 𝐓𝐫𝐮𝐭𝐡: 𝐓𝐡𝐞 𝐀𝐜𝐜𝐨𝐮𝐧𝐭 + 𝐓𝐡𝐞 𝐏𝐞𝐫𝐬𝐨𝐧
Is this the right company and the right person?
Identity, hierarchy, ICP fit, role, contact data and relationship paths all have to be resolved before anything gets scored. If the truth is wrong, nothing built on top of it can be trusted.
𝟐/ 𝐓𝐢𝐦𝐢𝐧𝐠: 𝐓𝐡𝐞 𝐒𝐢𝐠𝐧𝐚𝐥 + 𝐓𝐡𝐞 𝐈𝐧𝐭𝐞𝐧𝐭
Is there a real reason to act now?
Signals are external changes: hiring, funding, an acquisition or a new office. Intent is behavior inside our world: website activity, research or engagement with something we own.
One tells us what changed. The other tells us they may care.
𝟑/ 𝐀𝐜𝐭𝐢𝐨𝐧: 𝐓𝐡𝐞 𝐏𝐥𝐚𝐲 + 𝐓𝐡𝐞 𝐌𝐞𝐬𝐬𝐚𝐠𝐞
What should the seller do and say?
That might mean a call, an email, an introduction, waiting or no outreach at all. The play chooses the move. The mess…
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 3w ago
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 3w ago
The hardest GTM Engineering decision is not which AI tool to buy. It is deciding which parts of the system should belong to a vendor and which parts your company must own:
I have been thinking about this a lot lately because we are about to make the same mistake with AI that we made with SaaS.
We keep buying another tool to solve another piece of the GTM problem.
Salesforce. Clay. ZoomInfo. FullEnrich. The Swarm. ChatGPT. Claude. Grok.
And now it feels like every one of them has an agent or wants to become the place where the work happens.
But here is the thing:
None of them know exactly how your company sells.
They don't know which account matters. Which signal you trust. What intent actually means inside your company. Who the right person is. Which play is approved. Or what your seller should say.
I spent a large part of my career as the seller opening all of those tabs and trying to piece the answer together.
Now I am thinking about the system that should make those tabs disappear.
I don't think the answer is building everything internally. That makes no sense when these tools are getting better every day.
I also don't think we can pick one vendor, turn on its agent and expect it to understand every decision we've made about our GTM motion.
So the test I keep coming back to is pretty simple:
𝟏/ 𝐂𝐨𝐮𝐥𝐝 𝐚𝐧𝐲 𝐜𝐨𝐦𝐩𝐚𝐧𝐲 𝐮𝐬𝐞 𝐭𝐡𝐢𝐬 𝐭𝐡𝐞 𝐬𝐚𝐦𝐞 𝐰𝐚𝐲?
If yes, buy it. We don't need to rebuild contact data, enrichment, models or every other building block ourselves.
𝟐/ 𝐃𝐨𝐞𝐬 𝐢𝐭…
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 9d ago
Don’t add another surface for AEs or SDRs. Nobody needs another “AI-native” tool to log into. As a GTM Engineer, your job is to make the work disappear. Here’s what the future looks like:
𝐒𝐥𝐚𝐜𝐤 𝐢𝐬 𝐭𝐡𝐞 𝐬𝐮𝐫𝐟𝐚𝐜𝐞.
Your rep is already there asking:
“Who owns this account?”
“What changed?”
“Do we have a reason to reach out?”
Then we make them leave to find the answers.
Open the CRM.
Check the enrichment.
Find the research.
Paste it back into Slack.
You can build a better workflow.
An agent brings the account, the evidence and the proposed next step into the conversation.
The brief lives in a Canvas.
The next steps live in a List.
The rep reviews, edits or approves right there.
Slackbot is already a teammate in that workspace. Your custom GTM agent can work alongside it.
Underneath, the agent operates the tools.
That’s why Clay’s CLI and API-first products like MoltSets interest me. You can build around agent access instead of another interface the rep has to learn.
You decide what it can access, what it can do and when it needs a human.
What are you still making your reps leave Slack to do?
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 8d ago
I wouldn’t hire a GTM Engineer because their demo worked. I’d ask what happens when the data is wrong, the owner is missing and the agent wants to send anyway.
Here’s the conversation I’d want to have:
𝐌𝐞: The workflow found a contact and drafted an email. But the account records disagree. What happens?
𝐂𝐚𝐧𝐝𝐢𝐝𝐚𝐭𝐞: I’d stop the send and check whether we matched the right company.
𝐌𝐞: Turns out it’s a subsidiary. There’s no owner on the record.
𝐂𝐚𝐧𝐝𝐢𝐝𝐚𝐭𝐞: I’d check the parent account and routing rules. An empty field doesn’t mean nobody owns it.
𝐌𝐞: The rep needs it today.
𝐂𝐚𝐧𝐝𝐢𝐝𝐚𝐭𝐞: I’d give them the conflict, the sources and who can resolve it. I wouldn’t make them redo the research.
𝐌𝐞: You fixed this record. How do you keep it from happening again?
That’s where I’d spend the interview.
Show me the check you’d add.
The cases you’d test.
What the rep sees when the check fails.
Otherwise, the rep becomes your QA process. They catch the mistake, clean up the account and explain why the email shouldn’t have gone out.
If you’re interviewing GTM Engineers, put a broken record into the demo.
Then ask them to work through it.
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 3w ago
One of the worst experiences in sales is opening 50 tabs to make one call... and still calling the wrong person. Pipeline generation has lost its operating surface. Here’s how I think we fix it:
LinkedIn says the person left six months ago.
Salesforce says the account is yours.
ZoomInfo has a mobile number.
Clay found a timely signal.
ChatGPT writes email.
And somewhere in Slack is the one piece of context that would have told you not to call.
You finally pick up the phone. Wrong person. Wrong timing. Bad message.
Then the prospect asks: “How did you get my number?”
And somehow this becomes the seller’s failure.
I don’t believe it is.
We didn’t give sellers intelligence.
We gave them homework.
Salesforce became the system of record. Google Sheets became the working surface. Now AI has exploded the work across tools that each solve a piece, but none of them own the complete decision.
This is where GTM Engineering matters.
The work is not connecting one more tool. It is deciding what the system should know, trust and do before the seller ever sees it.
I believe the next pipeline generation surface takes one of three forms:
𝟏/ 𝐁𝐮𝐢𝐥𝐝
Create an internal system like Cursor’s ChatGTM that understands your accounts, methodology, context and approved plays.
𝟐/ 𝐁𝐮𝐲
Use an emerging product like Centralize that brings the context and next move into one place.
𝟑/ 𝐆𝐨 𝐡𝐞𝐚𝐝𝐥𝐞𝐬𝐬
Run the decision system behind the scenes and deliver a prioritized feed into Slack or the CRM.
My in…
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 11d ago
GTM Engineers: make the Salesforce login obsolete and give your sellers an agent in Slack that earns its place by helping them sell:
Your company needs accurate records.
That doesn’t mean your sellers need to spend their day maintaining them.
I spent years opening tabs, piecing together account context, and figuring out what to do next.
Why are we designing the next generation of GTM around keeping that behavior intact?
𝟏/ 𝐌𝐚𝐤𝐞 𝐭𝐡𝐞 𝐥𝐨𝐠𝐢𝐧 𝐮𝐧𝐧𝐞𝐜𝐞𝐬𝐬𝐚𝐫𝐲
Bring the seller who to contact, why now, what to do, and what to say. Show the evidence. Let them challenge the answer and approve the next step in Slack.
𝟐/ 𝐊𝐞𝐞𝐩 𝐭𝐡𝐞 𝐫𝐞𝐜𝐨𝐫𝐝𝐬. 𝐎𝐰𝐧 𝐭𝐡𝐞 𝐫𝐮𝐥𝐞𝐬
Salesforce can remain the operational record. The company owns qualification, trusted signals, approved plays, and permissions.
“We need Salesforce” doesn’t settle where sellers should work.
𝟑/ 𝐁𝐮𝐢𝐥𝐝 𝐭𝐡𝐞 𝐆𝐓𝐌 𝐑𝐮𝐧𝐭𝐢𝐦𝐞
The architecture to prove: Snowflake or Databricks for governed data. Clay for GTM workflows. GitHub for versioned instructions, policies, and tests. An OpenAI-powered agent serving sellers in Slack.
Reliable writeback, approvals, and auditability are engineering requirements. Another chatbot won’t satisfy them.
I’m building the supporting GTM Engineering Market Map and will share it separately.
Defend the login: which seller workflow must stay inside Salesforce, and why?
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 2w ago
OpenAI Dots, Meta Muse and GrokBot all made the same bet: the future of AI is a persistent agent with its own computer. That changes what GTM teams can automate, but it does not solve the hardest part:
Dots gets a cloud computer, connected applications and the ability to keep working between conversations.
Muse runs inside a dedicated secure VM, connects to the applications someone chooses and keeps an audit trail of what it does.
GrokBot gets a persistent cloud computer with a browser, filesystem and terminal so it can carry work across tools.
The point is not which one wins.
The category just changed.
We are no longer adding another chatbot to the GTM stack. We are giving an agent a computer, access to applications and the ability to act on our behalf.
That is incredibly exciting.
It is also where I think a lot of GTM teams are going to make the same mistake we made with SaaS: buying the runtime before architecting the system around it.
None of these agents automatically know which account record is true. Which provider to trust. Whether a signal is real. What intent means inside your company. Which play is approved. Or when a human needs to stop the action.
A cloud computer does not solve that.
Here is the operating model I think GTM teams now need:
1/ 𝐓𝐫𝐮𝐭𝐡 𝐚𝐧𝐝 𝐜𝐨𝐧𝐭𝐞𝐱𝐭
The CRM, warehouse and owned systems hold the history. Clay and the provider layer resolve, enrich and shape the context the agent needs.
2/ 𝐏𝐞𝐫𝐦𝐢𝐬𝐬𝐢𝐨𝐧 𝐚𝐧𝐝 𝐜𝐨𝐧𝐭𝐫𝐨𝐥
The agent needs a clear bound…
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 3w ago
Everyone wants to use Grok Bot. Then enterprise security realizes the agent runs on a persistent cloud computer with a browser, filesystem and terminal. The demo is the easy part. Here is the hard part:
A seller connects their tools and asks the agent to research an account, find the right person and prepare the outreach.
Ten minutes later, it has opened the tabs, moved the files and started doing the work we normally lose hours to.
That is the moment everyone wants.
Then the enterprise questions start.
Whose identity is the agent using? Which credentials can it access? What data can leave the environment? Which actions require human approval? Who shuts it down when something goes wrong?
That is not security killing innovation.
That is the difference between a great demo and an operating system a company can actually trust.
AI-native companies have an advantage here. They can design the company around agents from day one.
Established enterprises have years of permissions, workflows, systems and human habits built for people clicking buttons, not agents taking action.
You cannot drop AI into that mess and expect it to work.
I think every enterprise agent needs four gates:
𝟭/ 𝗜𝗱𝗲𝗻𝘁𝗶𝘁𝘆
Whose account is it acting through, and who is accountable for what it does?
𝟮/ 𝗔𝗰𝗰𝗲𝘀𝘀
Which systems and data can it reach, and what is explicitly off limits?
𝟯/ 𝗔𝗽𝗽𝗿𝗼𝘃𝗮𝗹
What can it do alone, and what must stop for a human decision?
𝟰/ 𝗔𝗱𝗼𝗽𝘁𝗶𝗼𝗻
Do the humans understand when to tru…
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 1d ago
Your GTM agent can follow every instruction and still do the wrong thing. The failure usually starts before the prompt:
Imagine it flags an account for expansion because product usage spiked.
The spike came from a test workspace. The recommendation looks credible. A rep acts on it, and now the customer has to explain why the message makes no sense.
The agent didn't invent the signal. We never told the system which usage counts.
That is the part of GTM engineering I think we underestimate. Before I write the play, I want a small contract for its data:
𝐒𝐨𝐮𝐫𝐜𝐞: Which events are eligible, and which are test or internal activity?
𝐈𝐝𝐞𝐧𝐭𝐢𝐭𝐲: Which customer and workspace do they belong to?
𝐅𝐫𝐞𝐬𝐡𝐧𝐞𝐬𝐬: How old can the event be before we stop using it?
𝐒𝐭𝐨𝐩 𝐫𝐮𝐥𝐞: If any answer is missing, does the agent hold the play or show the rep what needs review?
Then sample the recommendations every week. Save the false positives. Change the data contract when the product, accounts, or behavior changes.
You don't finish the foundation and move on to AI. Maintaining the foundation is how the agent stays useful.
What data rule did you only discover you needed after a GTM play went live?
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 3d ago
Salesforce, ZoomInfo, Clay, Hightouch and Profound are all making a claim on GTM context. If I were solving this as a GTM Engineer, here's where I'd start:
With the decision the agent needs to get right.
Each answer maps to what the company sells: Salesforce has the platform. ZoomInfo the graph. Profound marketing context. Hightouch the harness. Clay workflow memory.
They are partly right. The trap is choosing where context lives before defining what the agent needs to know.
If I got this problem tomorrow, I would start here:
Which account should the seller work today, and why?
Then I would write the context contract:
𝟏/ 𝐄𝐯𝐢𝐝𝐞𝐧𝐜𝐞
Facts required before a recommendation.
𝟐/ 𝐀𝐮𝐭𝐡𝐨𝐫𝐢𝐭𝐲
The source that wins when systems disagree.
𝟑/ 𝐅𝐫𝐞𝐬𝐡𝐧𝐞𝐬𝐬
How old each signal can be.
𝟒/ 𝐂𝐨𝐧𝐟𝐢𝐝𝐞𝐧𝐜𝐞
What turns research into a recommendation.
𝟓/ 𝐒𝐭𝐨𝐩 𝐫𝐮𝐥𝐞
What requires human review.
𝟔/ 𝐅𝐞𝐞𝐝𝐛𝐚𝐜𝐤
What happens when the seller corrects it.
Only then would I choose the architecture: Snowflake for facts and history. GitHub for definitions, policies and tests. Clay to assemble context and run the play. Slack for the seller to review, act and correct it.
Specialist vendors earn their place by improving one input or decision.
A vendor can own part of the system. None should become your company’s definition of truth.
Before buying a context platform, write the contract for one GTM decision. If the vendor cannot show the source, freshness, conflicts, stop rule and feedback loop, you are buyi…
