The week’s highlights

• The harness debate heated up. Mitchell Hashimoto asked a good question: if a generic agent plus your data beats every product’s built-in chatbox, “why your box over mine?” Guillermo Rauch pushed back with the case for owning your own agent. And Clay answered by finally shipping an API after three years of saying no, because “founders are designing for agents as importantly as for humans.” Our take: people get attached to their harnesses and having our own agent (which we do) can never be the only option to using Upside. Also home come there is no harness build for GTM builders?

• The data layer is the bottleneck, not the model. KeyBanc analysts reported that Agentforce is stalling because customer data “is not in order to do meaningful AI work.” Nobody wants to pay for AI through their CRM. Everybody still has to fix the data first.

What we’re pondering

1. Own the context, rent the intelligence. Bret Taylor’s post on how Sierra runs itself on agents, where he argues the durable advantage is not owning the model, it is owning the context and workflows that make every model more useful. The fear with foundation models is that they end up owning your memory: every learning your team accumulates from working with AI stays trapped with one vendor, and if you ever leave, they keep your intelligence. The alternative is to rent the model from whoever is best this month and own the context yourself, portable, exportable, yours. So in our case, when a customer asks “can I take my memories with me if I leave,” we say yes. Switching costs mean losing the machinery that maintains them, but they are yours. I think that answer will win more deals over time than any lock-in would.

2. Everyone is saying the same words.We have been mapping the landscape, and every day we see a new company saying the same (we noticed even older companies moving into this space): take all your data, clean it up, make it ready for AI. Selling context has become every vendor’s talking point. Which means the sentence itself is now table stakes, and the differentiation lives underneath it, where very few are actually building. For us, underneath looks like this: the model was never the bottleneck in agentic GTM, your data is. So we put our effort into the unglamorous parts like persona deduplication, buying group enhancement, data extraction. We also invested in making every number, touchpoint and insight traceable to its source, because nobody trusts a number they cannot trace, building permissioning and data governance. In the long run, when everyone says the same we believe who does the unsexy work wins.

3. A eulogy for the generic context layer. Kirk Marple wound down Graphlit this month after five years of building a genuinely impressive context platform, solo. His postmortem stuck with us: “people understand paying for tokens and model usage; paying for a platform layer on top is harder unless value, buyer, and distribution all line up.” The lesson we took: a context layer that is not welded to a specific business outcome is a feature, not a company. It either becomes open source infrastructure or it lives right next to the value it creates.

4. The fight for third-party data. Companies buy third-party data (enrichment, intent, contact info) under licenses that say: use it inside your own walls, do not pass it along. Now put an agent in the middle. If our agent buys a signal while working for customer A, can it reuse that signal for customer B? The data brokers’ answer is a firm no. That would be one purchase pretending to be two, and if agents can redistribute data the way Napster redistributed music, nobody buys from the source again and the supply dries up for everyone. To be clear, plenty of buyers would love a Napster for data, they pay a lot for these signals today. It is the sellers who cannot survive it. So agents will have to buy per customer, with receipts. We actually think this is good news for data vendors: agents are about to become their biggest customers, and the ones who design for agent buyers will sell more, not less.

5. The human in the loop is tired. The Pydantic team wrote the essay everyone deploying agents needed to read: review fatigue, not model quality, is the real bottleneck. I noticed myself feeling extra tired at the end of the day - because I usually run 2-5 workflows all the time and most of my time is spent context switching and reviewing instead of building. Yishan Wong explains why: when everything lower-level is done by something else, all that remains for you are the high-stakes, ambiguous calls. That used to be the CEO’s job description. Now it is everyone’s, and “most people are not equipped for this.” Scott Leese made the same point from the GTM side, looking at Vercel’s lead-qual numbers: the real story was six weeks of shadow mode and a three-person team watching before anything went live. The RevOps team is slowly becoming AI governance.

What we’re experimenting with

1. Multi-threading on steroids

