Reminds me of a painful lesson from 2017. I had a Surface Pro laptop, and stored all of my important work and personal files inside. Suddenly, my laptop stopped working and I had to send it for an RMA repair. None of my local documents could be restored.

Luckily I had done an ad-hoc Dropbox sync about 3 months ago, but that meant I lost 3 months of work.

From that day onwards, I only worked on files that were synced to Dropbox. Saved me a few close calls.

Fast forward to today, and this is exactly the same risk I have with Claude Code. All of my workflows, skills, and projects are stored locally on my MacBook Pro. If anything goes wrong with the machine and the data can’t be accessed, I’d lose months of work.

Claude Code Backups via GitHub

That's where I started backing up my Claude Code work to GitHub.

Here’s how it works

1. Tell Claude Code which folders need to be synced and which folders to ignore

2. Be careful not to push any secrets or API keys

3. Connect Claude Code to GitHub.

4. Create a private repo

5. Set up a daily push automation using macOS’s native scheduler, “launchd”. I didn’t even know this existed before, which pushes to GitHub 12am daily.

6. GitHub takes care of versioning. You can always roll back or restore later.

Why this matters now?

Feels like with the recent npm supply-chain attacks (e.g. the TanStack incident: https://openai.com/index/our-response-to-the-tanstack-npm-supply-chain-attack/), having the ability to roll back your Claude Code setup becomes more even more important.

Versioning isn’t just for losing your laptop in my opinion, but it’s for the day a dependency, a NPM packaging or an MCP server gets compromised and you need to revert to a previously good state.

PS: I’m not SWE trained, so I’m very curious to know. Is this actually best practice, or is there a better way to do this? Would love to learn how others are handling it!

The first thing I need before I can build anything is a complete list of the API endpoints that the SaaS tool exposes.

Why? 2 important reasons.

1. Execution. I have an automation or an agentic workflow in mind, and the endpoint inventory tells me whether it's actually feasible within the vendor's constraints. If it is, I can also see in advance where I'll need to work around endpoint restrictions instead of running into them mid-build.

2. Ideation. This is where I treat the LLM as a second brain. I give it the full list of API endpoints plus context on what I'm trying to achieve, and we brainstorm back and forth on what's potentially worth building. The LLM is good at lateral ideas that I wouldn't have made on my own.

Different types of API discovery

Layer 1: MCP + Web Scrape (Least Efficient)

The fastest way to get an endpoint list is to call the tool’s MCP server directly and ask it to return all the exposed endpoints. It’s quick, it’s efficient, and they’re already surfaced in my Claude Code context, so I can just call them.

The downside is that some MCP servers don’t expose the full API. There’s a real gap between what’s in the tool’s public API docs and what’s exposed through the MCP.

For some third-party SaaS tools, their MCP only gives me 60-70% of what the underlying REST API can actually do.

When the MCP isn’t enough, I usually have to fall back to scraping the tool’s API docs site. It’s slow, it’s inconsistent, and JavaScript-rendered pages make extraction very unreliable.

Case study: Apollo

• MCP covers 24% of Apollo's public REST API

• No llms.txt or OpenAPI.json (which I’d cover more below)

• API data parsed from https://docs.apollo.io/sitemap.xml

Layer 2: llms.txt

llms.txt is a newer convention (proposed in 2024) where companies publish a markdown index of their website content, formatted specifically for LLMs and AI agents to navigate.

It’s not made for documenting API end points specific. It’s more of a site-wide directory of linked pages, organized by category, with a one-liner for each. Examples include product docs, guides, reference material, blog posts & more.

The reason I check it for API discovery: llms.txt is often where the OpenAPI spec link is buried. The endpoints themselves aren’t in llms.txt, but the breadcrumb to the file that contains them often is.

Case study: Instantly

With Instantly, I checked https://developer.instantly.ai/llms.txt.

It’s an index of their docs built for LLMs, and one of the links inside pointed to their OpenAPI spec (which I’ll cover more below) at https://api.instantly.ai/openapi/api_v2.json. That file had every endpoint Instantly exposes.

If I’d stopped at the MCP, I would have missed all of them.

Layer 3: OpenAPI.json (Most Efficent)

The OpenAPI spec is a single machine-readable file (JSON or YAML) that describes every endpoint of a REST API in one place. Paths, parameters, request bodies, response shapes, auth methods. All of it, in one structured file.

This is the gold standard for API discovery for two reasons.

1. Completeness. The spec is the API. It’s not a curated subset like the MCP, and it’s not a doc page that might be out of date. If an endpoint exists in the spec, it exists in the API.

2. Accuracy. Mmost modern SaaS auto-generates this file directly from their API code. It stays in sync with reality without anyone manually updating it. Whatever I read in the spec is what the API actually does today.

The catch is that there’s no single conventional path where the spec lives.

Additional notes:

• When verifying an OpenAPI spec, use a deterministic script (Python or shell) instead of asking the LLM to WebFetch the URL. The script downloads the full spec to a temp file and counts how many endpoint paths are in it.

• WebFetch is non-deterministic. The LLM might miscount, skip sections, or summarize away detail.

• General pattern: when the task is structured data extraction (counting, listing, filtering JSON), use a script. Save the LLM for tasks that actually need reasoning.

Case study: DiscoLike

DiscoLike was the cleanest version of this.

The OpenAPI spec lives at https://api.discolike.com/v1/openapi.json, which is the conventional path. The DiscoLike MCP exposes 29 tools.

The spec shows 9 more more user-facing data endpoints that aren’t in the MCP (corporate hierarchies, vendor relationships, SSL cert history & others).

Save API endpoints once, reference them on demand

Once I have the endpoint inventory for a tool, I save it locally so I’m not re-pulling them from the source every time I want to reference it.

Just a word of caustion though. Don’t dump all of your API endpoints in your CLAUDE.md file.

CLAUDE.md is always-loaded context, so dumping 130+ Emailbison endpoints plus 60 DiscoLike endpoints plus 200+ Instantly endpoints in there burns through my context budget on every conversation, even when the work has nothing to do with those tools.

Instead, save each tool to its own file under .claude/mcp-end-points/. One file per tool. CLAUDE.md just has a one-line bullet pointing to each reference and they stay out of the context window until I tell Claude to read them.

Each reference file has two sections:

1. The endpoint catalog

2. Run learnings from actual usage which usually include rate limits, validation quirks, parameter naming traps. These are added in on demand.

Updating API endpoints via a hook

A point to note, APIs aren’t static. Your Saas tools could add new endpoints, deprecate old ones, or change parameter names. The reference file I saved last month isn’t guaranteed to reflect what the API does today.

The way I handle this is to create a Claude Code hook that points back to the tool’s OpenAPI spec URL. Once a month, it re-pulls the spec, regenerates the endpoint catalog section, and overwrites the file.

Composio is another option I want to test.

From my understanding of what they do. they maintain integrations for a lot of the major tools and handle the API updates on their side, so the refresh happens upstream rather than in my own setup. Haven’t tried it yet, but if it works the way I think it does, it removes the hook maintenance entirely.

After all, no matter how good your targeting, copy, or offer is, none of it matters if your emails aren’t landing in your prospect’s main inbox.

Email Gatekeepers

The 3 main email gatekeepers I’ve seen are:

• Proofpoint

• Barracuda

• Mimecast

Think of them as literal gatekeepers. They sit between your cold email and your prospect, scan the email, cross-reference your domain and copy against a huge database of blocked domains and known cold email patterns, and decide whether or not your email should be delivered.

If not, your email gets blocked.

You’d typically see these email security softwares deployed in:

• Larger enterprise companies / FT 1000 companies

• Govt organizations

• Legal organizations

How do you even know if a prospect is behind one of these? You can do a quick MX record lookup on tools like MXToolbox, or you can enrich it through Clay. Worth doing before you send if you’re going after enterprise prospects.

Mimecast (Backstory + What’s Happening)

Lately I’ve been seeing more and more of my prospects using Mimecast. And out of the 3 main gatekeepers, this one has been the trickiest to crack.

I ran a small controlled test using my company’s main domain to do high-touch 1:1 outreach to a batch of Mimecast-protected prospects. All of them got blocked. Meanwhile, the same kind of outreach was landing fine with Proofpoint and Barracuda prospects.

A couple of hypotheses I had in mind:

• My company’s main domain (along with other established aged domains) has probably been fingerprinted by Mimecast. This isn’t unique to us as any established business running a real PLG or SLG motion is sending millions of emails monthly across product, marketing, sales, and transactional flows. At that scale, every major email security provider will eventually have enough signal on your domain to fingerprint it. We are not spamming people, but it’s just the reality of operating at volume.

• Copy issue. The email copy might be considered too promotional for Mimecast’s liking.

The interesting thing is that the same copy from my company’s main domain was getting delivered fine to Proofpoint and Barracuda prospects.

Which tells me Mimecast is doing something different. Most likely stricter content scanning, heavier weighting on sender reputation history, and more conservative defaults compared to the other two.

What Worked for Mimecast Delivery?

#1: Non Promotional, Short Copy

I tested emailing the same Mimecast prospect using my company’s main domain with extremely short copy (under 7 words).

The email was delivered successfully and I got a reply.

My theory on why this works: Mimecast’s content scanning likely flags promotional language patterns, CTAs, links, and structural signals like multi-paragraph format and signatures. Ultra-short copy bypasses most of these triggers as there’s just nothing for the scanner to flag against.

#2: Secondary New Domains

Using newer secondary domains (not your company’s main domain) to do cold outreach seems to help too. Even with the promotional cold outreach copy.

All the Mimecast prospects got delivered successfully.

My guess is that the email security providers don’t have much sending history on these newer secondary domains yet, so there’s nothing to fingerprint against.

Main Takeaways

Contrary to the general consensus, emailing prospects from your company’s main domain might not necessarily see an uplift, especially with prospects using email security gateways.

For Mimecast specifically, consider using:

• Extremely short email copy (< 7 words)

• Secondary newer domains that don’t have much sending history

A few open questions I’m still testing:

• Does the short copy trick still work at scale?

• How long before secondary domains accumulate enough history to get fingerprinted too?

• Is there a copy structure that gets the best of both worlds. Preferably long enough to actually pitch something, short enough to dodge Mimecast’s scanner?

Will share more as I run more tests.

But what does a GTM engineer actually do?

I think the best way to answer this is to strip away all the technical and tactical competencies a GTM engineer is supposed to have, and go straight to the business impact they’re hired to deliver.

For 99% of GTM engineers out there, the role only exists in sales-driven B2B organizations, IE companies selling to other companies, not consumers.

And inside those companies, the role tends to live in one of two places: under Marketing, or under RevOps. In my opinion, where it sits changes what the job actually is.

From my observation, this split is most obvious in larger organizations where there's a standalone RevOps department. The GTM engineer role gets kinda blurry in smaller companies where there's usually no dedicated RevOps team, or even a single RevOps hire.

In those companies, you'll see one GTM engineer wearing both hats: handling the marketing and the revenue operations tasks at the same time.

GTM Engineer (Marketing) VS GTM Engineer (RevOps)

There’s 2 types of GTM engineers.

GTM Engineer (Marketing)

Attached to the marketing department

• Sits inside the marketing department

• Main goal: to drive net-new market expansion, bringing more new customers into the SLG pipeline

• Owns the systems that generate, qualify, and route demand at the top of the funnel

GTM Engineer (RevOps)

• Sits inside the revenue operations department

• Main goal: to drive sales enablement, making the existing sales motion faster and more efficient

• Two main levers they work on:

  • Sales velocity → how to move deals through the pipeline faster

  • Conversion → how to turn more leads into closed-won, faster

Use Cases: GTM Engineer (Marketing)

Outbound

This is probably the most common use case of a GTM engineer in Marketing. These roles were pioneered (I think) in companies like Ramp, Gong, and Rippling, where outbound forms a huge % of their net-new pipeline.

The core essence of cold outreach is to use different channels (email, LinkedIn, etc.) to reach net-new accounts that aren’t in your CRM yet. The intention is to turn a cold prospect into a booked-demo opportunity.

Where the GTM engineer comes in is building the tools that help find, qualify, and reach the right accounts at scale:

• Signal-based prospect sourcing by building prospect + company lists from real-time triggers like job changes, funding rounds, hiring activity, podcast or webinar launches, and tech stack adoption. For example, outreaching to a SaaS company that just launched a weekly webinar series.

• AI-powered personalization at scale by using LLMs to generate first-line openers, custom value props, or full email bodies based on the prospect’s recent activity (a podcast episode, a job posting, a LinkedIn post).

• Multi-channel orchestration (increasingly important) sequencing email + LinkedIn across tools like Instantly, Smartlead, or HeyReach.

The GTM engineer also owns the deliverability infrastructure underneath such as domain warming, inbox rotation, inbox placement tests, and so on.

PLG Activation & Expansion

This one’s more specific to my work as a GTM Engineer at Riverside. Riverside runs both a PLG motion and an SLG motion - meaning we have self-serve users on our lower-tier plans, and we also have larger B2B customers on our Business plan.

The core essence here is that companies like Riverside, with an existing PLG motion, have an opportunity that pure SLG companies don’t: converting existing paying self-serve customers into Business-plan opportunities. The intention is to catch the moment (via signals) when a current self-serve customer qualifies for that conversation.

Where the GTM engineer comes in is building the system that watches for those signals and routes them to the right place:

• External signal monitoring for changes in the company’s world that make a current paying user suitable for an upsell conversation. A self-serve user gets promoted to Head of Marketing. Their company raises a Series B. They start hiring a content team. They launch a podcast or webinar program.

• Automatic routing the moment a signal fires. Any of the above can qualify an existing self-serve customer for the Business plan and the GTM engineer builds the system that catches those signals and pushes the account into an outbound sequencer (or to an AE) the moment they fire.

Use Cases: GTM Engineer (RevOps)

AI-Assisted Rep Enablement

The whole idea behind AI-assisted rep enablement is figuring out how to take low-leverage, time-consuming manual work off each BDR or AE’s plate so they can spend more time actually selling. These enablements can range from very simple tools to highly complex ones.

• Slack prospect number generator. Historically, finding a prospect's phone number is a manual process. The rep logs into one data provider, then another, then another, hoping one of them has a verified number. With AI, this becomes a single Slack command: the rep pings the bot with a name and company, the request gets pushed into Clay, Clay runs an API waterfall across two or three providers, and the verified number comes back into Slack within seconds.

• AI-assisted call prep through auto-generating 1-page account briefs that surface recent company news, the prospect’s LinkedIn activity, prior CRM touchpoints, and (if it’s a PLG motion) product usage data, all synced to the account’s CRM before the meeting.

• Buying signal alerts in CRM + Slack, when a target account raises funding, hires a key role, visits the pricing page three times in a week, or hits a usage threshold, the rep gets a real-time notification with context and a recommended next action.

• Call intelligence feeding back into the sales motion. Pulling sales call transcripts from Gong (or Chorus, Fathom, etc.) and surfacing patterns across them such as common objections, winning phrases, recurring prospect pains. Then feeding those insights back to the AE and broader BDR team where the objections get addressed up front in the next round of calls, winning phrases get used more, and prospect pains become more apparent when reps are selling.

Lead Routing & Qualification

Making sure every inbound lead gets enriched, scored, and routed to the right rep. The GTM engineer builds the system that turns raw form submissions into pipeline-ready opportunities:

• Enrichment on entry. Every lead gets enriched the moment it enters in the CRM with email mapped to company, firmographics + technographics layered and ICP fit score calculated.

• Behavioral + ICP scoring that combines static fit (company size, industry, geography) with dynamic engagement signals (pages viewed, content downloaded, demo watched, pricing page visits) to separate “warm” from “lukewarm” automatically.

Worth Reading: The State of GTM Engineering (2026)

If you want to go deeper, the guys at GTM Cafe just put out the first benchmark report on GTM engineering, covering compensation, tooling, org design, and commentary from 225+ GTM engineers worldwide. It’s a really good read, and probably the best attempt yet at demystifying what this role actually looks like across companies.

Definitely worth checking out.

But once you start building outbound prospecting infrastructure on top of it such as agents and automated enrichment pipelines, you start hitting limitations that aren't so obvious.

Here are three I've run into that’s worth sharing, with the workarounds I ended up building.

#1: Apollo's prospect keyword search is extremely shallow

If you want to find prospects whose work involves “webinars,” Apollo will only return people with the literal word “webinar” in their job title.

That’s a tiny fraction of the people who actually run webinars. Most of them have titles like “Demand Gen Manager,” “Content Marketing Lead,” or “Field Marketing Director” and the webinar work shows up in their headline, About section, or job experience, not the title.

Compare this to vendors that have indexed the full LinkedIn profile such as Crustdata, MixRank, AI-Ark where you can keyword-search across:

• Job title

• Headline

• About section

• Job experience descriptions

• Education

• Skills

Skills searches are super underrated. If your ICP is defined by software proficiency or certifications such as L&D buyers running Docebo, Articulate, or Absorb LMS - Apollo can't find them.

You have to fall back to firmographics + title and accept that most of your list will be off-ICP.

#2: Apollo's API/MCP doesn't expose all the filters its own UI has

Example: I want to find marketing leaders who changed jobs in the last 90 days.

In the Apollo UI, “changed job in last X months” is a one-click filter.

In the API and MCP, it’s not exposed at all (this is really strange and frustrating).

The workaround is not ideal at all. You have to

1. Pull all marketing leaders matching your firmographics

2. Enrich each person individually

3. Read each person’s employment_history arrary

4. Calculate the start date of their current role

5. Filter to the ones who started in the last 90 days

Not only is it slow, it’s a real waste of LLM tokens and Apollo credits.

#3: Apollo’s “verified” emails have a 7.5% real-world failure rate

Apollo returns two types of email for your prospects:

• Verified: Apollo claims they’ve confirmed deliverability via SMTP

• Extrapolated: Apollo guessed it from a pattern (first.last@domain.com)

When you’re calling Apollo through the API or MCP, this distinction isn’t surfaced clearly. Both come back flagged as “sendable.” So if you’re piping Apollo’s output straight into your sequencer, you’re treating guesses and verified emails the same way.

The bigger problem is that even the “verified” emails fail at a meaningful rate.

I ran a re-verification pass on one of my recent batches using MillionVerifier (standard SMTP) followed by BlitzAPI (catchall domain handling), on emails Apollo had already flagged as sendable. Here’s what came back:

7.5% of “sendable” emails failed external verification. If you send these straight into a campaign, that is going to be your bounce rate floor, which is not acceptable at all.

Practical takeaway: if you're running cold outbound at any volume, don't trust Apollo's "sendable" flag as your final filter. Add a second verification layer (MillionVerifier or equivalent) and a catchall handler (BlitzAPI or similar). It's not optional as that’s going to be the difference between a 7.5% bounce rate and something deliverability-safe.

Closing thoughts

Honestly, my answer is to stack a second data vendor on top. Crustdata/AI-Ark/Mixrank for keyword depth and job-change detection. MillionVerifier + BlitzAPI for email validation.

What surprises me is that Apollo hasn't closed these gaps yet. I'm hoping they catch up. Apollo at this price point with full-profile keyword search, complete API filter parity, and trustworthy email verification would be a hard product to beat.

Until then, the answer is to stack a secondary data vendor.

It’s quite disruptive and not really ideal.

The fix is actually quite simple. I aligned my workday to Claude’s session windows + configured a simple Claude Routine.

The “Say Hello” routine

I set up a scheduled routine that pings Claude Code with a simple “hello” at 3 fixed times every day.

Each ping kicks off a fresh 5-hour session window.

Trigger times:

• 9:30am, starts session 1

• 6:30pm, starts session 3

• 7:30pm, backup ping in case 6:30pm didn’t ping in a fresh session

Combined with a manual session I start late at night, this gives me 4 usable Claude sessions per workday.

Note: For Claude Routines to trigger, you must not be usage limited during your current session.

Cron Expression: 30 1,10,11 * * *

My typical workday, mapped to sessions

• 9:30am: Routine triggers session 1

• 12:00pm: Work starts and I start using Claude in session 1

• 2:30pm: End of session 1, I manually start session 2

• 6:00pm: Dinner break (session 2 still running)

• 6:30pm + 7:30pm: End of session 2, routine triggers session 3

• 12:30am: End of session 3, I manually start session 4 for late-night agent runs (if any)

The 9:30am ping is the one that matters most. Especially when I’m busy with sending my kids to school.

6:30pm + 7:30pm ping is the next one. It kicks in while I'm having dinner with the family.

How to Setup Claude Routines

Claude Routines are scheduled prompts that work automatically at times you set, basically a cron job for Claude.

Here’s how to set one up:

1. Open the Claude desktop app

2. Navigate to Code tab

3. Click on Routines

4. Select Remote (not Local)

5. Write your routine instructions (mine is literally just “say hello”)

6. Hit Save

Quick note on Remote vs Local: Local routines need your laptop (or a VPS) running 24/7 for the routine to fire. Remote runs on Claude’s cloud infrastructure, so it’ll trigger whether your laptop is on or off.

For custom trigger times, the scheduling field is a cron expression. If you don’t know cron syntax (I don’t), just ask Claude Code to generate the expression for you and paste it into the scheduling section.

For reference, here’s what my three triggers look like:

• 30 1 * * * → 9:30am SGT

• 30 10 * * * → 6:30pm SGT

• 30 11 * * * → 7:30pm SGT

Final Thoughts

I'm sure there are better ways of doing this. Pushing Claude Code CLI onto a VPS, using Trigger.dev, OpenClaw I haven't looked into yet. But at this moment this works for me the best.

Will probably change as I get more advanced with agentic workflows!

Which can be rather expensive especially when the actions add up.

I’ll admit I’ve been migrating out of Clay too for some of the workflows I’ve been building. But not all of them. Specifically, not the ones that touch HubSpot.

Here’s why.

Where HubSpot fits in my GTM workflows

Two things I use HubSpot for:

1. Net-new checks. Before reaching out to a company, I want to know:

→ Is the company already in our CRM?

→ If yes, has there been any BD or AE activity within the last X months?

→ Are they an existing customer?

This tells me whether the company is safe to put into my outbound motion.

2. Writing company + prospect data into the CRM.

Once a prospect is in outbound, the company and contact records get written into HubSpot, along with the right tags and properties that trigger downstream HubSpot workflows.

Both workflows touch HubSpot but only one needs write access.

Why I don’t give Claude Code write access to HubSpot

If you’re running Claude Code at scale (I don’t mean outbound for 10 or 20 companies, I mean over 1,000 companies) hallucinations become very noticeable. This is even with guardrails.

I’ve had Claude Code hallucinate URLs in agentic workflows (using fake URLs that but didn’t exist). For a research step, that could be somewhat liveable.

For a CRM write, it’s not. You’re not sure of the data integrity, and once bad data is in the CRM, it triggers downstream workflows that weren’t supposed to fire.

Take a look at this hallucination example below.

Then there’s the other risk: API keys.

The Axios npm package (~100M weekly downloads) was compromised on March 31, 2026. Two malicious versions were published using the lead maintainer’s hijacked npm account, injecting a fake dependency that dropped a cross-platform RAT on macOS, Windows, and Linux (CSA Singapore advisory).

Even though the exposure window was only ~3 hours, but anyone who ran npm install in that window had to assume every credential on the machine was compromised. If your Claude Code agent has a HubSpot API key sitting in an .env file or a config somewhere, it’s now part of the attack surface for any supply chain compromise of any package the agent uses.

This scares me. Honestly with all the npm packages that I’m using within Claude Code, it feels like it’s a matter of time before one such package gets compromised.

So that’s why I am mitigating my downside. For any service that’s mission-critical, I don’t give Claude Code write access. Only Read-only access.

My approach: a two-prong workflow

I split my GTM workflows into agentic work (via Claude Code) and deterministic work (via Clay).

Claude Code → Push to Clay webhook → Clay writes to CRM

Here’s a recent example for webinar prospecting:

Claude Code (agentic side):

→ Finds companies and people organizing webinars

→ Filters by HubSpot net-new (read-only access)

→ Filters them according to my ICP rules

→ Enriches relevant prospects using Apollo.io

→ Crafts an opening line and body paragraph contextualized to the prospect’s job title and role

→ Pushes to Instantly

→ Pushes to a Clay webhook

Clay (deterministic side):

→ Writes the prospect and company into HubSpot

→ Adds the right notes for the AE to action

Claude Code does the messy, judgment-heavy work upstream. Clay handles the deterministic CRM writes downstream. The HubSpot API key never touches the agentic side of the pipeline.

The takeaway

Deterministic workflows running in tight, contained environments with scoped credentials are structurally safer than agentic workflows holding long-lived API keys with write access to your CRM.

This isn’t a Claude Code problem. Claude Code is doing exactly what it’s supposed to. It’s an architectural choice about where you draw the line between agentic and deterministic — and for me, that line runs right at the CRM.

They trigger workflows and lets you reach prospects in their current state of mind (be its inbound or outbound).

Signals: Quick Recap

Broadly speaking, there are two types of signals.

External / 3rd party: anything happening outside your own product:

• Social signals (LinkedIn posts, founder activity, exec moves)

• Job signals (open roles, hiring spikes, title changes)

• Technographic signals (stack adds and drops)

• Funding signals (rounds, M&A, IPO filings)

• Event signals (webinars, conferences, speaker lists)

• Aggregation signals (G2 reviews, Crunchbase changes, directory listings)

• & many more

Internal / 1st party: anything happening inside your own ecosystem:

• Website activity

• Product usage

• CRM and marketing engagement

• & many more

Two ways to get them: buy them from data vendors, or scrape them yourself.

This article is about the second option and specifically about the bottleneck most people hit when they try to scale it.

Why Scraping Breaks at Scale

When you’re using an LLM to extract data from rendered HTML, every single page is costing you:

• 5-10 seconds in a headless browser

• 50-100KB of HTML pushed into the context window

• Maybe 200 bytes of that is data you actually need

• One CSS class change away from breaking entirely

That’s around 99% wastage per page. And it’s super slow too.

Compound that across 200-300 companies you want to qualify in a week, the workflow becomes too slow and too expensive to be worth running on a schedule.

Introducing Network Logs

Network logs are the record of every HTTP request a web page makes when it loads. You can see them in any browser by opening DevTools → Network tab.

From analyzing the network logs of a site, you’re typically looking for two things:

1. Public-ish API endpoints. Endpoints the company uses for their own internal purposes (typically to populate their own front-end), but are still accessible to the public without authentication.

2. Direct JSON calls. Calls where the important data you’d otherwise be scraping from the rendered page has already been passed back as structured JSON.

How to Find Network Logs

• Right-click on the page → Inspect.

• Go to the Network tab.

• Reload, paginate, scroll. Whatever triggers the data you want to load.

• Right-click anywhere in the request list → Save all as HAR.

Upload the HAR file into Claude. Ask it to find the request where the API or structured JSON data lives.

Eventbrite Example

As a GTM engineer at Riverside, one of my main responsibilities is breaking into the webinar market. A lot of companies in our ICP run webinars regularly, so I needed a way to surface them at scale.

I started with Eventbrite. It’s one of the biggest event aggregators out there, and a lot of webinar organizers list their events on it.

I tried the network logs approach on it.

963 unique online webinar events from Eventbrite in about 12 seconds across all 49 pages. All neatly structured into the columns I actually needed (event name, start/end dates, timezone, organizer ID, event URL, language, etc).

963 unique online webinar events from Eventbrite in about 12 seconds across all 49 pages. All neatly structured into the columns I actually needed (event name, start/end dates, timezone, organizer ID, event URL, language, etc).

Doing this with LLM scraping would have taken hours to troubleshoot and probably burned through a chunk of tokens. With the network logs approach, it was a HAR file upload, a Claude prompt, and a quick fetcher script.

Amplification

LLM scraping is slow because every page has to render in a headless browser. It’s expensive because every page gets fed into the context window. Two costs you can’t really escape.

Network logs cuts both at once w/o a need for website rending and LLM extraction. Your time-to-production drops significantly, and your token costs drops with it too.

For a GTM engineer, I think that’s the biggest unlock as it amplifies your output.

And I kept hitting the same recurring problem: Why is my token consumption so high?

A simple Apollo.io MCP call where I was just:

• Running a people search

• Pulling their job titles

• Enriching the contact to find their emails

• Letting the downstream LLM decide if the title was a good fit for outreach

Would easily eat 7-10% of my session limits in a single go.

MCP = Major Context Problem

My instinct kicked in and I’m guessing that there’s a ton of stuff getting pushed into Claude that I don’t actually need.

And I was correct! Take a look at the results above.

With the Apollo.io MCP, when I’m running a people search + enrichment, it dumps the full response of that tool call into the context window. Most of it isn’t needed.

Each enriched Apollo response is 20-30KB per person. Maybe 100-200 bytes of it is actually useful.

That’s around 99% wastage added to the context window per profile.

When you stack that across 200-300 profiles in a single workflow run, and the context window bloats up massively.

How MCP actually works under the hood:

• When you call an MCP tool, the server returns a JSON response. That entire response gets injected into the context window. Your Claude Code gets charged tokens on every field, even ones that is not relevant to your workflow

• Some MCP tools accept a fields / select / filter parameter but it’s very rare. That could help in requesting fewer fields which shrinks the response down.

A quick example of the waste

Here’s what I needed for my workflow:

{
  "name": "Jane Doe",
  "title": "VP of Marketing",
  "email": "jane@company.com"
}

Here’s what Apollo’s MCP actually returned per profile which gets pushed into the context window:

{
  "person": {
    "id": "...", "first_name": "...", "last_name": "...", "name": "...",
    "linkedin_url": "...", "title": "...", "photo_url": "...",
    "twitter_url": null, "github_url": null, "facebook_url": null,
    "extrapolated_email_confidence": null, "headline": "...",
    "email": "...", "email_status": "verified",

    "employment_history": [
      // 6 full entries, each with 18 fields like _id, created_at,
      // updated_at, degree, kind, major, grade_level, raw_address...
      // mostly null. Every single one.
    ],

    "contact": {
      // a near-duplicate of the person object, plus:
      // hubspot_vid, hubspot_company_id, salesforce_id, salesforce_lead_id,
      // salesforce_contact_id, salesforce_account_id, crm_owner_id,
      // emailer_campaign_ids, has_pending_email_arcgate_request,
      // email_needs_tickling, queued_for_crm_push, godmode_apollo_creator,
      // existence_level, label_ids, source_display_name, contact_emails: [...],
      // phone_numbers: [...], typed_custom_fields, custom_field_errors...
    },

    "organization": {
      "id": "...", "name": "...", "website_url": "...", "linkedin_url": "...",
      "twitter_url": "...", "facebook_url": "...", "alexa_ranking": 3514,
      "founded_year": 2015, "logo_url": "...", "primary_domain": "...",
      "sic_codes": ["7375"], "naics_codes": ["54161"],
      "industry": "...", "industries": [...], "secondary_industries": [],
      "industry_tag_id": "...", "industry_tag_hash": { ... },

      "keywords": [
        // 156 strings. Every single keyword Apollo has ever associated
        // with the company. "sales engagement", "lead generation",
        // "predictive analytics", "lead scoring"... 156 of them.
      ],

      "technology_names": [ /* 92 strings */ ],
      "current_technologies": [
        // The same 92 technologies AGAIN, this time as objects with
        // uid, name, category. So tech stack ships twice in the same response.
      ],

      "funding_events": [
        // 6 funding rounds with full investor lists, news URLs, currencies
      ],

      "annual_revenue": 150000000.0, "annual_revenue_printed": "150M",
      "organization_revenue": 150000000.0, "organization_revenue_printed": "150M",
      // (yes, revenue ships 4 times across 4 fields)

      "org_chart_root_people_ids": [...], "org_chart_sector": "...",
      "org_chart_removed": false, "org_chart_show_department_filter": true,
      "organization_headcount_six_month_growth": 0.0656...,
      "organization_headcount_twelve_month_growth": 0.197...,
      "organization_headcount_twenty_four_month_growth": 0.275...,
      "snippets_loaded": true, "retail_location_count": 0,
      "suborganizations": [...], "num_suborganizations": 1,
      "short_description": "...500 word company bio..."
    },

    "intent_strength": null, "show_intent": false,
    "email_domain_catchall": false,
    "departments": [...], "subdepartments": [...],
    "functions": [...], "seniority": "..."
  },
  "request_id": -8584845490661980443
}

The full response was just under 30KB. I needed roughly 100 bytes of it.

That’s a ~99.6% waste ratio per profile.

Here are the datasets that resulted in this context bloat:

1. The duplicated contact object: most of the person data ships twice, plus a pile of CRM IDs (HubSpot, Salesforce) that only matter if you’re syncing back into a CRM.

2. 156 company keywords as a flat string list: useful for Apollo’s own search but useless to my workflow.

3. Tech stack shipped twice: once as technology_names (92 strings), once as current_technologies (92 objects with uid/name/category).

4. employment_history: 6 jobs back, each with 18 fields, most of them null.

5. Funding history: 6 rounds with full investor names and news URLs.

None of that helps a “is this the right title for outreach” decision.

Multiply that by hundreds of profiles. You can see where the token consumption goes.

So… are API calls just better?

Technically, yes. But with caveats.

Downside #1: discovery

Using direct API calls means you (or Claude Code) need to know which endpoints actually exist.

Some APIs are massive libraries (Cloudflare’s docs at https://developers.cloudflare.com/api/ are a good example). You have to figure out a way to push all those endpoint definitions into Claude, which can take time.

Downside #2: API key security

Most MCP tools use OAuth, which I personally find more secure than juggling API keys. Keys can leak. Keys end up in plain text in scripts. OAuth flows are generally tighter and easier to revoke.

Downside #3: Workflow maintenance

If the tool provider ever changes their API end points, your script breaks. With MCP, it takes that maintenance effort for you.

Your custom script does not. The example I used: if a vendor renames org_id to organization_id between March and June, and your workflow silently breaks until you notice.

MCP + API: best of both worlds

The best of both worlds? My recommendation is to use both.

Use the MCP to discover and prototype the endpoints. Then get Claude Code to write a Python script that hits those endpoints directly, pulling only the fields you actually need. Push that script as your deployed agentic workflow.

MCP → quick and easy setup. Perfect for prototyping, idea validation, and go-to-market hacks.

API → for deployment at scale, where cost-per-run, consistency, and predictable scaling matter.

You get MCP’s speed during exploration, and the API’s efficiency once you know what you’re actually building.

MCP for Day 1. API for Day 100.

If I’m still figuring out whether a workflow is even worth automating, MCP wins because the setup time is near zero. The token waste is annoying but acceptable.

The moment the workflow proves itself, that’s where the equation reverses and token waste compounds. A workflow that runs 500 times a week burns through credits fast if every call is dragging 90% noise into the context window.

That’s when it’s worth the time to rewrite it as a script that hits the API directly, returns only what you need, and runs on a fraction of the tokens.

It’s a 2 week course that goes through how to use AI with GTM motions inside Clay.

Here are 8 things I learnt that will be impactful in my future GTM workflows.

#1: Setting Variables Upfront for AI Steps

Problem:

If you’ve been doing AI enrichment in Clay, the previous workflow was to use Clay variables directly in the prompt itself.

The issue: when you’re going back and forth between Clay and Claude to find the optimal prompt, each time you swap you have to manually reconfigure the Clay variables. Brutally painful and not efficient.

Why this is better:

The new method lets you define variables upfront by assigning variable names (IE $OpeningLineClassification) and then referencing the variable names in the prompt instead of the raw Clay variables.

I can now swap the freely while keeping the variable mapping stays intact.

#2: Configuring Claygent Outside of Clay Tables

Problem:

When you’re doing it inside your Clay tables, adding dummy data is almost close to impossible if you’re working with live data. Especially true when you’re trying to configure for edge cases (you have no idea how much time I spent bouncing between Claude Code and Claygent just debugging).

Why this is better:

You can finally configure Claygent outside your Clay tables. It allows me to test, break, iterate, all without polluting your live rows.

Especially for edge cases.

#3: Clay Navigator

Didn’t even know this existed before the cohort. It’s an interesting option that you can enable within Clay.

Where normal Claygent reads a page, Navigator actually interacts with it. It can fill in search forms, click buttons, toggle filters, paginate, and scroll. Clay’s version of an agentic browser, inspired by OpenAI’s Operator.

• Human-style navigation: clicks, form fills, filter toggles, pagination, and scrolling.

• Research you can replay: every run includes a step-by-step Claygent Replay so you can see exactly what Navigator clicked, filled, and checked along the way.

• Works across formats: pages, tables, PDFs, XML/CSV outputs & Navigator strings it together.

I personally don’t see much use case for this in my workflows right now. But definitely something interesting to keep at the back of my mind.

#4: Clay Sculptor, for just about anything

Sculptor is Clay’s AI co-pilot that sits inside the table and lets you talk to your data in plain English. It can reformat records (concatenating fields, standardising formats, stripping emojis and junk), analyse data with visualisations, and even recommend enrichments on the fly.

Technically you don’t have to bounce back and forth an external LLM.

Another trick I picked up: use Sculptor to export outputs as CSV so it’s faster to paste straight into your data providers column. Previously I was pasting the outputs manually, row by row.

Another example of how Clay Sculptor works. It understands the contextual knowledge of the columns. So you can just prompt it within Clay itself.

In this case, I wanted them to split out the last name after considering edge cases.

#5: JSON.stringify()

A super useful command to extract information off an array of data for downstream manipulation.

If you’ve ever had an array that you couldn’t pipe into the next step, or you needed to preserve a nested structure as a string, this is the fix.

#6: Waterfall for Job Openings & News

I only thought that there was an option to use waterfall for email enrichment. Turns out it works for more.

Company Job Openings

Izzy (instructor from Clay) did a neat example. Imagine you’re selling a customer support chat solution. What you can do is:

• Do a job opening waterfall for “customer support” jobs

• Scrape the median salary published for each customer support job

• Multiply median annual salary by the number of customer support jobs

• Use it as your contextual opener, IE how your customer support chat solution could save $X annually

Company News

An option to pull the latest news from the company you’re trying to reach. Easy way to warm up an opener without combing LinkedIn or Google manually.

#7: Conditional Params in Pure Forumla Columns

For your regular non-formula columns, you could always set a condition: only run this column if X is true, or only run if X is false. Pretty standard.

What I didn’t realise is that the same logic works inside pure formula columns. You can drop a formula in there and tell it to only execute when a certain parameter is true or false. So the formula doesn’t even evaluate on rows that don’t meet the condition.

Small unlock, but helps with a cleaner table!

#8: Sandbox Mode

Running experiments on live tables is risky. One bad Claygent run on 2,000 rows and you’ve run through your credits for the day.

Sandbox mode solves this. It spins up a mini version of your table (top 10 rows, capped at 50) that you can freely test against.

A few things worth knowing:

• Credits do consume in sandbox mode

• Outbound actions (exports, webhooks, Write to Other Table) are automatically disabled, so nothing accidentally fires

• You review all changes before publishing them back to the main table

Rough workflow: build in sandbox, test on the sample, review the diff, then publish. Closest thing Clay has to a staging environment.

Closing Thoughts

Big kudos to Izzy and Sayli for keeping the course high energy and engaging throughout. There were tons of live sessions with great speaker profiles, and the course itself was well structured with plenty of examples, including video walkthroughs going through each chapter one by one.

Really enjoyed it. If you're looking to get your foothold in Clay, I'd highly recommend signing up for the AI Skills Cohort.

PS: Sharing the Slack channel below for memory sake!

1. Find job titles with your keyword in them

2. Extract the list

3. Drop it into an outreach sequencer

The logic makes sense. You go after people who directly own what you’re selling, instead of guessing at three or four personas and spraying. Targeted with less waste.

Where keyword-in-job-title search falls apart?

1. Your keyword probably isn’t in their job title. This is true for activity-based keywords like “webinar”. Nobody puts “runs webinars” in their LinkedIn job title usually. They put “Marketing Manager”.

2. Job titles are notoriously vague. “Growth”, “Marketing Ops”, “Demand Gen”, “RevOps” could mean wildly different things at different companies. The same keyword pulls in people with very different scopes of ownership.

3. LLMs don’t save you. Yes, you can ask GPT to spit out 50 related job titles. It’ll miss half of what’s actually out there. Titles are too messy and too locally invented for any model to have full coverage.

Biggest Limitation of Apollo.io

Apollo only scrapes top-level profile data such as job title, current and past companies, location, education.

If your keyword lives anywhere else, Apollo can’t find the person, even if they’re a perfect fit.

Enter AI-Ark

AI-Ark searches the entire prospect bio, not just the headline. That includes:

• Their summary

• Their work history (the actual descriptions, not just company names)

• Their skills

This unlocks signals Apollo simply can’t see. Activity-based keywords finally work with keywords such as “webinar”, “live event”, “community building”, “podcast production”. This is because people write about what they actually do in their bios, even when their title is generic.

Tools-based search is where this really pops. Say you’re targeting L&D professionals. Your keyword list looks something like:

None of those show up in job titles. They show up in skills and work history instead. If you had been using Apollo.io, you would have missed them. AI-Ark catches them.

AI-Ark vs Apollo: same keyword, different results

Let’s take a look at a quick comparision between both

AI-Ark

• Search: “webinars” in prospect summary

• Location: USA

• Total: 11,426

Apollo

• Search: “webinars” in job title

• Location: USA

• Total: 497

That’s roughly a 23x difference in TAM coverage for the exact same ICP.

If you’ve been running Apollo-only prospecting, you’re almost certainly reaching a fraction of your actual market.

A note on noise

Every B2B intelligence tool has noise, and AI-Ark is no exception.

Searching “webinars” in a prospect’s summary won’t only surface people who run webinars. You’ll also pull in people who spoke at one a few years ago, or attended one they liked enough to mention. Neither of those is your buyer.

So there’s still filtering work to do further down the pipe. Usually that means an LLM pass to actually read the bio in context. AI-Ark gives you a much bigger pool to start with. You have to do the qualification downstream.

When you’re building in plan mode, Claude works out the plan first for your approval before doing any actual implementation.

You get a high-level view of what Claude Code is proposing before a single line of code gets written. That means you can audit the architecture, push back on assumptions, tweak the scope, and iterate until it actually matches what you want.

Only then does it build.

But why does this matter?

Subscribe now

Why Plan Mode?

After using Claude Code consistently for the past 2 weeks, two constraints keep showing up:

• Credit consumption (Maybe because I’m on the Pro plan.)

• Time for Claude to complete its tasked work

You’re going to face these two constraints no matter what.

If you’re vibe-building and the output goes in the wrong direction, you don’t just lose time. You burn credits. And then you burn more credits fixing what shouldn’t have been built in the first place.

The biggest surprise (in a good way) for me in plan mode is that Claude Code asks genuinely deep clarifying questions. The kind of questions and insights that honestly didn’t even occur to me when I was planning things out.

Not surface-level stuff, but structural questions that make you rethink what you’re actually trying to build. It really forces you to be precise instead of vague-prompting your way forward.

Actual Example: Building a “GTM-Brain”

As a GTM engineer, I’m very interested in building out my “GTM Brain.”

It’s essentially a system that:

• Stores all of my GTM knowledge

• Continuously ingests new knowledge (Substacks, YouTube, operator threads, etc.)

• Distills that knowledge automatically

• Synthesizes it against what I already know

• Surfaces gaps, blind spots, and opportunities in my line of work

My biggest belief in the post-AI world is this:

Most roles can get from 0 → 90% efficiency by leveraging information that already exists, synthesizing it properly, and applying it to their context.

The key missing gap is the collection and synthesis of this data at scale, which is exactly what I’m trying to build my GTM Brain to solve.

Let’s take this as an example.

One thing I’ve always struggled with is: how do I “download” all the GTM information in my head into Claude Code?

I considered a few approaches. Creating a master file with everything I know. Dumping notes into one giant doc. But it quickly felt too manual and way too time-consuming.

When I used plan mode, Claude Code proposed “Option C,” which I really liked.

Instead of trying to write everything down upfront, it suggested running a structured Q&A / interview to capture my actual expertise. Almost like mapping my brain through conversation. Then combining that with my GTM-brain content to deepen topic coverage.

That to me was a solveable bottleneck.

If you’re building workflows, debugging loops, or thinking through architecture, your brain moves way faster than your finger.

That means you need a proper voice dictation setup.

Subscribe now

Choosing Your Voice Dictation Layer

I researched into what’s out there:

• Wispr Flow (paid)

• Superwhisper (paid)

• Spokenly (free)

My pick? Spokenly.

It runs locally. Sets up in minutes. And most importantly, it costs $0.

Spokenly runs a local LLM model on your machine to convert your voice into text w/o any cloud dependency. I’ve tested it, and the model works very fast too.

And it’s free. Which makes it hard to justify paying a monthly subscription just to transcribe your own voice.

The model I use is Nvidia Parakeet TDT 0.6B v3. Lightweight, responsive, and more than good enough for prompting Claude Code all day.

Once you switch to speaking instead of typing, going back feels super slow.

Why?

With Playwright, you are adding browser capabilities unlocks what standard web fetch can’t handle:
→ JS-heavy websites
→ Multi-page scraping/pagination
→ Screenshots
→ Actions that require being logged in to your own accounts
→ Perform actions on websites (such as clicks, form fills etc)

Subscribe now

Use Case of Playwright: Landing Page Analysis

With Playwright, I can analyze the full funnel of a competitor exactly as a real prospect would experience it.

For example: Landing page
→ Click “Submit” on whitepaper (page 1)
→ Fill qualification form (page 2)
→ Reach scheduling page (page 3)
→ Reach confirmation page (page 4)

Playwright can automatically progress through each step, just like a human user. It clicks buttons, fills forms, waits for the next page to load, and captures the resulting state.

At every stage, it extracts and catalogues the page without requiring me to manually go through the funnel.

Playwright over Puppeteer

When working with headless browsers, there are two dominant options:

• Playwright (maintained by Microsoft)

• Puppeteer (maintained by Google)

I went with Playwright over Puppeteer primarily because it has an official MCP server maintained by Microsoft. Puppeteer’s MCP implementation has been deprecated, which makes Playwright the more reliable choice for long-term use with Claude Code.

Official support also reduces the risk of breakage. Deprecated or unofficial MCP servers may stop working, fall behind browser updates, or introduce unexpected issues. Since my workflows depend on consistent browser automation for landing page analysis and funnel extraction, stability is critical.

Note: Playwright spins up a fresh browser instance each time (think of it like a new incognito window), so you can't use your existing browser sessions.

I think this opens up alot of potential in marketing research and data collection.

Handling Playwright Chrome Auth

The main issue I hit with Playwright was authentication.

By default, Playwright spins up a fresh browser profile every run. Think “new incognito window.” Clean session, zero cookies, zero logins.

That’s great for test isolation. It’s terrible for real-world research.

Because if your workflow needs access to anything behind a login (LinkedIn, ad libraries, SaaS dashboards, analytics tools), you end up re-authenticating constantly. Same sites. Same MFA. Same pain.

Then I saw a simple fix:

Make a copy of your default Chrome profile and point Playwright to that copied profile.

Now Playwright launches with an already-authenticated state. Your cookies, sessions, and stored logins persist across runs. You get the best of both worlds:

• Not touching your real day-to-day Chrome profile

• Keeping a stable “automation” profile with persistent auth

• No repeated logins every time you run a script

Subscribe now

Why GitHub Installation Over NPM Registry?

I went with GitHub as Anthropic maintains the official repo.

The npm command being shared (for example from sources like aitmpl.com) is published and maintained by a 3rd party.

With unofficial 3rd party packages, you don’t really know what’s inside unless you audit everything. It could be clean. It could also include extra scripts, telemetry, modified templates, additional dependencies, or code that reads from your environment.

Claude Code is typically granted broad local access. So in theory, an unofficial package executed via npx can:

• Read and write files

• Access .env variables

• Modify project structure

• Execute scripts during install

If I’m giving something that level of access, I’d rather it come directly from the original maintainer than through an extra distribution layer I don’t control.

Installing Anthropic’s Github Repo

The install itself was straightforward.

I pointed Claude Code directly to Anthropic’s official GitHub repo URL and asked it to install the skill from source.

In practice, it was just:

• Clone the repo

• Copy the skill-creator folder into my local .claude/skills directory

• Restart Claude Code

That’s it.

As someone who’s quite deep into AI x Marketing, this feels non-negotiable at this point.

Wanted to share this 0 → 1 journey openly, mainly as a way to document what I’m learning. If it helps other marketers along the way, even better.

Subscribe now

The 2-Week Struggle: Why I Nearly Gave Up

I’ve actually been exploring Claude Code for the past 2 weeks.

Watching videos, reading guides, bookmarking resources. Just... stuck in tutorial mode because the terminology kept confusing me.

Everyone throws around terms like “agents” and “skills” and “hooks” like they’re self-explanatory. They’re really not. Especially when most guides are written for developers, not marketers.

Things finally clicked for me today. So while it’s still top of my mind, here’s what actually helped me break through the confusion.

#1: Claude Code (the tool itself)

What I thought: Some coding platform where I’d need to learn Python or JavaScript.

What it actually is: A system where you build automation workflows using plain English. You’re technically “writing code,” but it’s just markdown files with instructions.

Reality check: The word “code” puts marketers off. But you’re not becoming a developer, you’re just teaching an AI your marketing processes.

#2: Claude Code CLI

What it looks like: That black terminal window you see developers use. All text, no mouse clicks.

Why it matters: Claude Code runs in the terminal. No fancy interface to click around and just typing commands. Feels old-school and I couldn’t really get the hang of this.

The shift: Think of it like typing an email versus filling out a form. More direct, less fuss.

#3: IDE Integration (Cursor, VS Code, etc.)

What it is: IDE = Integrated Development Environment

What they actually are: Optional visual wrappers that sit on top of Claude Code. They give you:

• File trees you can see and navigate

• Prettier formatting for your markdown files

• Mouse navigation if you prefer that

Common options:

• Cursor - Popular in Claude Code circles

• VS Code - Microsoft’s free editor, highly customizable

• Antigravity - by Google

Day 1/30 - What I Did

Step 1: Found the Best Guide Available

After going through dozens of Claude Code tutorials, I settled on Joshua Schultz’s complete guide. It’s over 10,000 words of solid architectural breakdown.

I’ve read a lot of AI guides over the past year, and most fall into two camps: either too surface-level (just showing you what buttons to click) or too technical (assuming you already know how systems work). Joshua’s guide is different.

It teaches you the “why” behind the architecture. I’m not interested in just copying templates—I want to understand how the system thinks so I can build my own workflows. The guide breaks down the hierarchy (Commands → Agents → Skills → Hooks) in a way that actually makes sense. I finally understood why you’d use a Command versus a Skill, and when an Agent is overkill.

Step 2: Set Up Claude.ai Project as My Learning Copilot

Here’s what I did: I uploaded Joshua’s guide into a Claude.ai Project (the web interface, not Claude Code yet).

Why this approach works:

• Claude.ai keeps the entire guide in memory across all my questions

• I can ask things like “How do Commands differ from Skills?” without re-explaining everything

• Basically have an AI tutor that already knows the framework I’m learning

Resources that Helped me Out

1. Nate Herk’s Claude Code Guide:

2. Mark Kashef’s Claude Code Guide:

One thing I wish I knew before building on it was choosing between the self-hosted and Cloud versions.

TDLR: From my own experience, if your workflow regularly runs longer than 5 minutes, skip Cloud and go self-hosted immediately.

Subscribe now

#1: Execution Run Time

The biggest limitation of n8n Cloud is its max execution runtime.

This is simply the amount of time your workflow is allowed to run before n8n stops it.

• Starter = 5 minutes

• Pro = 40 minutes

• Anything beyond this gets cut off.

What this means is the amount of time that your workflow can run, before n8n caps it and stops it.

This is why any workflow that consistently runs past the 5–40 minute range should go straight to self-hosted.

A short story… When I was building an agentic workflow for Riverside, it kept failing around the 15–40 minute mark. It was super perplexing because I couldn’t figure out why.

I spent hours trying to debug. Kept thinking that there was a failure in my workflow logic.

Turns out it was just a Cloud plan limitation.

I shifted everything to a self-hosted setup, and it ran for more than 4 hours without any issues.

In my most recent test on the n8n Cloud Starter plan (see the image above), the workflow consistently failed around the 20–30 minute mark.

From my experience, anything that crosses the 10-minute range becomes a wildcard. You never really know when Cloud will decide to shut the workflow down.

But… why will you need such a long running workflow?

It usually comes down to two things:

1. The nature of the work itself (scraping, LLMs, slow APIs)

Some workloads are just slow by design:

• Scraping websites (pagination, throttling, retries)

• LLM creation workflows (image generation, video generation, multi-step prompts)

• APIs with heavy rate limits

• Polling or waiting on slow upstream services

Any of these add latency, even if you’re only doing them once.

2. You’re doing it at scale (large batch jobs, loops)

If you run the same slow process not once, but 50, 200, or 1,000 times, runtime explodes.

• Loops over large datasets

• Batch enrichment

• Multi-agent cycles

• Repeated reflection or planning steps

• Processing a full list of URLs / prospects / videos / transcripts

#2: Cost

So if your workflows consistently runs past the 5-40 minute range mark, you have a few options

• Go to n8n self-hosted: $5-$20 USD/Month

• Go to n8n enterprise: $12k~ USD onwards/Year

Unless you’re a company that needs enterprise-level features like SSO, SOC2, audit logs, or vendor compliance, self-hosted is the most economical choice.

On cost alone, self-hosted is the clear winner.

Note: I didn’t compare self-hosted with the Starter plan because the cost difference is too small.

#3: Private Packages (e.g., Python Libraries, Pandas)

This is something that really caught my eye recently.

I haven’t tested it yet, but self-hosted n8n apparently allows you to use external Python packages and libraries such as Pandas.

This is a big deal because it means you can give your LLM access to far more tools inside your agentic workflows, without having to rebuild everything from scratch inside n8n nodes.

You also save a lot of time as you’re not recreating entire libraries yourself.

#4: Infra Management

From what I’ve seen, there are basically two ways to self-host n8n

• Self-hosted (Fully managed): e.g. Render ($19/month)
  You get the benefits of self-hosting without touching servers.

• Self-hosted (You manage the server): e.g. a VPS (Varies, $5-$15/month)
  Full control, but you handle updates, scaling, and monitoring.

• Cloud: no infra to manage at all
  Easiest option, but with the limitations mentioned earlier.

It’s true that Render is more “pricey,” but the time and effort you save from not having to maintain your own VPS is worth it.

If you’re not technical like me, paying a bit more to avoid server maintenance is a huge time saver.

Do note that if you’re using Render and your workflows start scaling (more executions or longer runtimes), you’ll eventually need to upgrade your Render instance’s RAM to support the increase.

Wrap Up:

If you’re building agentic workflows, the decision between Cloud and self-hosted n8n isn’t complicated.

Long runtimes, Python packages, or heavy loops? Go self-hosted.

If not, Cloud works fine.

So business owners and solo marketers doing it all themselves can skip the guesswork… and copy what actually works.

→ I drop one of these 10xPlaybooks 🚀 every week. Don’t miss the next.

John

150+ people turned up. Really heartening to see the marketing community in Singapore being so passionate about AI.

As a marketer trying to make sense of this post-AI world, there are a few things I’ve come to believe:

1. Community matters more than ever.

2. We learn faster (and better) from each other than figuring everything out alone.

3. No one has this figured out. We’re all still students.

Below are some highlights from the session, plus the deck I shared.

Subscribe now

Designing Agentic Systems

I think agentic systems should be built around two simple principles:

• Repeatability

• Your biggest bottleneck

Repeatable systems let you run proper evaluations, handle errors cleanly, and feed context back into the workflow without things breaking.

Bottlenecks force clarity. Identify the biggest constraint in your role or business, then design a system specifically to remove that choke point.

Agentic Systems = Workflow Layer + Data Layer + LLM Layer

3 things every agentic systems needs:

1. Workflow Layer: This is where everything gets built and automated. It handles the logic, the routing, and the sequence of tasks.

2. Data Layer: Feeds your workflow with the information it needs, such as internal and/or external data

3. LLM Layer: Uses a model to interpret inputs, make decisions, and generate actions or outputs.

Bottleneck → Supply or Demand Constrained

Generally speaking:

• Supply Constrained: Build operational efficinecy agentic systems

• Demand Constrained: Build demand gen/customer acquisition agentic systems

Why I think bottleneck identification is important?

In the AI world we’re in, there’s just too much noise. And too little time.

We need to cut through the noise and fight the fomo. And not explore endlessly or try to build every single type of agentic workflow out there.

This was actually me 4-5 months ago, where I was trying to build everything, test everything, and ended up spreading myself too thin.

Now, I’m super focused on the parts of agentic marketing that actually is required for my role.

Remember: The market rewards depth over breath

Mockup of a Demand Generation n8n Workflow

I also built a mock workflow in n8n using the problem statement below.

Your role: You’re a demand generation marketer at Airwallex.

Your goal: Acquire more net-new F&B customers in Singapore for Airwallex’s payment gateway.

Workflow steps

1. Scrape Google for “online bakery”–related keywords in Singapore

2. Render the HTML to extract content

3. Pass everything into LLMs to do three things:

   1. Extract the email

   2. Check if the business is actually doing online bakery (look for terms like “show now”, “delivery”, etc.)

   3. Draft a cold email

4. Store the results in Google Sheets so you can use them immediately

The end result?

You’d get something like this. And once this is built, you can schedule it to run daily or weekly… giving you a steady, predictable stream of leads without manual effort.

Agentic Workflow Improvements

Agentic workflows aren’t something you set once and forget.

99% of the time, you won’t get it right on the first try.

That’s where evaluation and iteration of your workflow becomes very important.

For example in this workflow, I noticed that

• Using an LLM to identify emails from the rendered HTML wasn’t reliable → better to use a dedicated email-finding API (like hunter.io).

• Some scraped results were already existing Airwallex customers → run them through your CRM’s API to filter and keep only net-new customers.

Wrap Up

It was a really cozy event. Packed, but in a good way. Lots of genuine conversations, people sharing what they’re building,

I honestly learnt a lot just from talking to everyone. The questions, the small chats after the session, the random “hey, I’m trying this too” moments.

Events like this remind me why community matters so much in a post-AI world. None of us have everything figured out, but together we move a lot faster.

Thanks again to everyone who came up to chat. Hope to see you all at the next one.

PS: Here’s the link to my deck if you want to look through it.

So business owners and solo marketers doing it all themselves can skip the guesswork… and copy what actually works.

→ I drop one of these 10xPlaybooks 🚀 every week. Don’t miss the next.

John

Subscribe now

Verdict: 9.5/10. Highly recommend.

It covers the fundamentals of agentic workflows, which includes: reflection, tool use, planning, and multi-agent systems.

It also provides solid theories and examples on evaluation, optimization, and error analysis, something that I think areas most people (including me) skip when building their first AI systems.

Just wanted to share 14 key learnings from the course that I found most useful.

Subscribe now

#1: Agentic Workflow Development Process Summary

Your agentic workflow development has two “modes” — Build and Analyze — and you should move constantly between them.

• Build: Start fast. Get an end-to-end system running (even rough). Then improve components as signals appear.

• Analyze: Examine outputs, read traces, and run small evals (10–20 samples). Track metrics, do error analysis, and isolate weak components.

Then cycle between both.

• You start by building a quick, end-to-end system

• Then you analyze right away by look at outputs, read traces, spot underperforming components.

• That analysis informs what to fix next.

• You repeat this loop: build → analyze → build → analyze, tightening it each round.

#2: Degrees of Autonomy

I thought this was one of the more interesting sections for me personally.

There’s always debate (especially on Linkedin) on what counts as an “agentic” workflow.

Most people see it as binary, meaning a workflow is either agentic, or it isnt.

Andrew defines it differently. An agentic AI workflow is simply when an LLM-based app executes multiple steps to complete a task.

And instead of a yes/no definition, he frames it as a spectrum of autonomy:

• Less autonomous: fixed, hard-coded steps.

• More autonomous: the LLM decides which tools or actions to take

#3: Parallelism for Speed

Always consider parallelism workflows for speed.

It gives you:

• Better performance

• Faster than humans

• Modularity as you can swap tools, models, or components anytime

In the example above, instead of fetching pages one by one, the system can parallelize all nine web downloads, then feed them into the LLM to write the essay.

#4: Agentic Workflow Evaluations

Agentic workflow evaluations help you troubleshoot why a workflow isn’t performing and pinpoint exactly where it’s breaking down.

Here’s an eval framework:

1. Define what “good” looks like.
   Before running evals, know what success means, IE what specific output or behavior you’re expecting from the workflow.

2. Start small.
   Run a mini-eval on 20–50 examples.
   This gives you fast signal on which step or component needs improvement.

3. Pick the right eval type:

   • Objective: measurable accuracy (e.g., output Y = expected Y).

   • Subjective: LLM or human-judged quality (e.g., clarity, tone, reasoning).

#5: Objective vs Subjective Evaluations

Objective evals are for tasks with clear right or wrong answers.

They’re code-based, grounded in hard truths, and measured against known results.

• Use code-based evals when outputs can be verified automatically

• Build a dataset of ground-truth examples to test agains

Subjective evals use an LLM as a judge when there’s no single “correct” answer.

Example are for tasks like reasoning, tone, or visual clarity.

Key insight: Grading with a rubric framework gives more consistent, repeatable results.

Example rubric for chart evaluation:

1. Has a clear title

2. Axis labels are present

3. Chart type is appropriate

4. Axes use the correct numerical range

Each rule gets a binary score (1 or 0), then aggregated. The LLM grades performance objectively within a subjective task, thus keeping feedback structured instead of fuzzy.

#6: End to End vs Component Eval

End-to-end evals are expensive! You have to run the entire workflow just to see what needs improvements.

Component-level evals are more surgical. You can isolate which part of the workflow is not up to expectations, so you know exactly where to focus improvements.

Use end-to-end evals to test the full user experience.

Use component evals to debug faster and save compute.

#7: Reflection to Improve Outputs

I must admit… this portion on “reflection” is interesting.

I never thought of putting in a “reflection” step to improve on outputs, but it make so much sense.

The idea is very simple: after the LLM writes the first draft, it reviews its own output, identifies weaknesses, and rewrites a better version.

Why? Because reflection = increased performance

How to do reflection:

• Explicitly define what “reflection” means in that context. IE tell the LLM what to reflect on (e.g., factual accuracy or reasoning gaps) and what to check (clarity, logic, tone, etc.)

• Don’t use “fuzzy” reflection logic such as “improve this” or “make it better”

#8: Reflection (with feedbacks)

Reflection can also come externally.

You can connect external tools that the LLM can call for feedback. Then feed those feedback signals back into the model to refine its next output.

#9: LLM Tools

LLMs can be equipped with tools (functions) to take action or retrieve data.

Instead of hardcoding every step, you let the LLM decide when to call a tool.

This is an important first step in building more autonomous agentic workflows, giving the LLM autonomy to plan and execute actions on its own.

#10: Error Analysis

Two key takeaways from this section.

1. Analyze errors on a component level

Break your workflow down and check which step is producing outputs that don’t match your expectations.

2. Measure manually

Compare each component’s output to what you expect it to produce and track which step underperforms most often.

Without proper error analysis, you waste time tweaking things randomly. Instead of fixing the component that actually bottlenecks your workflow performance.

Andrew shares four ways to improve LLM component performance:

1. Improve your prompts

2. Try a new model

3. Split up the step

4. Fine-tune a model

Personally, I’ve found little uplift from switching models. Think that today, most are “good enough” for typical use.

But improving prompts and splitting steps into smaller parts has delivered noticeable performance gains for my workflows.

#11: Latency & Cost Optimization

Both latency and cost matter… but in practice, latency usually matters more.

Token costs are often negligible, while slow responses hurt user experience and cap your workflow’s runtime.

I would say that generally only optimize cost when it’s significant, but focus first on making your workflow feel fast.

#12: [Pro Tip] Real Automation = The LLM Plans, You Don’t

This section was a real eye-opener for me.

When building agentic workflows, you can and should ask the LLM to plan the steps first. Let it figure out how to solve the problem before it starts executing.

I’d been doing it backwards. Hardcoding every step instead of letting the model design the plan itself.

Although, I think the sweet spot might be a mix of full autonomy and semi-autonomy.

• Have the LLM to plan out the steps first

• Hard code the steps

• Run 50 times to do proper error analysis and component analysis

Because if the steps aren’t discrete, it’s hard to measure where things go wrong or which part underperforms. Food for thought.

#13: [Pro Tip] Shortcut Workflow’s Edge Cases Through External Libraries

To handle your workflow’s edge cases, you can make use of existing libraries.

Instead of create a standalone tool for each edge case (time consuming, not practical).

Take Pandas library in Python for example. it has hundreds (even thousands) of functions for data processing.

By letting the LLM write code and call those functions, it can string together multiple operations to solve complex queries on its own.

#14: Multi-Agentic Workflow

Think of agents like specialized tools the LLM can call when needed.

Instead of one big linear workflow, the LLM plans and coordinates across multiple roles.

• Creating different agents (similar to tools) that the LLM can call

• Ask the LLM to carry out the plan

• Execute

• The workflow becomes non-linear

Wrap Up: Strong Fundamentals Win

I really enjoyed this course.

It covers the core fundamentals of agentic workflow design, something rarely explained this clearly anywhere else.

Highly recommended for anyone that is starting out in agentic workflow building.

So business owners and solo marketers doing it all themselves can skip the guesswork… and copy what actually works.

→ I drop one of these 10xPlaybooks 🚀 every week. Don’t miss the next.

John

She’s one of the few marketers I’ve met who doesn’t just tinker with AI tools. She builds AI workflows, codes her own MCP servers, and thinks deeply about where AI & marketing is really heading.

Since then, we’ve had long, unfiltered conversations about AI and marketing. And every time, her perspective stood out: blunt, strategic, and refreshingly free of hype.

Some of my favorite AI-related posts from Alex on LinkedIn:

• A masterclass in storytelling

• MCP Guide

• It’s all about strategy

That’s why I asked Alex to share her thoughts in this Q&A, so more people can hear the way she thinks about AI & marketing.

Subscribe now

Question #1: Why do you think strategy is the real moat for marketers in the AI era?

Alex: Strategy is the baseline.

But it’s not the only thing. What makes marketers defensible in the AI era is the combination of strategy, curiosity, taste, and empathy.

• Strategy matters because if you don’t understand the problem you’re solving, the audience you’re solving it for, and what people actually expect, no tool or workflow will save you.

• Curiosity is critical because AI changes so fast. If you’re not experimenting and asking new questions, you’ll fall behind.

• Taste and empathy separate the noise from what’s valuable. Audiences already filter out generic “AI slop.” To create content that resonates, you need human judgment, taste, and the ability to put yourself in the customer’s shoes.

So yes, strategy is the moat, but it only works if you combine it with curiosity and taste.

That’s what will separate great marketers from everyone else as AI makes execution cheaper and easier.

My Thoughts: 

I think strategy comes from an innate grasp of marketing fundamentals. The stuff you only build by solving with real problems, not with shortcuts.

The thing about AI is it tempts marketers with an easy way out. You can skip the understanding, get a decent answer fast, and move on. But it’s exactly that hard work, the failures and the experimentation that builds real strategic thinking, 

Question #2: Does AI make it harder for younger marketers to build strategy?

Alex: Yes and no. Nobody sat me down early in my career and taught me “strategy.” I learned it by jumping into tactics, failing, then breaking things down and realizing what worked and what didn’t. That trial-and-error process is what builds strategic thinking.

The risk with AI is that younger marketers may skip that process. They can get answers fast, but they lose the struggle that usually forces deeper understanding.

That’s why leaders have to step in. It’s our responsibility to expose younger marketers to strategy:

• Explain the “why” behind decisions (why we chose this playbook, why we ignored that channel).

• Show them how positioning and messaging are built, not just hand them a tool.

• Give them space to experiment. To think, problem-solve, and find their own answers.

AI can accelerate parts of the work, but without mentorship, I think that junior marketers risk staying stuck in tactics.

My Thoughts: 

I used to be a very tactical marketer, always hunting for inefficiencies in the market we could exploit for quick results. The problem is, those gaps never last. You end up chasing short-term wins instead of building something sustainable. 

Learning strategy is what allows a marketer to shift from quick wins to building something sustainable.

Question #3: What does a strategy-first approach to building AI workflows look like?

Alex: When it comes to AI automation, it's easy to confuse strategy with complex workflows, but those tend to backfire.

Those complex no-code workflows look shiny, but they break easily, waste time, and often require developer skills anyway.

A strategy-first approach starts with the problem: what are we actually trying to solve? From there, it’s about choosing what’s worth automating and what isn’t.

That usually means starting small:

• Using tools you already have (like Gemini inside Sheets) to save hours on analysis.

• Building lightweight workflows that solve one real bottleneck.

• Automating only once you know it works in practice.

Chasing end-to-end agents that promise to "replace your marketing team" won't get us far. But stacking small, reliable wins that align with our strategy will.

My Thoughts: 

For me, strategy in AI workflows starts with one question: what specific problem are we solving?

The workflow should exist only to solve that problem. Nothing more.

Most of the time, that means the workflows aren’t complicated. They’re focused, singular, built to solve for X and only X.

Question #4: Part of strategy is focus. With new AI tools every week, how do you decide what’s worth exploring?

Alex: "Shiny tool syndrome" is real. With endless updates on new tools, features, models, and "no-code" workflow templates, it's too easy to be distracted.

The way to stay focused is to start from first principles: what actually makes a difference for your marketing strategy and pipeline? Strategy means deciding not just what to do, but what to ignore.

That often means doubling down on smaller, proven wins such as plugging AI into Google Sheets to analyze thousands of rows of data, instead of chasing the latest tool.

Focus is a discipline: ignore 90% of the noise and go deep on the 1–2 things that create real impact.

My Thoughts: 

I’m a lot more selective with AI tools now. When I first started, every new launch felt like a “game-changer,” and I wanted to try them all.

But after spending time building actual AI workflows, my approach has shifted. 

Today, I look at tools on a needs basis. If I’m repeating a task often, that’s when I’ll look for an AI tool to augment it, not before.

Question #5: If AI makes execution a commodity, what else besides strategy gives marketers an edge?

Alex: If AI commoditizes execution, the edge won’t come from a productivity and efficiency boost, as everyone will have that.

The edge comes from what AI can’t replace: taste, empathy, and authenticity.

• Taste: knowing the difference between high-value content and generic “AI slop.” Audiences are already filtering out posts that feel machine-written. Marketers with taste will know how to steer AI to produce quality that resonates.

• Empathy: being able to put yourself in the customer’s shoes, understand what actually matters to them, and translate that into campaigns.

• Authenticity and community: people will crave human-to-human connection more than ever. Live events, founder-led brands, and communities will become some of the strongest differentiators.

So beyond strategy, the moat is human judgment and the ability to build real trust. That combination is what will separate marketers who thrive in the AI era from those who get drowned out.

My Thoughts: 

It’s funny how things change. I started my marketing career right when social media was taking off. Back then, brands were ditching human-to-human connection to go online.

Ten years later, we’ve gone full circle in the age of AI. 

Wrap Up: A Marketer’s Real Moat

The future of marketing won’t be defined by who tries the most AI tools. It will be defined by who uses them with focus, judgment, and strategy.

That’s Alex’s core message: AI is just the accelerator.

The real moat comes from how you think, what you choose to ignore, and the edge only humans bring… Which is taste, empathy, and authenticity.

Big thanks to Alex for sharing her candid perspective!

PS: Do follow Alex on LinkedIn for hype-free AI use cases for marketers and GTM teams, which she shares regularly.

So business owners and solo marketers doing it all themselves can skip the guesswork… and copy what actually works.

→ I drop one of these 10xPlaybooks 🚀 every week, don’t miss the next.

John

Subscribe now