So I took the GTME mindset to actually defining GTM Engineering. I used AI and Exa.ai to find open roles and practitioner profiles, then built a database and a web app to help explore it and a Notion workflow to keep it updated daily.

I pulled 1,058 job listings (983 open), 1,167 named practitioners, and 867 hiring companies and I used Cursor to analyze each role and title, extract the skills and estimate the knowledge needed for each role.

The job category is exploding. Clay coined the title in 2023. The Signal recently reported that 54% of the fastest-growing B2B SaaS companies now have a GTM Engineer (or someone doing the job under another title). There are hundreds of open roles. Carilu Dietrich, who advises hypergrowth companies, is calling them Marketing Engineers. a16z launched a Growth Engineer Fellowship. Toast posts “GTM Engineer, Marketing Operations AI Innovation.” Profound calls them AI Marketing Engineers. Drew Bredvick, who runs GTM Engineering at Vercel, has the catchiest description I have read: “pattern recognition turned into automation.” His first agent at Vercel took the inbound SDR team from 10 to 1, saved $2M+, and was built in a weekend.

I also found there are occasionally customer-facing roles that get misclassified into this job title, but they’re something separate. The main job? Building their own company’s pipeline, sales, and renewal engine.

Where the term came from (and how it’s evolving)

Clay came up with the category.

In their July 2025 essay they wrote the title was minted there in 2023, when around 100 GTME job listings were going live every month. As of late 2025 that had already grown past 245 a month, with the Signal projecting close to 2,700 listings for 2026. The original definition: a GTM Engineer was someone who used Clay (and its ecosystem) to build automated, signal-driven outbound. It meant finding the right account, enriching it, scoring it, and getting outreach to the right person at the right time with the right context, all automated. This was a good frame. It gave a name to work that high-leverage outbound teams were already doing. It also helped Clay create and own a category.

But ask any four people what the job actually is today and you will get six answers (I actually asked at our last GTME event and recorded the answers.)

“A GTM engineer is someone who can explain what GTM is to an AI agent, stitch together all kinds of APIs, visualize their workflows, and define that with the proper context to AI.”

“A GTM engineer is someone that knows very well how to use AI and all the tools that we have today for go-to-market, and can bring everything together to create great GTM systems that reduce a lot of the manual work.”

“My understanding of GTM engineering is starting to apply code to all forms of marketing, whether that’s community building, lead generation, it doesn’t really matter. Now code is leveraged for every function, not just for building product or infrastructure.”

The original scope (mostly focused on external data and outbound motions) was focused on people with specific revenue system skills. In the last 18 months, two things happened that shattered the scope.

The first is that AI made building accessible to people who don’t write code. A demand-gen marketer with Cursor and an MCP can ship a workflow in a weekend that used to require a quarter of engineering time. A RevOps analyst who has never opened a Python notebook can stand up an account research agent in an afternoon. A marketing leader can wire up an SEO pipeline made of nine specialized agents and a tenth orchestrator on top of her own GTM data.

Second, once GTM operators could build, the whole job started changing. Lifecycle marketing, website copy, account research, pipeline forecasting, competitive intel, renewal risk, campaign personalization, AEO and answer-engine visibility, brand presence inside LLMs. All of it started looking less like a list of tasks and more like a set of systems somebody has to design, instrument, evaluate, and ship.

The shift for GTMEs

There is a precedent for this: we already saw a similar shift in engineering. When swyx, who established the largest AI engineer community, wrote The Rise of the AI Engineer in 2023, the role looked like one thing: someone who specializes in taking generic foundation models into valuable products, doing the prompt, context, and harness engineering to build agents, and shipping more productively with AI.

Three years later, that role has constantly evolved. Some AI Engineers are product engineers with prompt skills. Others are platform engineers running model gateways, evals specialists, forward-deployed engineers embedding with customers, or research-adjacent. The original definition did not shrink. The market expanded around it, and now we call all of them “AI Engineers” and squint to figure out which kind we mean.

GTME is going to do the same thing, but faster, because the underlying skill is more transferable.

The shape of GTME today

When I analyzed the open GTME positions, the data supported the hypothesis that the market is rapidly shifting. The role is already expanding into different archetypes. I found eight that will probably shift and merge over time.

Here is the full breakdown of all 1,058 job listings (983 open):

All eight share the same underlying workspace (unified GTM data, agents and workflows on top of it, evaluation loops, and a measurement discipline that ties the system back to revenue), the outputs just take different shapes depending on which part of the funnel the role lives in and what the company is optimizing for.

The success metrics, on the other hand, are completely different by archetype. An Outbound GTME is measured on meetings booked from automated plays. An Exec / CoE lead is measured on org-wide AI adoption and pipeline efficiency. A Marketing Engineer is measured on pipeline-influenced or AEO visibility. A RevOps Evolution role is measured on routing accuracy and lead-to-opportunity conversion. A Founding GTME is measured on revenue, full stop.

If the role is evolving this fast, the ecosystem has to evolve too. Below are roles broken down by subtype, size of hiring company and location.

Biggest challenges currently facing GTM engineers

Problem 1: GTM Engineers need a unified data layer for internal GTM data.

Clay won outbound by giving GTM Engineers a clean platform for external data. Pull a list. Enrich it. Score it. Sequence it. The reason a Clay power user can ship in days is that someone else already did the awful work of unifying every enrichment provider behind one interface.

Internal data has no equivalent.

Every GTM Engineer who tries to build something that depends on what actually happened inside their own company hits the same wall. Salesforce is a swamp. HubSpot has the marketing side, half-synced. Gong has half the calls. Outreach has half the emails. Marketo has the campaigns from three CMOs ago, with naming conventions from two RevOps eras ago. The data warehouse has whatever someone’s analytics engineer copied over last quarter, and probably stopped maintaining six months later. The GTM Engineer’s first ten hours go to plumbing, not product.