The problem is simple: reps know they should reach several people at a target account instead of one, because more contacts means more meetings booked. Almost nobody does it, because researching five people takes hours per account. We helped a customer automate this: a rep presses one button and three agents run in sequence: the first works out who at the account is actually involved in the buying decision, the second researches each of those people, and the third drafts outreach for all of them. The rep gets back a ready-to-run kit: who to contact, what we know about them, and what to say. Humans still choose which accounts deserve the push. The agents just make the legwork nearly free and Upside makes sure the agents target the right people.

2. I started a subreddit.

I kept wishing there was one place to ask practitioners what actually works in AI for GTM, in a place where LLMs can read it. So I started one: r/AIinGTM. It is a few days old and already has the conversations I wanted to be having: what’s actually working using AI in GTM, favorite AI harness, and a breakdown of 1,000+ GTME job posts. The plan is to answer questions in public, compare favorite tools, and talk openly about the ones we are building and help each other rank for LLMs. Please join and if interested in helping me moderate it, send me a note!

3. Attribution by judge and jury.

Running our Pipedash attribution on new customers blows us away every time. It runs as teams of AI agents that each analyze a deal independently, then vote. The agents reach consensus or escalate. We are designing courtroom procedure for software. Alex went deep on this pattern in his AI Engineer talk, Design Patterns for AI Trust: Juries, Libraries, and Agent Tiers. And if you want to nerd out with us live, we are hosting a webinar on how to solve attribution with AI. Come with your messiest attribution question.

Show and tell: GTME Talks

This week we hosted Show & Tell: AI for GTM at Notion HQ, and it blew past every plan we had: over 2,200 registrations across the room and the livestream, plus a long waitlist. This community is starting to feel like a movement. We record everything, and the full playlist is now live. Three from this week to start with:

• Assembled: Closed-Lost Deals Convert Best. Maitrik Shah on the system that re-engages the deals you already lost, your highest-converting leads.

• Notion: All Your Customer Data, One Page. Eric Goldman on the Customer Hubs that Notion runs its own GTM motion on, kept fresh by agents.

• Baseten: Tens of Thousands of Signals, a Penny Each. Ben Levitt on monitoring the signals only your team cares about, across tens of thousands of accounts, for pennies.

And we are already looking for a home for the next edition. If your company has space in SF and wants a few hundred GTM engineers in the building for a night, reply to this email or DM me :)

The coolest new GTME roles this week

• Founding GTM Engineer at Rovi Health (YC F25, NYC). AI health concierge, and the job description includes managing sales collateral in GitHub. Highest paid role of the week: $150-200K base, $250-400K OTE plus early equity.

• GTM Engineer, Marketing at Nooks (SF). A GTME dedicated purely to marketing: attribution, routing, and “systems that make failures visible before they become problems.”

• GTM Engineer at Bluejay (YC, SF). $90-160K with equity stretching to a full 1%. Tiny team, real upside.

• GTM Engineer at Ben (London). The agent stack is written directly into the job description: HubSpot, n8n, Make, Claude, Attio.

• GTM Systems Analyst at Ashby (Remote). Up to $162,438, a number so precise it must be the output of a model.

Three new trends: Marketing is getting its own dedicated GTMEs instead of borrowing them from sales ops. The agent stack is now written directly into job descriptions, the way SQL used to be. And comp for founding roles has stretched wide, from $90K with real equity to $400K OTE, depending on how early you are willing to go.

Worth your attention

• Joan Westenberg’s bread paradox: the counterargument to “AI kills SaaS.” Convenience always wins, and most people will keep buying bread instead of baking. This was my favorite this week and a good reminder.

• Guillermo Rauch: “Make the model a cog in a machine you own. Own your data, evals, model choices. Don’t outsource your brain.” The week’s thesis in three sentences.

• Aaron Levie’s dinner notes from a table of enterprise IT leaders: agents need their own roles and privileges, and “all enterprise software must be headless.”

• Michel Lieben had Claude Code read 6,750 LinkedIn posts from 25 viral creators to extract what actually works. The replies are a masterclass in people missing the point.

• Addy Osmani on agent harness engineering. The discipline got a name this week.

• More companies are pulling back the curtain on their internal machinery: Cerebras wrote up how they built their company knowledge base, and Neil Rahilly noticed that Sierra runs on a custom harness too. Company brains and custom harnesses are quietly becoming standard equipment.

