GTM Engineering with Agents: A Field Guide to Automating the Funnel

GTM Engineering with Agents: A Field Guide to Automating the Funnel

Summary

Every go-to-market team is really running a handful of pipelines. Leads come in, get cleaned up, get scored, get worked, and either turn into revenue or quietly rot. Most of that work is mechanical, and most of it gets done by hand or by a tangle of point-to-point integrations that break the moment a vendor changes an endpoint.

This guide takes the agentic approach the rest of the series is built on and points it straight at the funnel. The idea is simple: wrap every source you care about (your CRM, your enrichment providers, your email, your product analytics) as an MCP tool, then let small agents orchestrate the motions on top of them. Capture, enrichment, scoring, outbound, nurture, hygiene, forecasting, churn signals. One tool surface, many agents, each running on a schedule.

It's hands-on. We build each motion as a small agent loop over MCP tools, wire them together with a cron, and put guardrails around the parts that can email a customer or overwrite a record. By the end you'll have a mental model for GTM as a system of agents, plus enough concrete patterns to start replacing the manual busywork on your own stack.

It pairs with MCP from Scratch for the protocol and Running the Fleet for orchestration. This one is about pointing all of that at pipeline.

This is a living document and will be updated as the tools and patterns evolve.

Loading The Funnel Is Already a Pipeline…
Loading One Tool Surface, Many Agents…
Loading The Record Everything Agrees On…
Loading Capture: Clean at the Door…
Loading Enrichment Without Burning the Budget…
Loading Scoring You Can Argue With…
Loading Outbound: The Motion That Can Embarrass You…
Loading Follow-Up on a Timer…
Loading Hygiene: The Boring Agent That Pays…
Loading Signals: Expansion and Churn…
Loading Forecasting You Can Defend…
Loading Guardrails and Blast Radius…
Loading The Daily Run…
Loading Rolling It Out Without Breaking Revenue…
Loading Toolkit: The GTM Agent Checklist…
Loading About Roger…

Do you like my content?

Sponsor Me On Github

Keep reading

AI Project Management: Shipping Software When Agents Write the Code

AI Project Management: Shipping Software When Agents Write the Code

Something strange happened to my job this year. The typing got cheap. An agent can turn a paragraph of intent into a working pull request while I refill my coffee, and yet the projects did not get faster. Not really. More code shipped, more PRs merged, and somehow the same features took roughly the same number of weeks to actually land. That gap is what this guide is about. When machines write the code, the scarce thing is no longer the writing. It's the specifying, the slicing-up, and the reviewing. Project management stopped being about handing out work and started being about feeding agents instructions clear enough that their output is worth keeping, then catching the parts that aren't. I've been running this way for a while now: specs before code, work cut into agent-sized pieces, a small fleet on separate worktrees, and a review loop that assumes the machine got something subtly wrong. This is the playbook I wish someone had handed me. It covers spec-driven development, decomposition, acceptance criteria an agent can test against, parallelism without chaos, the review loop, governance for code you didn't write, and the handful of metrics that tell you whether any of it is actually working. It's written for engineers and tech leads who already use agents to write code and want to run real projects with them, not demos. _This is a living document and will be updated as the tools and the workflows keep evolving._

Read guide
The Agentic Playbook

The Agentic Playbook

Everyone agrees you should be building agents. Nobody agrees on how. One camp says drag nodes on a canvas and ship this afternoon. The other says real agents live in code, in your repo, behind your own API. They're both right, and the argument is a distraction: the loop is the same either way. A model, a set of tools, a memory, and a stopping condition. Once you see that, the question stops being "which side is right" and becomes "which lane fits this job." This playbook walks both lanes properly. The first half builds agents in n8n: the AI Agent node, tools it can actually call (including MCP servers), memory and RAG on the canvas, human approval gates, multi-agent patterns, and the Evaluations feature that tells you whether any of it works. The second half builds the same ideas in TypeScript with the Vercel AI SDK inside an Astro site: a streaming chat endpoint, real tool definitions with schemas, the ToolLoopAgent, approval gates in code, structured output, and MCP as the bridge that lets your n8n workflows and your code agents share the same tools. It pairs with [Mastering n8n](/guides/mastering-n8n) (which covers hosting and hardening the platform itself) and [Roll Your Own Coding Agent](/guides/roll-your-own-coding-agent) (which builds the raw loop from nothing), and once you're shipping agents, [QA in the Era of AI](/guides/qa-in-the-era-of-ai) shows what happens when you point them at your test suite. This one is about shipping: picking a lane, building the agent, and knowing when to switch lanes as the job outgrows the canvas. _This is a living document and will be updated as the tools and patterns evolve._

Read guide
QA in the Era of AI

QA in the Era of AI

I've worked at companies with entire QA departments: rooms of people clicking through the same flows before every release, filing tickets, arguing about repro steps. Most of that job is now something you can wire up. Not because testing got less important, but because agents got good at exactly the parts that burned humans out: reviewing every pull request, walking the same three flows every morning, catching the console error nobody looked for, filing the ticket with the screenshot actually attached. This guide is the system for doing that on purpose. It started with [a post about my dialer QA bot](/blog/how-to-use-claude-code-to-qa-your-website), where Claude Code drives a browser through real call flows and files GitHub issues for whatever breaks. Here we build the whole department around that idea: AI code review as the first gate (and the real tradeoffs between the tools), agents that write tests plus the mutation-testing trick that keeps those tests honest, browser agents that smoke-test every preview deploy, visual and accessibility passes, and the loop that turns every failure, from staging or production, into a filed issue that another agent fixes. (And if you want to build agents like these yourself, that craft is [The Agentic Playbook](/guides/the-agentic-playbook); this guide is about putting them to work.) And because I'd rather you trust this thing for the right reasons, we spend real time on where it breaks: agents that pass tests they should fail, self-healing tools that heal around genuine bugs, prompt injection hiding in the very pages your QA agent reads, and the work that still belongs to a human with product judgment. The goal isn't zero humans. It's humans doing the 30% that was always the actual job, with a tireless department underneath them. _This is a living document and will be updated as the tools and patterns evolve._

Read guide