Validity’s 2025 CRM data report found that 76% of organizations said less than half their CRM data was accurate and complete. AI exposes this weakness in a way that older tools never did. A model can summarize a call. An agent can draft an email. But if the underlying account hierarchy is broken, or the contact roles aren’t filled in, or the same person shows up under three email addresses, the agent is guessing.

The thesis is simple. GTM Engineers need a unified data foundation they can build on without spending a quarter stitching together CRM, calendar, email, calls, and product usage. And it cannot just unify broken data. It has to use messy data as signal and rebuild a clean, enriched data lake for AI. The teams who have built this themselves are pulling ahead in real time.

Problem 2: There is no agreed-upon success metric for the role.

When you hire a software engineer, you know what good looks like: PRs merged, incidents resolved, p95 latency, test coverage, on-call performance. Imperfect, but legible.

When you hire a GTM Engineer, every team measures them differently, and most teams haven’t written down what “good” means at all. They know it when they see it. Which is to say, they hire by vibes.

This is fine in 2026 because there are roughly four times as many open roles as qualified people. It will not be fine in 2027. The first GTME you hire on a strong gut feel is a great hire. The fifth one you hire that way is a disaster, because by then you have stacked five different definitions of the role on top of each other and nobody can tell which work is moving the business.

The category needs a measurement vocabulary. Until it has one, every GTM Engineer is going to be quietly underrated by their company until the day their system stops working and everyone realizes how much pipeline was secretly running through it.

Problem 3: There are no widely adopted agent harnesses built for GTMEs.

If you spend any time on LinkedIn (where most of GTM lives), you have seen Claude take over. My friend Alina Vandenberghe, the CEO of Chili Piper calls it “AI psychosis” because everyone is building with Claude and posting their morning briefs.

I personally use Cursor more. I love the harness, I love that it is better at solving its own problems, and I like being able to try GPT 5.5 for what I am building. But whether you use Claude or Cursor, these tools were built for developers. They were not built for the GTME architect persona: team memory, permissioned GTM data access, repeatable evals, safe handoffs into business systems.

Companies like Dust and Glean are taking on the problem at scale, while other teams are building this in house. Zapier has just launched its own product, and so has Notion (though more developer focused). And for companies like Ramp who want to build their tools internally, Claude is moving fastest in this area with a consulting-led enterprise approach and just announced a $1.5B JV. OpenAI is fast following with OpenAI Deployment Company, both aiming to help enterprises adopt AI.

Every GTM person needs to develop GTME skills (or risk becoming obsolete)

This is the uncomfortable part of the essay. The market is splitting GTM people into two groups, and the split is going to compound very quickly.

There are people who work within the system given to them: these are the slide-deck CMOs, templated-sequence SDRs, dashboard-only RevOps analysts and campaign managers who only configure tools that other people built and operators who only file tickets. Leaders who can describe a strategy but cannot prototype the machine that would execute it.

Then there are people who build the system. They may still hold the same titles: CMOs, SDRs, RevOps leaders, demand-gen marketers, PMMs, SEs, founders, growth leads. But they have added the builder muscle. They use AI to research, write, code, orchestrate, analyze, test, and deploy. They can rebuild a workflow in a weekend instead of writing a brief and waiting two quarters for the implementation.

This does not mean everyone becomes a traditional engineer. It means everyone in GTM has to understand how to design, evaluate, and adapt systems. The work itself becomes software.

Three months ago I was still mostly copy-pasting prompts into ChatGPT. I was not starting from zero. I co-founded Branch, scaled it to thousands of enterprise customers, and served as its CMO for years. I had spent that whole time building marketing teams, revenue systems, attribution models, and growth engines. But I had not built much software in years. I operated like a traditional GTM executive. Decide the strategy. Ask the team for the execution. Review the dashboard. Repeat.

Then we started building internal AI systems at Upside, and I stopped being a requester.

I shipped our case-study skill, an eight-phase pipeline that goes from “name the customer” to a published webpage. It generates the interview questions from past examples, researches the answers through the Upside MCP and Fireflies, finds the exact video timestamps for the strongest quotes, validates every claim against source data, drafts in Google Docs, and publishes the HTML. The numbers it pulled for our Assembled case study (30k+ hidden contacts discovered, 37k+ hidden touchpoints uncovered, 2x more accurate pipeline) it found itself. I just picked which ones to lead with. I also built a self-updating GTME database that uses tools like Exa and Notion to pull roles and practitioners together all in one place.

Teams are hiring for a named GTME role right now because all these skills are still so fresh that it often makes sense to centralize them…but don’t kid yourself: everyone in GTM is going to have to learn some of these or not have a role in the next 12-18 months.

How to become a GTM Engineer

If you have read this far and thought “I am not technical enough for any of this,” I have to tell you, you are wrong. I was not technical enough three months ago. Here is what actually changed how I work, in the order it happened.

1. Think in systems, not in tasks. Every time you catch yourself doing a thing twice, ask if the second time should be a system, not a one-off automation. A real system, with memory, evaluation, and a feedback loop.

2. Overuse AI on the work you think you are best at. The temptation is to use AI for the work you don’t want to do, and keep doing the “real work” yourself. That is exactly the wrong instinct. Instead, use AI for the work you are most proud of. Force yourself to teach a model to do it.

3. Pick a problem that fights you. Pick something that has been annoying you for a year. The first version will be embarrassing. Ship it anyway. The second version will be three times better than what you would have produced if you had tried to architect it correctly up front. My project? Building a self-updating GTME hub.

4. Steal from the people doing it. This is the part everyone underestimates. The GTME community is small enough and people love to show how they are building and our last event below is just an example.

If you are building, hiring, becoming, or trying to figure out how to measure a GTM Engineer, join the community. It is forming in real time, and the people who join now are going to define what this role looks like for the next ten years.