• The HN thread on Claude Code sending 33k tokens of harness before reading your prompt. That is a lot of throat clearing before the actual work starts.

• The Memory Heist: a researcher tricked an agent into exfiltrating its own memory. If item one of this issue is right and context is the asset, this is what stealing looks like now.

• Databricks’ CEO on enterprises moving “from tokenmaxxing to valuemaxxing”. The phrase is doing a lot of work, and it is the right work.

• Carles Reina on what he would do restarting ElevenLabs GTM from zero: senior sellers, faster hiring, and outbound from day one. The mass-email debate from last issue continues.

The most ridiculous story of the week

The team at Atomik launched Sliceline, the pizza delivery startup from HBO’s Silicon Valley, as if it were real. A $6M raise “to turn sad employees into happy ones, one pizza at a time,” a polished launch video, a live site, behind the scenes shipping footage, even merch. The launch pulled over 760,000 views, and then Arthur Zargaryan’s writeup about going viral went viral too, another 570,000 and counting. And because reality is stranger than fiction, DoorDash actually shipped a CLI this week, which means the old XKCD bit about sudo make me a sandwich is no longer a joke. You can now order lunch from your terminal.

That’s issue two. If something here made you think of your own “everyone says the same words” moment, reply and tell me about it.

Mada

Hi, it's Mada. AI is changing how we do GTM so fast that this is the first issue of something I've wanted to make for a while: a weekend letter about what we’ve been learning and experimenting with every week, at the edge of GTM. Less news, more of what we’re pondering, building, and stealing from. And if you’re looking to steal from others, our lineup on Tuesday at our AI in GTM demos is fire :)

The week in one minute

• GTM moved into the terminal, and mass email started dying in public. ColdIQ’s Michel Lieben is walking away from his $7M ARR agency to run entire GTM motions from Claude Code. Others talked about doubling down on non-AI pipe gen: HockeyStack’s outbound playbook was built mostly on calls, not emails, and Steve Armenti, the ex-Google demand gen lead now running his ABM agency twelfth, keeps showing pipeline built from single relationships.

• The company or GTM brain debate is now buy vs build. Product marketing leader Angela Sun asked how to host her team’s homegrown GTM brain (they currently zip .md files around Slack) and got 100 comments of practitioners comparing setups. Nobody was asking which vendor to pick. More below.

• “Enterprise ready” was the question everyone kept circling in AI GTM. Alex’s AI Engineer talk on the challenges of scaling AI in GTM for large orgs, the Klue breach, and Jen Igartua’s latest all landed in the same place: controls, audit, monitoring.

1. What we’ve been chewing on

Buy the GTM brain, or build it? At AIE Track 6 last week half the talks ended up about building a version of the GTM brain in house. Arman Vaziri at Ramp walked through “Ramp Revenue,” an in-house engine that processes millions of records a day and runs more than 80% of their sales workflows. Flora Liu at Notion spent most of her talk on what AI shouldn’t own. A RevOps leader at a fast-growing AI company told us his goal is to “rebuild GTM ops with specialized agents on knowledge graphs.”

Rebuild, not buy. We had the same debate inside Upside this week and landed somewhere I didn’t expect: the brain isn’t one centralized thing. It’s AI processing plus connected memory plus contextual data wherever it lives, with just enough centralization to stay efficient.

Do harnesses matter more than models? Thariq Shihipar from Anthropic said it best in his AIE keynote: the constraints on a model are usually ours, “the harness we put them in, and the way we prompt them.” Anthropic removed roughly 80% of the Claude Code system prompt for Fable-class models because the examples were constraining imagination.

As I test more new harnesses (this week Codex) I’m realizing I’ve developed real emotional attachment to my harness of choice. When a workflow is a better fit for Cursor (usually helping a customer build miniapps in Upside), I still get giddy, almost the same butterflies I get meeting a friend I feel deep comfort around. I can’t fully explain why, which is sort of the point: the same model feels completely different depending on what’s wrapped around it, and right now the gap between harnesses is bigger than the gap between models.

Fable vs GPT 5.6? Everyone’s asking which one. Thariq’s Field Guide to Fable is the best explainer I’ve found. Summarized by my co-founder, Alex: GPT 5.6 is the senior employee at the top of a long career track. Precise, experienced, great at execution, probably the last of its line. Fable is the draft pick: bigger but less trained, occasionally naive, and noticeably better at reading between the lines of what you actually meant. The advice we gave ourselves: date around. Learn to work with multiple model personalities instead of marrying one.

Why is attribution so hated? I wrote about this on Friday: Attribution didn’t just die. It was murdered by your comp plan. AI forensics genuinely solved the memory problem, reconstructing touchpoints from emails, calls, and notes. But attribution was never a math problem. The moment credit gets tied to goaling, everyone games the mirror. Solve the data and you’ve done half the job. The other half is organizational.

2. What we’ve been experimenting with

Video and images: better cameras and setup, still figuring out the creative direction. We’ve been trying to build our own explainer video, and spent real hours in Runway’s Aleph 2 and Edit Studio this week. What we’ve found: AI does the grunt work, taste is still on us. On images, no single model does it all. Midjourney V8.1 is incredibly creative, but still can’t spell. GPT Image 2 is incredibly precise but less creative, and it keeps drifting back to its own stylistic preferences. The workflow that worked for me:

1. Start in Midjourney to get the right vibes.

2. Upload that image into GPT and ask it to describe the style.

3. Generate the image in GPT using the style it just described. It does a much better job than if you hand it an image and ask for something similar.

One incredible workflow: Fable one shotted an explainer video of Upside for an advisor using our messaging docs, the Upside MCP, the Descript MCP and Fireflies recording.

A chief of staff for each of us, running every prompt. We’ve been experimenting with running all our prompts through one agent to see if it can build context and run like a real chief of staff. We use Craft Agents for this, because outside of Codex it’s the only harness that lets one agent spin out other agent windows that both it and the user can interact with. Mine does quite well at holding context and pulling higher-quality output from its subagents. We haven’t quite gotten our personal chiefs of staff to talk to each other directly yet, but they do share a Notion doc where they log learnings each day and learn from each other.

3. GTMEs we love, and demos worth stealing from

How Clay drives demand. Bruno Estrella, Clay’s head of marketing, broke down how Clay drives its own demand, and it was a masterclass in eating your own dog food. What we’re stealing: enterprise cohorts as a growth motion, exec LinkedIn content mapped to personas (each exec owns a persona, and they compete on views), a certification program that turns users into evangelists, and a promo cadence where every asset gets posted two or three times across channels plus 1:1 emails. Screenshots and notes in our internal library.

Flora Liu (Notion) and Arman Vaziri (Ramp). The two AIE talks we keep quoting. Flora on deciding what AI owns versus what a human owns, and measuring impact qualitatively because the clean dashboard number doesn’t exist yet. Arman on the building blocks of GTM orchestration at Ramp. When recordings are ready, we’ll link them next issue.

4. The coolest new GTME roles this week

• GTM Engineer at Together AI (SF, $160-190K + equity, posted July 2). The stack literally lists Claude Cowork next to Salesforce and Clay. That’s where this role is going.

• Founding GTM Engineer at Sim (SF, $120-200K + up to 1% equity). Backed by Paul Graham and Perplexity, 70K developers already. You’d build the machine that sells the machine.

• GTM Engineer at hud (SF, $120-170K). They sell RL training data and evals to frontier labs, so your buyers are ML researchers. Possibly the most interesting GTM problem on this list.

• Highest paid this week: Founding GTM Engineer at Clearly AI, $150-210K plus up to 0.4%, Seattle or remote.

5. Worth your attention

1. Vercel took a 10-person SDR team down to 1, for $5,000 a year. SaaStr session with COO Jeanne DeWitt Grosser. Lead-qual agent at 32x ROI, a support agent handling 93% of a deeply technical caseload, and her line that “GTM is turning into consulting.” If you share one thing this week, share this.

2. Why a $1.2B exit felt like failure. GTMnow with Drift co-founder Elias Torres, now building Agency toward $1B in revenue with under 100 people and no CRM. His thesis: sales is the last role AI will eliminate.