That post hit a nerve. I got several GTM operators messaging me to ask how the plumbing actually works. The answer is the Model Context Protocol (MCP), the thing that lets an agent like Claude talk to Salesforce in natural language. And the next question was: How do I get that? This is where I’d point them to (surprisingly) an open source project that I was using…

That question got a lot more interesting last week.

What Salesforce announced, and when

There are two timelines running in parallel here, and it’s worth pulling them apart.

December 2024: A solo developer, Tushar (github: tsmztech), publishes mcp-server-salesforce (https://github.com/tsmztech/mcp-server-salesforce) under an open source/MIT license. It supports 18 tools. It does almost everything a GTM operator would want. You can query records, create them, update them, describe objects, run SOSL, execute anonymous Apex, and manage schema. I’ve been using it to build custom objects, populate data, set up workflows, and keep my CRM up to date automatically from emails/call transcripts (thanks to the Upside MCP).

May 30, 2025: Salesforce releases its own official DX MCP Server (https://github.com/salesforcecli/mcp), published as @salesforce/mcp on npm, in Developer Preview. They pitched at developers building in VS Code, Cursor, and Claude Code.

April 15, 2026 (five days ago): At TDX 2026, Salesforce announces Headless 360 (https://www.salesforce.com/news/stories/salesforce-headless-360-announcement/). The framing is key: “No browser required.” “The most ambitious architectural transformation in our 27-year history.” More than 100 new MCP tools and skills. The entire platform, reframed as infrastructure for AI agents. I turned into the heart-eyes emoji, immediately.

That’s the announcement I want to talk about. Because for a GTM audience, the messaging sounded exactly like what I wanted (and was already doing). AI does the CRM work, now with much better tools (yay).

What actually shipped

I pulled the full tool inventory of @salesforce/mcp directly from the repo. There are a LOT. Things like data, metadata, testing, code-analysis, orgs, users, aura-experts, lwc-experts, mobile, mobile-core, devops, enrichment, scale-products, experts-validation, etc (over 90 in total).

Here’s what the official server can do:

• Run SOQL queries (but sadly, read only?!)

• Deploy and retrieve metadata between your local DX project and the org

• Run Apex tests and Agentforce agent tests

• Run the Salesforce Code Analyzer

• Scaffold LWC components, Aura migrations, mobile capabilities

• List orgs, assign permission sets, create scratch orgs

Here’s what it cannot do:

• Create, update, delete, or upsert a single record. There is no DML tool anywhere in the package.

• Describe an object or retrieve picklist values. No schema introspection. If you have picklists, this is a blocker.

• Run SOSL or cross-object search.

• Execute anonymous Apex for one-off operations.

Turns out… every single thing I was doing in a GTM Engineer capacity (creating opps from emails, updating stages, enriching records, backfilling custom objects) requires at least one of those four capabilities. The official server cannot do any of them.

This is not a beta gap that will close soon– I believe it’s actually a design choice. The Salesforce DX team’s model is that your local DX project is the source of truth, and agents should deploy versioned metadata and run tests. Ad-hoc data mutation belongs elsewhere. That’s a defensible engineering stance, and may be appropriate for large organizations with swaths of SFDC devs. But it means the official server is a developer SDK, not a GTM Engineer/operator tool, despite the marketing framing.

The community MCP ships all four of those capabilities and it’s what I (continue to) run.

Security

A reasonable question: is one of these safer than the other?

In practice, for how most people will run them, no. Both use the local Salesforce CLI (sf) to authenticate. The same access token, org scoping, and user permissions. Whatever the authenticated user can do in the org, the MCP can do.

One nuance: the community MCP also supports username/password and OAuth client-credentials as alternative auth paths. Those could be riskier if you store credentials in a config file. Sidenote- please make sure your SFDC org is secured by Okta or similar– it’s worth the effort to keep things secure. The official MCP only supports CLI auth, which is slightly safer by default. If you use the CLI path for both (which you should), the security posture is identical.

“But isn’t the official one safer for a big org?”

This comes up every time I talk to a RevOps leader about this. The argument goes: the official MCP can’t write data, so it can’t cause damage. Hand it to anyone and the worst they can do is a bad query. Isn’t that the right choice for an enterprise?

Turns out that’s a reasonable assumption to make, but it’s not necessarily true.

Salesforce’s permission model already handles this. Whichever MCP you run, it authenticates as a specific user and inherits that user’s permissions. If your analyst can’t delete opportunities in the UI, they can’t delete them through any MCP either. The safety layer is the profile, not the tool. If your admin is worried about blast radius, the answer is a scoped service user with a tight permission set, not a server that happens to ship without DML.

The read-only property of the official server isn’t a safety feature. The DX team didn’t remove DML to protect you. They removed it because their model of the world is “mutate Salesforce through versioned metadata deploys, not ad-hoc data changes.” It’s their philosophy, not a designed guardrail.

The bigger point: GTM engineers are builders. It’s hard to build if you can’t easily write.

My take

Salesforce doesn’t really want you to leave Salesforce. The Headless 360 announcement is, in part, a reaction to the fact that agents operating over APIs make the UI optional, which threatens the stickiest thing about the platform. Responding to that by opening up the API surface is the right instinct. It’s a good step.

But the product that shipped under the MCP banner is a dev tool. It’s aimed at people writing LWCs and deploying metadata from Cursor. It is not the product a GTM engineer, RevOps leader, or operator wants when they say “let my agent update Salesforce for me.”

The solo-maintained, 153-star community project is closer to what that pitch describes than the thing Salesforce shipped.

So for now: I’m still running the community MCP. It’s what turns “the best CRM is the one your team never has to open” from a tagline into a workflow. When Salesforce ships DML, describe, SOSL, and anonymous Apex in the official package (and I hope they do, because first-party support matters), I’ll reconsider. Until then, I’ll keep using my open source MCP.

And look– I might be wrong here. I invite you to challenge my stance/findings here. Everything is moving so quickly, and I know I still have a ton to learn here.

Leave a comment

Share

Last week we hosted a webinar with three people who are basically doing our job better than we could. Matt Grebow from ServiceTitan built personalized sales kits for 100 closed-lost accounts in two days. Carl Gunlefinger from Comply shipped a paid search dashboard in 30 minutes. Charlie Flanagan from Dscout turned 520 closed-lost deals into a coaching system his sales team is actually using.

None of them wrote traditional code. All three are what our own Alex keeps calling GTM engineers, building real analytical apps on top of their own GTM data using the Upside MCP, Claude, and Craft Agents. A year ago, every one of these would have been months of data team work.

And here is the punchline nobody gets tired of saying: AI makes it possible to ask much better questions and build internal tools in hours, not weeks. But that only works if the data underneath is clean. That is where Upside sits, and all three of these builds ride on top of it.

Also if you are interested in seeing live demos of AI Marketers or GTM Engineers building with AI, join us for our next event!

Check out our GTM Engineer Meetup

A Quick Note on Upside

For people new to us: Upside is the data foundation for GTM engineering. We connect to Salesforce, Gong, HubSpot, Marketo, plus all the unstructured stuff that never makes it into the CRM (emails, meeting transcripts, notes) and we rebuild a clean, trustworthy version of what actually happened in every deal.

Entity resolution, buying group detection from signals buried in emails and calls, touchpoint reconstruction, activity deduplication. On top of that foundation we add dashboards, Deep Research reports, pre-built analysis recipes, and an MCP (Model Context Protocol) that any AI agent or custom mini-app can query directly. Every build below sits on that foundation.

One example of data healing: Upside automatically detects buying group members that were never logged as contact roles in the CRM.

Meet Today’s GTM Engineers

Matt Grebow // ServiceTitan - Director of Enterprise Marketing

Built: Roofing Win-Back Sales Kit for 100 accounts

Carl Gunlefinger // Comply - Senior Marketing Operations Manager

Built: Paid Search Impact, Webinar Performance, and a Single-Deal Replication Dashboard

Charlie Flanagan // Dscout - Head of Marketing Operations

Built: Loss Analysis System and Contact Engagement Tracker

100 Personalized Sales Kits in Two Days

Matt runs enterprise marketing at ServiceTitan. He told us he started using AI reluctantly, thinking carefully about which skills his team should keep doing as humans and what was safe to delegate.

The necessity part was harder to ignore. ServiceTitan had plenty of tools measuring activity and logging touchpoints, but the valuable context was sitting in sales emails, Gong calls, and notes nobody had time to read.

“We were collecting and reporting on signals, and from those signals we were inferring intent. But the context of those signals lives with sales, in emails and phone calls and notes. Upside stitched a lot of these data points together, and when I saw that, it created this epiphany for me where I finally understood what was possible.” // Matt Grebow, ServiceTitan

The Problem

The sales team wanted to re-engage about 100 closed-lost roofing accounts that had seen a demo once and passed. Generic follow-up emails were not going to cut it.

The Solution: An Auto-Generated Win-Back Sales Kit

Matt’s vision was a detailed, company-specific narrative for each of the 100 accounts. His list:

• A summary of all previous opportunity notes and calls, including transcript summaries

• A list of the important contacts and what each of them cares about, gathered from both first-party conversations and third-party research

• A summary of all product enhancements ServiceTitan had shipped since that account last saw a demo, tied back to that account’s specific interests

• Talking points and objection handling mapped to each contact’s role and business concerns

• A draft email sequence for each company and contact

Then he said the part we loved: “and oh yeah, let’s do this for a hundred accounts.”

The data came from Salesforce, Gong, and Marketo, passed through Upside and cleaned up, with a layer of third-party research and intent signals on top.

Each kit opens with a re-engagement assessment and jumps into recent news, account narrative, decision makers, product enhancements since close, messaging framework, talking points, case studies, and draft emails.

A couple of sections surprised even Matt. With access to ServiceTitan’s positioning docs, the agent started generating mini battle cards tailored to each account’s competitors. Pointed at their case study library, it pulled the exact stats and testimonials that mapped to each account’s concerns.

The Impact

Idea to first draft: one day. Another day of feedback. Two days total for a system that covers 100 accounts.

“I gave it a list of the topics I wanted to cover, pointed it toward the data sources, and Claude built the kit.” // Matt Grebow, ServiceTitan

If you want to see the demo in action, we published a short clip of Matt walking through it.

From Question to Published Dashboard in 30 Minutes

Carl runs marketing operations at Comply. Mailroom at an accounting firm, recovering attorney, six years in ops and analytics at Connect America, seven-plus years in marketing operations now. Exactly the right kind of person to build these apps.

Carl wanted to solve something a lot of ops people recognize: give leadership the top-level KPIs and give the operators underneath the actionable detail, all in the same place. His words: zoom out and zoom in at the same time.

“By nature, I love building reports. I love figuring out ways to put information together that doesn’t belong together. It’s been a blessing and a curse. This new tool really makes it a blessing.” // Carl Gunlefinger, Comply

He built three mini-apps. We had questions about all of them.

Mini-App 1: Paid Search Impact

Paid search is one of Comply’s few big investments this year. Direct conversions are trackable in Salesforce, but every marketer knows direct conversions are the tip of the iceberg.

Carl typed one question into Claude via Craft Agents, asked three follow-ups, and had a published preview 30 minutes later. Six tabs: Overview, Campaigns, Keywords, Landing Pages, Journeys, Conversion Velocity, Strategic Insights.

Mini-App 2: Webinar Performance Dashboard

Tying every webinar back to pipeline and revenue is the painful part. Carl built it anyway.

We have done that by hand for years in our own dashboards. If you use the MCP, the agent is smart enough to figure it out itself.

Mini-App 3: The Single-Deal Replication Playbook

Our favorite. Carl’s sales leaders closed a deal last quarter and wanted to understand how to replicate it. So Carl built a dashboard for that one deal: every touchpoint, every channel, every person, every inflection point, and the replication playbook you could pull from it.

Carl ran Upside’s activation analysis first, then built the dashboard through the MCP. The aha: how many channels and touchpoints contributed to this one deal, and how many replication suggestions came out of the pattern. He is already making a dynamic version so sales and marketing can pick any opportunity and pull up the same playbook.

“Literally from idea to preview publication, probably 30 minutes.” // Carl Gunlefinger, Comply

Turning 520 Closed-Lost Deals Into a Coaching System

Charlie heads up marketing operations at Dscout, an AI-powered user research platform. A decade in SaaS, seven years deep in marketing ops. Dscout’s CMO likes to say the team needs to “defend the budget,” and Charlie lives that.

“A lot of what we did originally was just exporting Salesforce reports and me manipulating data in spreadsheets. It was a big time sink.” // Charlie Flanagan, Dscout

The Problem

Dscout had 520+ closed-lost opportunities with the usual surface-level CRM reasons (timing, budget, product fit) and a sales team that needed real narrative insight to improve. Who did we actually lose to? Who wasn’t in the room? What do winning deals have that lost ones don’t?

The data to answer those questions exists, but it is scattered across Salesforce, Gong, HubSpot, and sales activity logs. Stitching it together by hand is exactly the kind of work that makes ops people tired.

Mini-App 1: Closed-Lost Analysis

Charlie’s closed-lost analysis gives an overall breakdown of why deals were lost, the dollars tied to each reason, and filters to ask more specific questions. New product launching that addresses a specific loss reason? Here are the exact accounts you can go back to.

The app also gets into competitive data: who Dscout is in bake-offs with most often, on which accounts, and whether losses came from a single factor or multiple factors stacking.

But the tab Charlie gets the most use out of, and the one Mada called out as her favorite, is “How to Win.”

“Closed-lost opportunities filtering has been recognized as a significant win. It gives our sales leaders something specific to train on.” // Charlie Flanagan, Dscout

Mini-App 2: The 3 Contacts Engaged Tracker

You need to be multithreaded to sell enterprise SaaS. At Dscout, when the team engages three or more contact roles on an opportunity, win rates jump significantly. Charlie built a mini-app to track exactly that.

Then Charlie made it operational. Not a static dashboard but a live view sales leaders use for coaching. Filter to a team or rep, see which open deals have three engaged contacts and which don’t, see how fast those contacts got engaged and what stage the deal is at.

What Charlie loved: Upside already heals the buying group and identifies everyone actually involved in a deal. This app intentionally compares that to who sales manually added as a contact role. The gap becomes the coaching conversation. “Upside knows Jennifer Armstrong is a stakeholder on this deal. Why haven’t you added her as a contact role?”

Small detail we loved: Charlie asked Claude to add mouse-over explanations on every data column. Hover over a field and the app tells you exactly how the number was calculated. He called it “a pretty awesome unlock” for sharing apps with colleagues who didn’t build them.

Charlie shared the closed-lost analysis with Dscout’s go-to-market leaders in a marketing metrics meeting last week. If you want to see him walk through how he built with us, we have a short clip of Charlie on the Upside channel.

What Matt, Carl, and Charlie Have in Common

Three patterns show up in all three builds:

Speed. Idea to deployed mini-app in hours. Two days for Matt’s 100-account kit. 30 minutes for Carl’s paid search dashboard. The real investment is no longer engineering time. It is the quality of the question being asked.

No code. Nobody wrote traditional code. They described what they needed, pointed the agent at the data, reviewed, iterated. Matt used Claude. Carl used Claude via Craft Agents. Charlie used Claude through Claude Cowork.

Good data is the moat. Every one of these apps sits on top of Upside’s cleaned, unified data layer. Without data healing, deduplication, and buying group detection underneath, you just get confident hallucinations on top of broken CRM fields.

Watch the Full Webinar

Every demo in this post is worth seeing live. Full recording:

More From Our YouTube Channel

A few more videos we have published that go deeper on pieces of this:

• Personalized Sales Kits for 100 Accounts in 2 Days // Matt’s Win-Back Sales Kit in a short clip

• Upside Gave Me the Keys to the Kingdom // Charlie on going from biweekly collaboration to building his own mini-apps

• Start Small, Prompt Better // The three big lessons from Matt, Carl, and Charlie

• AI + Personalization = Less Generic Marketing // Matt’s take on why AI actually makes marketing more human

• How to Automate Five Marketing Functions // Our own webinar covering five marketing workflows we’ve automated

• How Dscout Connected HubSpot, Salesforce, and Gong in 5 Minutes // The original MCP integration demo that got Charlie started

• What Are MCPs and Why They Still Matter // Tools vs Skills, APIs, and building local MCPs

• Three Favorite AI Developer Tools Marketers Should Use // Claude, Craft, and Cursor

• How to Uplevel Your GTM Reports With AI and the Upside MCP // A practical walkthrough of building analytical mini-apps

• How to Automate Case Study Creation With AI and Upside MCP // From transcript to published page

• How to Build a Fully Automated, Self-Improving Ads Orchestrator // Level 10 on the GTM AI Adoption Ladder

Subscribe to the Upside YouTube channel for more of these walkthroughs, or check out our Future of Marketing podcast wherever you listen.

And if you want to see what building on top of Upside looks like for your own GTM data, you can start at upside.tech.

Three months ago, we were just asking ChatGPT basic questions. Today we have AI agents running our SEO pipeline, optimizing our Google Ads account daily, building case studies from scratch, and managing most of our marketing operations. Here’s exactly how we did it, and how you can too.

We recently hosted an AI in marketing webinar where we walked through the five marketing workflows we’ve automated with AI agents. We wanted to go beyond theory and actually show our real setups, real prompts, and real results. This post is the complete breakdown of everything we shared.

A quick note about us: Mada used to be a software developer, stopped coding for many years, and co-founded Branch (which grew to $100M+ revenue) where she led marketing. Dan has spent his career in demand gen and marketing operations at companies like Outreach, MuleSoft, and Branch. We started Upside to solve problems we both lived with for years: not understanding what’s actually working in marketing.

The GTM AI Adoption Ladder

As we’ve been talking to customers and other marketers, we’ve noticed a clear pattern in how people adopt AI for go-to-market work. We built what we call the GTM AI Adoption Ladder, inspired by something Gary Tan created for engineers, but tailored for GTM teams.

People start at the bottom, just copying and pasting stuff into ChatGPT. Then they move to having AI draft content. Then AI gets plugged into your tools. Then AI starts handling lead enrichment. Then agents start running on autopilot. And at the very top? The orchestrator learns from its own results and evolves without you having to tune it manually.

Three months ago, Mada was probably at Level 1 or 2. Even in just three months, she’s now closer to Level 8 or 9. Dan has built one workflow (the ad optimization agent, which we’ll cover) that we think actually qualifies as Level 10. The pace of improvement here is wild.

Our Favorite Orchestrator AI Tools for Marketing

Everyone has their own setup, and people talk a lot about Claude. But we actually use three main tools, each for different things.

Claude

This is the one everyone knows. Dan and we both use it, but it’s not actually our primary tool. It’s best for research, writing, and analysis. Mada was prepping for a podcast interview recently and asked Claude to research the guest and generate questions. It did such a good job finding all the background and context that would have taken an hour to do manually. She only had to add a few questions on top.

Craft Agents

This is Dan’s favorite tool. Craft is similar to Claude in some ways, but it has built its own connectors to services like Substack, Google Sheets, and more. For example, Mada built an entire article in Craft and it published directly to Substack, which was really smooth. The big difference is that Craft lets you build automations, schedule recurring tasks, and connect to pretty much anything.

One thing to keep in mind: Craft is great for builders and people you trust to know how to use data. It’s harder to control what people connect to across a whole organization. Claude, on the other hand, has really good security controls, which makes it better for large teams.

Cursor

Yes, Cursor is technically a developer tool. Mada has never written a line of code in it. But she finds it really powerful for building reports, HTML files, dashboards, and interactive apps. Even though it doesn’t build its own connectors the way Craft does, it’s more flexible in letting you add your own connectors. The harness of Cursor just feels more powerful than using Claude directly for building things.

Pro tip that made a huge difference for us: Make sure you’re using the latest model. When Mada started with Cursor, her results weren’t great, and her team pointed out she wasn’t using Opus 4.6. The model you pick is probably the single most important factor in the quality of work you’ll get. We’ve found that Opus is dramatically better than Sonnet and Haiku for these kinds of tasks. Hallucinations are rare these days if you’re on the right model.

What is an MCP (and Why Marketers Should Care)

A lot of our workflows use MCPs, so let’s quickly explain what they are. MCP stands for Model Context Protocol. It’s basically a wrapper around an existing API that is custom designed for an AI agent to use.

If you’ve worked with APIs before, you know they’re built for developers. There’s documentation you have to read, authentication to figure out, query formats to learn. With an MCP, you just give the AI agent a URL, and it configures itself. It figures out how to use the tools, what the best practices are, and basically trains itself.

The Upside MCP, for example, includes things like what analytical mini-apps should look like, what the styling guide is, how to query customer data. When you connect it to Claude or Craft, the agent just knows how to use all of that immediately.

Skills: Turning Prompts into Reusable Instructions

The other concept that powers everything we do is “skills.” Skills are basically the ability to turn prompts into reusable instructions. They sound complicated but they’re actually simple to create. You can ask Claude or Craft or Cursor to help you create a skill.

Under the hood, a skill is just a markdown file that gives the AI agent structured instructions. AI agents are better at reading this format than plain text. But here’s the thing: you don’t need to write this file yourself. You go through a session, do the work, and then at the end say “Hey, make a skill based on everything we just did.” It creates the skill file, and next time you can just reference it.

In Craft, you can even set up recurrence. For example: “Turn what we just did into a skill and run it three times a day at these times.” One important caveat though: in Craft, your computer needs to be on for scheduled skills to run. Cursor has something called background agents that don’t require your computer to be on, but we haven’t tried those for marketing workflows yet.

Workflow 1: Building a Case Study (Fully Automated)

This was Mada’s first skill, and it’s the one she’s most proud of. Building case studies used to involve a ton of manual work: researching the customer, coming up with interview questions, conducting the interview, pulling metrics, writing the narrative, formatting everything.

The first few case studies on our website were built with AI help, but in a very manual way. Ask the MCP for questions, interview the person, feed the recording back in, try to turn it into HTML. Way too many steps. So Mada set out to automate the entire pipeline into a single skill.

Here’s how the skill works:

Phase 0: Setup and Integrations. You give it the customer name and point it at example case studies. It then connects to the Upside MCP (which has all our Salesforce, HubSpot data, and external call recordings), Fireflies (for deeper internal calls), Slack, and Notion.

Phase 1: Generate Questions. It looks at past case study examples, parses the structure and tone, and generates about 21 questions organized by section. It presents these for approval before moving on.

Phase 2: Research Answers. After the interview is recorded and transcribed (the recording ends up in our MCP automatically), the agent researches answers using the Upside MCP. It runs SQL queries against pipeline data, searches call transcripts, checks Slack discussions, and pulls from Notion docs.

Phase 3 and 4: Video Snippets and Quotes. It searches transcripts for compelling moments, ranks them, and extracts quotes. For our Assembled case study, it even found the exact video timestamp to clip.

Phase 5: Data Validation. This is important. It pulls actual SQL metrics (revenue, pipeline, before/after numbers), cross-references every claim against source data, and flags any gaps. When it gave us metrics, we asked it “how did you calculate this?” and it gave us citations and methodology for each number.

Phase 6: Draft in Google Docs. It creates a draft and shares it. Instead of editing the draft directly, Mada left comments in Google Docs. The agent then took all the comments (and later the customer’s comments) and revised accordingly.

Phase 7: Publish as Webpage. It generates the HTML, applies our design system, and either pushes to Webflow via MCP or outputs an HTML file that we dropped into Lovable.

The data points in the case study (30k+ hidden contacts discovered, 37k+ hidden touchpoints uncovered, 2x more accurate pipeline data) were all found by the agent using the Upside MCP. Mada didn’t have to go calculate any of those herself. The agent actually gave her six data points and she just picked the best ones.

One thing we want to emphasize: we still conduct the interview ourselves. We don’t think AI should do that. The interview is about relationship building, and even if it were technically possible to automate, we would not. That human connection matters.

Workflow 2: Content on Steroids

We’ve started a podcast called The Future of Marketing, and Mada wanted to see if she could fully automate turning podcast episodes into Substack posts. She connected Craft to the Google Drive folder where all the podcast recordings and transcripts live, and asked it a question we’d never actually asked our guests directly: “Based on the entire transcript, how would this guest answer the question ‘What is the future of marketing?’”

The agent went through each transcript, inferred how the guest would answer, and then created a full blog post. But here’s the really cool part: because we gave it access to the Figma MCP, and our designer had a brand guideline document for the podcast, the agent was able to read those guidelines and create branded images that actually looked professional.

Yes, the content is AI-generated. But it’s based entirely on actual conversations that real people had. The AI is summarizing and synthesizing original content, not making things up. We think that distinction matters a lot.

Workflow 3: GTM Analyst

There are some really powerful things you can do when you give AI agents access to your data. One example: we wanted to figure out the best time to send our outbound emails, based on when those emails actually get responses.

We know there are tools out there that offer this, but we wanted something customized to our specific segments of emails. Dan generated the dashboard you see below with literally one prompt: “Use the MCP, find all the emails we’ve sent, categorize them into ones that had a response, break it down by day of the week and hour of the day.”

The agent went further than what we asked. It figured out we were probably trying to find optimal send times, so it automatically added tables showing the highest and lowest performing time slots, and it even factored in statistical significance to filter out times where we hadn’t sent enough emails to make a real claim.

Our takeaway from our own data? Send emails early in the morning, before noon. Everything after noon gets progressively worse. Or, interestingly, send on the weekend at night. That seems to work surprisingly well too.

Channel Attribution with AI

We also built something more advanced: a multi-agent attribution system. Seven agents go through a deal and each one argues which touchpoints should get credit. Then a supervisor agent mediates the discussion. “You think this marketing email should get credit. Why?” It reasons through and comes up with a final percentage breakdown.

This is a pretty advanced application, and each deal takes about an hour to process. It looks at both explicit touchpoints and inferred influences (things it picks up from call transcripts and emails). Any of our customers could build something similar on top of their own data. (We explored this further in our Revenue Efficiency in the Age of AI panel.)

We also helped one of our customers, Ethan, understand what was actually driving his inbound leads. The tool discovered that referrals were huge for his business. And here’s the insight that no dashboard would have surfaced: the people attending his events weren’t directly becoming customers, but they were referring customers. So the ROI of events looked bad on paper, but was actually fantastic when you traced the referral chains.

Workflow 4: SEO Planning and Content Creation

This is Dan’s project, and it’s the most complex orchestration we’ve built. When you think about how SEO actually works, it falls into several buckets: finding keywords, analyzing SERPs, doing research, writing content, polishing it, publishing it, and then monitoring and optimizing over time.

We asked ourselves: how much of this could be done with a series of agents? The answer: almost all of it. But not with one agent. With nine separate agents.

Why nine agents instead of one? Two reasons: context windows and time. If you give one agent this entire job, it will run out of context and start forgetting things. We experienced this firsthand. Mada tried to do a similar analysis with just one agent looking at a hundred deals. After four deals, the agent was doing great. By the end, it had forgotten half the instructions and dropped the quotes it was supposed to include. It also took four hours. We names this NIMA after Nima Asrar Haghighi who taughed Dan everything he knows about SEO.

By breaking the work into specialized agents, each one becomes really, really good at just one thing. They start to emulate what an actual SEO team looks like in practice.

The whole system was created with a single (very long) prompt: “Build an AI-powered SEO content pipeline with nine specialized agents that go from keyword discovery to publication. Each agent has one responsibility. They read from one shared backlog in Google Sheets. When they finish their work, they put the output in a file that the next agent picks up.”

How the Pipeline Flows

The orchestrator (the 10th agent) sits on top and acts like a project manager. It looks at the sheet, figures out what needs to happen next, calls the right sub-agent, reports progress, sends Slack messages, and makes sure the process moves forward. It never writes content itself.

The keyword discovery agent connects to Google AdWords and SEMrush to find high-potential keywords. The SERP analyst evaluates the competition for each keyword and decides whether we can realistically outrank what already exists.

The topic researcher creates a full research brief pulling from external sources (via Exa web search) and internal data (via the Upside MCP, which gives it access to what we’re hearing on customer calls, what language our prospects use, what problems they describe).

The editor agent takes only that research brief (not the internet, just the compiled research) and writes a draft. This is important: by constraining what it can see, the output is much more focused. When done, the article goes into a Google Doc for our human review.

When we leave comments and feedback, the agents incorporate that feedback into their own prompts so they learn over time. The orchestrator can even reject work and send it back for additional editing if it doesn’t meet quality standards.

On avoiding AI-sounding content: We’ve built guidelines into the editor agent to avoid telltale signs of AI-generated writing (m-dashes are banned, for example). The agent is also designed to pull actual quotes from things we’ve said on calls and in emails, so the writing comes out in our own voice. Nothing gets published without human review.

Workflow 5: Ad Campaign Management and Optimization

This is the one Dan is most excited about, and honestly, we think it might be the most impressive. Dan was staring at an empty Google AdWords account and realized: building this out manually (ad groups, ads, keywords, negative keywords, bid management, testing) is a massive amount of work for a whole team. But we have agents now.

The prompt: “Build an AI-powered Google Ads optimization agent that runs daily. Pull performance metrics since the last run, classify search terms using LLMs and web research, and automatically add negatives for terms that don’t relate to us.”

Here’s how it works in practice. The agent checks what keywords we showed impressions for, then uses the Upside MCP to understand if that keyword is relevant to what we do. It also does a web search to see what comes up for that keyword and assesses whether we should be bidding on it. Irrelevant terms get added as negatives automatically. Terms it’s unsure about get sent to Dan for his opinion. And when Dan provides that feedback, the agent remembers it going forward.

Beyond just pruning bad keywords, the agent also runs ongoing tests. It’s optimized to increase click-through rates and conversion rates, so it’s constantly experimenting with bid levels, ad copy, and landing page pairings. It logs the context of every test it runs, and on each daily optimization, it checks in on those tests to decide whether there’s enough data to call a winner or if it needs more time.

The daily summary shows green across the board. We’ve been running this for about a month, and every time we check, we see improvements in impression share and click-through rate because it’s constantly pruning low performers and adding better keywords and ad text.

It’s even created all of Dan’s ad campaigns, ad groups, and naming conventions from scratch. In the beginning, he just told it: “Figure out a naming convention that works for you and stick with it.” It even recommended building custom landing pages to improve quality scores for specific keywords.

One fun detail: to connect to Google Ads via API, you need to go through an MCC account and submit an application. Dan had Craft look at the application, write a description of the optimization agent, create screenshots of a UI it designed, and submit it. Google approved it in two days.

Bonus: Marketing Operations Automation

Beyond these five main workflows, we’ve been using agents to automate a huge amount of our day-to-day marketing operations. Dan has over 40 connectors at this point. The philosophy is simple: most tools have either an API or an MCP, and once you start connecting them, things get really interesting.

Here are some of the things we’re running on autopilot:

Webinar launch workflows. For this very webinar, we told the agent to set up all the HubSpot workflows, connect to SQL, sync to a Salesforce campaign. It did all of that. Then we said “turn that into a skill” because we’ll host more webinars and always want the same setup.

Personalized outreach. To promote the webinar, Dan asked the Upside MCP to look through all his emails, meeting invites, and transcripts, then provide a list of the top 100 people he should invite. The agent created the email template in Apollo. Dan just personalized each one.

Inbound lead tracking. An agent analyzes all inbound leads over the past few weeks, checks if we followed up, how many times, whether a meeting was booked, if they RSVP’d. It flags anomalies like someone who accepted a meeting but then RSVP’d no, and drafts a re-engagement email.

Lead qualification on autopilot. As leads come in, the agent does web research, historical research via MCP, figures out the context of that account and person, and makes a specific recommendation on how to follow up.

Weekly product analytics. This is common for marketing teams: a weekly deck with web visits, leads, MQLs. Dead simple with an agent. Connect to all the data sources, pull the numbers, and it creates Keynote slides that look exactly like your existing format. We actually found that Cursor creates better-looking slides than Google Slides. Especially good when you provide a template and tell the agent “this is the format, now populate it with this week’s data.”

Salesforce administration. Sometimes in a meeting someone says “we need two more fields in this report.” Dan just prompts the agent to create those fields. The fields get created, field-level security is set, they get added to page layouts. All the clicking that would normally take 30 minutes happens in seconds.

What We’ve Learned

A few things have become clear to us over the past few months of building all of this.

We feel more like managers now. Even though we don’t have a large team, all we do is give agents instructions and then review their work. It’s a different way of operating, but it’s surprisingly productive.

Always ask “how did you calculate that?” When agents give you stats or metrics, ask for citations and methodology. Our MCP has extensive instructions on how to compute metrics and it won’t make things up, but we still verify. If an agent says “pipeline increased 40%,” we ask “from where to where?” and “what’s the attribution?” Sometimes a number is technically accurate but misleading in context.

Multiple specialized agents beat one general agent every time. Context windows are still the limiting factor. One agent doing a complex multi-step job will start forgetting instructions partway through. Nine specialized agents, each with a narrow focus, produce way better results.

Memory is the hard problem. When one agent learns something from a report, how does that knowledge get shared? We’re building our own memory systems for this, and it’s something the entire industry is working on.

The model matters more than anything. If your results aren’t good, check which model you’re using. Opus 4.6 is so much better than Sonnet or Haiku for these tasks. If you tried AI for marketing work a few months ago and weren’t impressed, try again now. The improvement is significant.

Human review is still essential. Nothing gets published or sent without our eyes on it. But the nature of our work has shifted from “doing the thing” to “reviewing and directing the thing.” We think the future of marketing is actually more fun, because we get to focus on the creative, strategic work and hand off the repetitive, boring parts to agents.

We’re building Upside to be the intelligence layer on top of your GTM data, and these workflows are proof of what becomes possible when your data is structured in a way AI can actually understand. If you want to try any of this yourself, the MCP connectors, skill files, and prompt templates we used are all available. Just reach out.

Subscribe now