3. Cat Wu: Claude picked propensity-score matching for a retention analysis without being told to. AI is moving from summarizing dashboards to choosing analytical methods.

4. The reversibility test. Webflow CRO Adrian Rosenkranz on The Revenue Leadership Podcast: agents can own any decision you can reverse; one-way doors must stay human. And “your moat is what the LLM doesn’t have: your context.”

5. The anti-hype award goes to Tony Dinh: roughly $15K in AI usage, $157 in MRR. Token consumption is not commercial progress.

That’s issue one.

B2B attribution was never solved because it was never a math problem. It was a memory problem.

Every model, first-touch, last-touch, W-shape, all the alphabet soup, was doing math on a record that was mostly missing. A fourteen-month enterprise deal with ten logged touchpoints isn’t a data set, it’s a rounding error with a dashboard. The referral over coffee, the exec who joined one email thread but wasn’t logging her emails, the podcast they listened to last month: none of it was ever tracked. Smart people looked at that and declared attribution dead: Matt Heinz wrote the category’s postmortem, Jeff Pedowitz called it “fool’s gold”, and Adam Ortman buried last-click in Forbes. They were right about the models. They gave up one step too early, at the data.

AI changed that. Not “upload your Salesforce export to ChatGPT” (please don’t), but AI applied forensically: reading every email, calendar invite, call transcript, and CRM record, and reconstructing what actually happened, including the buying group nobody logged and the referral mentioned once on a call. People tell you on calls why they came to your website, what they asked chatGPT about you - that data is just messy and unstructured, we use it all as a source of signal (not source of truth) to reconstruct the real story.

Once you know what happened, AI can solve attribution. We did it.

Pipedash works like a jury: a panel of independent AI analysts each reads the full deal history and argues for an allocation, a judge weighs their reasoning, and every dollar ships with a citation. It baffles even the skeptics. Sales leaders at one enterprise customer pulled up deals they knew personally to stump it, and on one, the system surfaced that the connection came through an alumni association. Their words: “That was it! How did it know?!”

So attribution is solved. Which brings us to the real problem, the one no model was ever going to fix.

Everyone hates attribution because it gets used as a goal. It never should be.

“When a measure becomes a target, it ceases to be a good measure.” That’s Goodhart’s law, and it should be stapled to every attribution dashboard ever shipped.

Think about why attribution fights get so ugly. It was never really about the math. It’s that credit became comp: the “sourced by” field decides marketing’s budget, the SDR’s bonus, whose headcount survives planning season. So everyone games the inputs and inflates their claims, and you get the thread every CEO knows by heart: marketing claims $33M, SDRs claim $41M, sales claims $20M, partnerships claims $12M... and there’s $54M of real pipeline.

The collaboration cost is even worse. At Branch, our single best source of new deals was VIP dinners that marketing organized and SDRs filled with 1:1 invites. Goal each team on their credit split, and the SDR stops inviting prospects to marketing’s dinner, because helping might shrink their own number. Your best program dies first, and it dies silently.

But here’s the twist: now that attribution actually works, evidence-based allocation can’t be gamed. You can’t argue with a citation. That should be great news, but it turns out some teams wanted the weapon more than the truth. They don’t want attribution, they want a predictable metric they can goal on. When someone says “this doesn’t look right,” listen closely: sometimes it means “this doesn’t let us look like we’re doing a good job.”

Attribution is a diagnostic, not a target. It exists to teach you what drives revenue, not to decide who gets paid.

Three more problems

1. It’s expensive to run. For now. Reasoning over thousands of touchpoints per deal with a panel of AI analysts costs real compute. We’re making it cheaper by pre-organizing the data and encoding it as a knowledge graph, so every run starts from structure instead of chaos. But today, honestly, you don’t run this on every deal every morning.

2. Not everyone wants attribution. Some people want a tool that shows them they did well. A mirror, not a microscope. No technology fixes that.

3. Deal-level truth is slow. Big deals take a year or more, so even perfect attribution tells you what worked twelve months ago - and it can help you make smart investment decisions but it can not help you understand if your team is doing well now.

So here’s how to actually use it

Do attribution at a very high level. Channel, program, quarter. Where does the next $100K go, what do we kill, what do we revive. Ethan Smith’s team at Graphite found $10M+ in hidden referral revenue this way and restarted the events program that last-touch had murdered.

Never goal on attribution, goal on measured leading indicators instead. Use attribution to learn what drives revenue, then comp people on the controllable inputs it points to (new pipeline created after an event, pipeline velocity, number of leads that turned into stage 2 pipeline etc ). Never on “your team’s share of the credit.”

Put both on the same clean, comprehensive data layer. One reconstructed record of what happened, shared by every team, feeding both your attribution and your goals’ measurement and all the campaigns that help you win along the way.

If you’re wrestling with any of this, especially the “my CRO wants to comp on sourced pipeline” version, DM me or comment below. I’d genuinely love to hear how you’re thinking about it.

For as long as there’s been B2B, hiring more humans has been the best way to scale go-to-market. That age is over. People still matter (the exceptional ones more than ever), but headcount need no longer be the default scaling lever: the teams pulling ahead today are deploying agents, building internal tools, and running analyses to answer questions that would seem miraculous to someone visiting from even as recently as 2023.

This is the new age of agentic GTM, and the winners are leaning in far beyond ‘give everyone Microsoft Copilot seats and call it a day’.

You probably know all of that, and you’ve heard the next part too, from about a dozen vendors in the last quarter: your data isn’t ready for this. It’s the detritus of a tech stack built for humans working with records by hand. The agents, internal tools, and analyst-quality reports that help you scale in this new age can be afternoon projects now…but not until you have a clean, AI-native data layer to power them.

AI is only as good as the data under it, and B2B data is a swamp. We've had dirty CRMs for thirty years, but people are astonishingly good at mentally repairing the mess. AI isn’t. It can't build that context graph on its own. For the age of agentic GTM, you need a governed layer that reconstructs what actually happened and makes it usable by humans, agents, and apps.

GTM circa 2026: valedictorian interns, new heroes, and a tech stack of the walking dead

Our team has talked to hundreds of go-to-market leaders over the past two years. The future of agentic GTM is here; it’s just not evenly distributed yet. If you’re already living in the new world, nothing in this section will be news and you should probably skip it. But if your organization is just getting started on its AI-fueled journey of self-transformation, here is a quick state-of-the-industry for agentic GTM in mid-2026:

1. AI is ‘valedictorian intern on demand’. It’s book-smart as hell, a little too self-confident, and still lacking real-world experience. But it’s also able to do an absurd amount of impressive work when you point it in the right direction.

2. We’re witnessing the rapid emergence of the first truly new GTM role in many years. Whether you call them GTM Engineers (that job title has come a long way since Clay coined it as a synonym for ‘outbound automation manager’), Chief AI Intern Wranglers, or simply ‘the people who know how to turn data into intelligence and ship tools that everyone else can use’, they’re force-multipliers for their teams. They are the heroes of this new age, and nearly every org we talk to is either hiring this role or trying to grow it internally.

3. The traditional GTM tech stack is decomposing into its elemental primitives. LinkedIn influencers would have us all believe that we’re in the middle of the SaaSpocalypse and legacy products are just waiting around to die. This is overblown, of course, but many purpose-built tools are no longer necessary when Claude can do the same things for you over an MCP, or a GTME can spin up a better-fit internal replacement in a weekend.

If B2B GTM has a Rosetta Stone, attribution is probably it

At Upside, we discovered the importance of a GTM data layer while trying to do something else: in early 2024, our team set out to help B2B go-to-market orgs make better decisions by building the best multi-touch attribution model in the world. We eventually succeeded (it’s called Pipedash, and it’s quite good), but that’s the headline for a different article.

Later on, we realized what we’d actually built. The quest to fix attribution had forced us to reckon with the encyclopedia of all the ways that B2B GTM data can get screwed up: figuring out which contacts are really the same person, reconstructing who was actually in each buying group, putting scattered touchpoints back in the right order, untangling campaign naming conventions that are an archaeological dig through who was in charge back when ABM became fashionable in 2017.

We’d thought of it all as plumbing for an attribution model, but this created exactly what our customers were missing for all their other GTME projects: an AI-native GTM data layer. We just had to turn on the lights and open it up to all the places GTMEs were already working.

Established teams need to defeat the three bosses of agentic GTM…with a handicap

Today, Upside works primarily with large, established B2B companies. We help them transform their go-to-market data swamp into something AI can use. We find they are drowning in raw data, but typically still feel like they have no answers. In fact, they often can’t even get access to many of the new tools that AI-native startups consider critical, because the compliance team is busy working through how to update their evaluation rubrics for the age of AI.

The good news is these coins flip over to reveal strengths on the other side: years (sometimes decades) of history worth mining, plus the playbooks, the operational discipline, and the customer relationships that startups don’t even realize they’re missing. But if you’re part of a more established organization that is learning to play the new agentic GTM game, you have some work ahead of you.

Here are the three big bosses we see these teams struggle with most often, and the tactics to beat each one. Look carefully, and you’ll notice that all three tie back to the same missing layer: governed GTM context that agents, apps, and humans can use safely and effectively.

Boss 1: The best AI tools aren’t allowed anywhere near your data

After nearly 50 years, the spreadsheet finally has a competitor: general-purpose AI harnesses (Claude, Codex, Cursor) are the new ‘default business tool’.

But not everyone has access yet, because what works at a hot startup (‘everyone gets a license, connect it to whatever you want’) is a non-starter in a Fortune 500 company, where pointing an agent at production data is how you accidentally create an insider-trading problem instead of a productivity gain.

So when the IT team hands people a locked-down, enterprise-approved derivative, the gap between the real thing and the sanctioned version is the difference between ‘game-changing’ and ‘frustrating, unusable trash’.

The fix: don’t accept the ‘pick one’ framing of frontier AI vs. governance, because you can have both. Build the data layer that lets state-of-the-art AI operate safely. If that means a dataset sandboxed inside a safe-by-default shell to enforce security and permissions, so be it. Datasets scoped by role, permissioned hosting for generated apps. Focus on making the environment secure, and if you absolutely cannot get approval for a best-in-class generic AI harness like Claude, Codex, or Cursor, make sure you stay as close to that layer as you can instead of taking the easy, bundled-with-your-office-suite way out.

Boss 2: The quality of your ‘boring data infrastructure’ actually matters a lot

You can point your AI agent directly at Salesforce today. It’ll even dig up some interesting trivia. Unfortunately, a typical enterprise CRM instance is somewhere between a geological record and a garbage dump — much like crude oil, the value is in there but it’s not something you should put directly into your car.

Let’s say you’re trying to run a deal analysis. You’re going to need signals scattered across Salesforce, HubSpot, Gong, and your ad platforms, all overlapping, half-logged, none of it joined. If you — a knowledgeable-on-GTM human — open all those sources in different browser tabs, it’ll take you a couple hours to piece through the unstructured mess, untangle all the overlap, and develop a thesis about what is actually going on in that single account. If you give that same task to a skilled data analyst (but one without your GTM knowledge), they’ll probably be quicker at the mechanics but more likely to miss the forest for the trees about what it all means.

Claude is that data analyst wearing rocket boots. Yes, you can connect it to all of those sources directly (via MCP, or even an intermediate warehouse like Snowflake or BigQuery), but that very much does not take care of the mess. Copilot it through the process carefully and you can do something great once; you’ll start from scratch next time, and so will everyone else on your team.

The fix: materialize the data fabric first, so your agents can understand it intuitively and aren’t reinventing how everything connects in each new session.

• At minimum: document an ontology of how your sources relate and make sure your agent knows about it.

• Better: create a joined data lake on a shared schema.

• Best: treat every upstream system as a source of signal (not a source of truth), and reconstruct a knowledge graph of what actually happened.

Boss 3: Nobody trusts an answer they can’t trace

AI is non-deterministic. Just like with people, you get different answers if you ask the same question twice. But with AI, add in that you’re hiring a fresh intern straight off the street for each new thread, and that means they come with only what they learned in school — they haven’t gone through onboarding for your company yet.

Worse, the quality of AI results still depends on the skill of the human operator in non-obvious ways. Did Jane, the event manager, know to batch fifty deals across subagents so the run didn’t get lazy halfway through? To check meeting transcripts for event attendance, not just the Salesforce campaign? That ‘pipeline’ here means deals past Qualification?

A small, AI-native team improvises around that. A large, more established one can’t afford multiple answers to the same question if they differ in definitionally critical ways.

The fix: architect the system so that individual operator skill can’t become a failure. This means encoding the scaffolding and context engineering that your best operators use to get great results, and then applying it automatically when Jane the event manager asks a basic-sounding question about campaign performance.

• Bad: trust the AI to figure it out. Models get better all the time, plan mode and the ask-user-question tool help a lot, and there have been multiple step-function improvements in intelligence over the past year. But remember the overconfident intern; this is where the bill comes due.

• Better: invest in solid documentation about how the data is structured, with a context layer of ‘anchor assets’ that you keep up to date as onboarding material for each new agent session (skills and agent-specific memory are this category in a trench coat).

• Best: give the agents live, just-in-time coaching (this is how Upside’s Radiant active context layer works). Train a ‘librarian agent’ that they can go to for advice before each query. Set the librarian up with context on how your data works (including shared memories about org-specific nuance), and design a continual learning loop that extracts new entries worth recalling from day-to-day usage. This way, wins compound team wide and no one is starting from scratch.

Bonus: a few tactics and tools that we’ve found help with overall trustworthiness:

1. Make sure you have non-AI audit and traceability tooling, so users can ‘go to ground’ in the data layer when needed. Give them an old-fashioned tabular dashboard with filters and a visual timeline explorer, where they can investigate by hand. For new users, these things can also help with the cold start problem of an empty chat window.

2. When you use AI to generate deep-researched outputs, do it once and store them for queryable reference in future. This is both more consistent and cheaper than running the research on demand every time someone needs the answer.

3. For more subjective, high-complexity questions, use jury-and-judge workflows (for example: a panel of three analyst agents independently run the same investigation, and then a separate evaluator is responsible for verifying their findings and normalizing the final answer).

What happens when you win

If you want to work agentically and are already operating beyond the scale of ‘vibecoders in a Blue Bottle’, you need a GTM data layer. This is the single greatest accelerator your team will find, and you’ll see a Cambrian explosion of creativity once you have it: the person you had filed under ‘average’ starts shipping brilliant things nobody thought to ask for, and everyone gets more data-driven because the data is finally on tap (for examples of what we mean, check out this gallery of miniapps inspired by things we’ve seen actual Upside customers create).

But be careful before you sign up to rebuild the boring infrastructure yourself. This layer does not come out of the box with Claude, and unless you happen to have a spare top-tier engineering team just hanging around, an in-house solution quickly becomes a trap — a constant hope that ‘just one more fix’ will finish the project and finally make things stable. Because it won’t. OpenAI and Anthropic have both published long write-ups of the un-glamorous, non-model work they had to do before their own internal data agents became usable. You wouldn’t build all of Excel just to use a spreadsheet, and your company probably shouldn’t run its own go-to-market context graph either.

That’s why Upside exists. We believe AI makes it possible to ask better questions, run deeper analyses, and build internal tools faster. But that only works if GTM engineers have a clean, normalized data layer that covers every GTM team. We extract the raw signals from everywhere they exist across your systems and transform them into a knowledge graph, the single best source of what actually happened in your accounts. Then we make that data available in all the places and ways you need: a powerful MCP, analytics dashboards for your broader team, and hosted interactive miniapps with live data, all in a way that won’t get you in trouble with your compliance team. We keep the boring part boring so that your team can do the exciting stuff.

We’ve been building in the GTM space for a long time, and this is the most fun we’ve ever had. If you’re already duct-taping this together by hand, you’re ahead of the curve, and you also don’t have to do it alone. The old GTM stack was built for humans updating records. The next one will be built for humans, agents, and apps reasoning over context.

Upside is the AI-native data layer for GTM engineers. Come build the age of agentic GTM with us!

This article was originally published on the Upside blog.

Leave a comment

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