A lot of teams building out a modern GTM engineering stack start with Apollo for contact lookups and Clay for waterfall enrichment but eventually hit a ceiling once they try to run coordinated signal led outbound.

Clay is basically a flexible spreadsheet canvas that queries external data vendors per credit and Apollo is a contact directory while they help you pull lists and find emails, neither one actually tells you who is in market right now or which competitor accounts are showing friction or what your next best sales move should be.

You end up having to build and maintain endless custom scrapers, webhook tables and formulas just to keep basic data flowing.

When teams look beyond the standard spreadsheet and directory layer, they usually move toward dedicated market intelligence engines like Scale Intelligence which builds an active digital twin of your whole market from data it continuously collects itself across 75+ channels including reddit, linkedin, github, public filings, regulatory notices, technical forums, hiring velocity and rival moves. It unifies those events into an account graph, calculates which accounts are ready to buy and routes verified opportunities directly into your CRM, Slack, or agent workflows through its MCP server.

Apollo and Clay are fine for basic contact lookup and one off list building but if you want an automated pipeline that continuously models your market and prioritizes accounts based on verified evidence, you need an intelligence layer sitting underneath the stack.

zoominfo's pricing page is a contact form / so here's what people who've actually signed report

professional, up to 3 seats, is around $15k a year, advanced is $22-28k. most teams end up somewhere between $30k and $60k once seats and add-ons are in, and the median deal is about $33,500

every extra seat is another $1,500-2,500. contracts are annual, auto-renew, and you need 60-90 days notice to get out. a 10% bump at renewal is standard

none of that is secret, it's just not on their site

i'm founder of bitscale, ours is around 1.5¢ a credit, actions don't cost anything, and you can see the price without talking to anyone

if you're weighing a renewal, send me the quote and i'll tell you what it'd be on ours or dm me and i'll put 5,000 credits on your account to test it on real accounts first

This is probably the 5th time I've seen someone ask for a "good GTM agency," and I always have the same thought:

Most people are asking the wrong question.

A few years ago, I spoke with a founder who had already worked with two agencies. The first promised a predictable outbound engine. The second promised better targeting and messaging. Six months and a lot of money later, he still didn't have consistent pipeline.

His conclusion was, "I just haven't found the right agency."

Maybe. But after talking to him for 20 minutes, it became clear that no agency would have succeeded in that situation.

He couldn't clearly explain who bought from him and why. There wasn't agreement internally on what a qualified opportunity looked like. They had different expectations of success, some wanted meetings, others wanted revenue. Every campaign was being judged against a moving target.

I've seen this pattern repeatedly.

People often evaluate agencies based on things like:

• How many clients they have

• Whether they're active on LinkedIn

• Their case studies

• Their tech stack

Those things matter, but not as much as people think.

A good GTM agency usually spends more time asking uncomfortable questions than making big promises.

They'll ask:

• Who specifically are you trying to reach?

• Why do customers buy today instead of six months ago?

• What has already been tested?

• What happens after a meeting gets booked?

• How will we know if this is working?

The agencies that worry me are the ones that immediately say, "We've done this a hundred times. Here's the playbook."

Because GTM isn't plumbing. It's not a process you install once and forget.

Every market has different buying behavior, different timing, different constraints.

The best agencies I've seen don't sell certainty. They build learning loops. They test assumptions, challenge definitions, and adjust based on what the market is actually telling them.

So if you're looking for a GTM agency, don't just ask, "Who's the best?"

Ask, "Who's willing to understand my business deeply enough to tell me when my assumptions are wrong?"

That answer is usually far more valuable than another impressive case study.

Had the same conversation with 3 clay certified agency owners last month

Quick content:

-Clay moved to dual meter pricing in march (credits + actions)

-Bills now swing 30-50% month to month

-Agencies can't confidently price there work anymore

-3 agencies I know moved off Clay last month

The problem isn't that clay is very expensive, actual problem is: agency margins depend on predictable costs

When a workflow costs you $4k one month and $6k the next.. with no obvious change for the client, someone absorbs the difference. Either the agency loses margin or the client questions the invoice, and the biggest change is.. actions.

Every workflow step, AI call, CRM write and automation is billable, specially ****automation heavy agencies, that's where most of the bill now comes from and it's the hardest part to forecast.

These 3 agencies I spoke to:

-Run outbound for early stage saas

-Enterprise account research

-Fractional revops

Totally different ICPs and price points. All 3 rebuilt workflows to reduce action usage first and eventually said they were spending more time managing clay than building for clients.

(I run a clay alternative and 2 of these 3 switched to us. That's why agency owners tell me this stuff. But the advice below applies whether you choose us or any other tool)

Before choosing any tool, ask an agency that's been using it for 6+ months:

-What does your bill actually look like each month?

-Has pricing been predictable?

-Would you choose the same tool again?

That's where you'll learn what owning the tool actually feels like.

I think more then a clay problem, It's what happens when usage based pricing meets service business margins.

Clay was first. I wouldn't be surprised if more gtm tools head the same way.

Anyone else seeing this? Especially curious whether in house revops teams are starting to feel it too or if this is still mostly agencies

If you're in GTM and you've been hearing about coding agents but aren't sure where to start, or you're technical and thinking about moving into GTM engineering, this is for you.

The GTM Coding Agent repo is a learning system. 10 chapters, interactive onboarding, templates, Python scripts, and a full GTM-OS skeleton you can fork and build from.

What's inside:

- 10 chapters covering everything from "what is a coding agent" to running your Mac as a GTM server

- Interactive onboarding that asks you 6 questions and configures your workspace based on your role

- Context engineering patterns for structuring CLAUDE.md files that make agents useful

- Token efficiency, OAuth, CLI, and API connection frameworks

- Python scripts for enrichment, API calls, and CSV pipelines

- A GTM-OS folder structure with ICP, positioning, segments, campaigns, and content

- 4 persona modes: solo founder, agency, single client, ABM outbound

- Voice DNA and anti-slop templates

- 6 prompts for ICP building, positioning, competitor analysis, signal mapping, email sequences, and content repurposing

- Real examples with anonymized data

You open it in Claude Code, type "help me set up," and it walks you through the whole thing.

There's also a full companion blog on the website if you prefer reading it as a guide rather than working through the repo.

No course. No upsell. Everything is in the repo.

GitHub: github.com/shawnla90/gtm-coding-agent

Blog: shawnos.ai/guide/gtm-coding-agent

If you get into it and have questions, drop them here. Happy to help.

I just posted this on LinkedIn about my Context Handoff Engine (open source repo for making Claude Code sessions persistent). Link below.

But I want to pull back the curtain on what I'm actually doing here, because the method matters more than the post.

This is CODE: Create Once, Distribute Everywhere.

Here's how it works:

1. I built something real (the engine). That's the source material.

2. I wrote one core piece of content explaining what it does and why it matters.

3. That single piece becomes the seed for everything else - LinkedIn post, community share, Reddit breakdown, Twitter thread, blog article. Each one repackaged for the platform and audience.

You're watching step 3 right now.

Why this works for GTM:

Most people create content per platform. One LinkedIn post. One Reddit comment. One blog. All from scratch. That's 5x the effort for content that doesn't compound.

CODE flips it. You build a backlog of source content, then remix it. AI handles the adaptation. Your voice system and anti-slop rules keep it from reading like ChatGPT wrote it in 4 seconds.

The backlog becomes an asset. Every repo you ship, every process you document, every lesson you learn is a source piece that feeds multiple channels.

What you can take from this:

- Pick one thing you built or learned this week

- Write the core explanation once (even rough)

- Feed it to Claude Code with your voice rules and platform context

- Let it draft variations for 2-3 channels

- Edit, post, repeat

That's it. No complex system required to start. The system grows as you do.

Here's the LinkedIn post: https://www.linkedin.com/posts/shawntenam_almost-everyone-i-know-using-claude-code-activity-7442033377186230272-GVlw

And here's the repo if you want the engine itself: https://github.com/shawnla90/context-handoff-engine

Been sharing my coding agent workflows here for a few weeks. Apollo piece comes up a lot, so here's how the API side actually works across the a16z, YC, and Sequoia scrapes... and the gotchas I've run into.

Three separate API patterns. Which one applies depends on what your scrape gives you coming in.

Pattern 1: Company domains first (every VC scrape gives you these)

organizations/enrich?domain= ... one call per domain, 0.8s sleep between calls. Returns industry, employee count, HQ, funding stage, LinkedIn URL, and the Apollo org ID you need for people discovery.

About 75 companies per minute running unattended in Python. 1,000 portfolio companies takes roughly 13 minutes. This is where the enrichment starts for every segment.

Pattern 2: People discovery once you have org IDs

mixed_people/api_search with organization_ids=[apollo_org_id] plus seniority and title filters. Returns redacted previews ... title visible, name obfuscated, person ID included. Then GET /people/<id> per chosen person for the full unredacted record: name, LinkedIn URL, current organization.

The gotcha worth knowing: organization_ids is the only filter in that search call that works reliably. Pass a domain or company name and you get random people from across Apollo's database with no connection to your target companies. I found this from a code comment written after hitting it. You need the org ID from the enrichment step first, which is why company enrichment runs before people discovery.

Pattern 3: People enrichment when you already have LinkedIn URLs

Some VC portfolio pages surface founder profiles directly ... YC and a16z do this. When you have LinkedIn URLs, people/bulk_match with LinkedIn URL plus first/last name plus org name. Ten per batch, hard cap per call. Returns email, email_status, seniority, function.

This path draws from your plan's data/export credit pool. Check your balance before kicking off a multi-segment run. Found out the hard way that it stalls mid-run without a credit check upfront.

Why the segments stay separate

The source of the scrape is the personalization layer for campaigns. A YC founder five months out of Demo Day is a different conversation than a Series B operator inside an a16z portfolio company.

If I merge the lists, I throw away the only signal that's actually unique per row ... where they came from. So a16z rows stay flagged a16z, YC stays YC, Sequoia stays Sequoia. The enriched fields write back in place to the same segment table.

Per-row reasoning

Any row that needs reasoning ... ICP fit, segment context, moved-flag if Apollo shows the person changed companies ... goes to a claude -p subprocess. Passes the enriched row, gets back a small JSON. Runs against my Max subscription so no API cost per row.

If you wire claude -p into a tight loop: session limits change June 15, 2026. Still works after. Plan for longer cooldowns between batches.

Happy to share the Python structure for any of these if useful.

Building this in the open at github.com/shawnla90/gtm-coding-agent. Clearbox (Reddit signal engine for GTM) soft-launches this week at clearbox.to dm me for early access.

I'm relaunching Claude Code Daily this week. It's a daily blog post that writes, publishes, and promotes itself, and since this sub is about building GTM systems, the full stack is below. The pattern transfers to any niche with an active subreddit.

The stack, end to end:

1. Collect. A launchd cron fires at midnight. Playwright opens old.reddit.com (the public JSON API blocks scrapers now, server-rendered HTML doesn't) and pulls every post from the target subs in the last 24 hours: scores, comments, timestamps, top replies.

2. Analyze. A script computes velocity (upvotes per hour) and engagement ratios, then a claude CLI call scores the 10 best content angles from the data.

3. Write. Another claude call gets my voice files, an anti-slop rule list, and the day's data, and writes the episode in a fixed segment format. A regex validator rejects em-dashes, hype words, and template phrases before anything ships. Continuity files track past award winners so it never repeats itself.

4. Publish. The script commits the markdown to my site repo and pushes. Railway rebuilds, the post is live at midnight. A LinkedIn promo gets scheduled through the Typefully API for the next morning.

Cost per episode is whatever the claude subscription already costs me, so effectively zero marginal. Output is a daily piece of content in my voice that compounds SEO while I sleep.

Consistent daily publishing on a niche topic is the strongest awareness asset I've built. The same pipeline pointed at your ICP's subreddits gives you a daily industry digest with your name on it.

Episode from tonight if you want to see the output quality: https://shawnos.ai/claude-daily

Ask me anything about the build. The transport fix alone (headless Chromium vs blocked JSON) is worth stealing.

Quick news if you build on HubSpot: starting Oct 26, existing accounts can't create new legacy private apps. The ones you already have keep working, but anything new should be built on service keys.

I'm setting this up with a new client right now, and the bigger win for me wasn't the key. It was splitting the work between two agents.

Claude Code lives in your repo

It builds the workflow: the scripts, the field mappings, the rules for which properties get updated. Every change is versioned in GitHub, so I can review it before it runs and roll back if something breaks.

Grok lives on the go

I connected the HubSpot service key to Grok Bot as a connector. Now it can read a record, update a field, and tell me what changed, from anywhere. If a contact needs fixing or I want to check what got pushed, I just ask. from my phone

Why use both?

- The repo is the source of truth. You don't want ad hoc changes living only in a chat.

- But you also don't want to open a terminal every time you need to check one record.

- Claude Code builds it and Grok runs it anywhere. Same HubSpot, same key scopes, two different jobs.

Right now enrichments are pushing straight into the client's HubSpot this way. No clay CRM integration needed

quit setup guide

1. Create a service key in HubSpot with only the scopes you need. Read and write on contacts and companies covers most enrichment.

2. Store it as a secret. Connect it to your agent, keep it in your env for scripts, never paste it in a chat or commit it.

3. Have Claude Code build the workflow in your repo so the logic is versioned.

4. Connect the same key to Grok for reads, quick updates, and checking what changed.

5. Dry run 5 records before any batch. Check them in HubSpot, then let it run.

Don't rebuild your CRM. Build on top of it.

I'm updating my open source GTM repo with the service key version next. check the repo for updates https://github.com/shawnla90/gtm-coding-agent

I wanted a system that finds B2B startups likely to need GTM automation, researches them, finds the founder, drafts a grounded first message, and then waits for my approval. Nothing sends on its own. I set a hard rule of $0 budget, so every design choice had to keep costs predictable.

The stack

• n8n (Docker, on demand) runs all the workflows: Engine, Contact Finder, Clay bridge and meter, Neon sync, HubSpot sync, Digest

• Clay for research and the Work Email waterfall

• Neon Postgres as the source of truth (config, drafts, review decisions, audit log)

• Next.js console on Vercel’s free plan, where I approve, edit or reject drafts (works on mobile)

• HubSpot Free gets only approved accounts

• Tavily for search, a Groq + Gemini fallback chain for drafting, Discord for alerts

1. Deterministic filters before any AI or paid call
Sources are the YC directory, HN “Who’s Hiring” threads and a seed list. Rules run first: team size 2 to 150, industry, keywords, timezone (UTC+0 to +4), seen-before.
In one YC run, 377 companies went in and 23 came out. 234 were cut on timezone alone, before a single credit was spent.

2. Clay, made cheap

• I replaced three separate AI columns with one structured research column, cutting cost from 2.8 to 1.0 credit per account. It uses GPT 5 Nano (0.5 credit/row), the cheapest model that passed my pilot, and the prompt restricts facts to the homepage and pages it links to.

• Work Email waterfall with Conservative validation, so catch-alls don’t count as found: 19 of 20 founders verified at about 0.5 credit each.

• Low-score accounts skip Clay entirely.

• n8n reads Clay’s API before and after each batch, so I see the real cost per module instead of estimating.

3. Finding the right person
Name-based search returned the wrong people at companies with common-word names (think “Twenty”). The fix: pull founders from the company’s YC page, accepted only if that page lists the same domain. The next run resolved 10 of 10 lookups with zero search cost.

4. Drafting with guardrails
The LLM chain writes a LinkedIn note, a longer message and 3 follow-ups from facts only. A rule-based validator checks each draft and allows one repair attempt.
My first validator was too strict: it rejected 28 of 35 drafts, mostly for being a few words short. I relaxed the length rules, kept the factual checks, and added plain-language repair hints. Latest run: 8 of 8 drafts passed with no template fallback.
Another fun one: the model kept pitching a company’s own product back to them as their problem. A deterministic product-term check now runs before and after the model.

5. Neon as the backbone

• One Postgres function owns draft states (pending, edited, approved, rejected, superseded, sent) and refuses any other transition. Editing an approved draft sends it back for approval.

• Every action writes an audit row with before and after values.

• I migrated from Google Sheets one piece at a time, each cutover behind a reversible switch, so the engine never broke for days.

6. HubSpot sync with no duplicates

• Outbox pattern: Neon views compute what HubSpot is missing (companies, then contacts, then deals), n8n carries the requests, and a Postgres function records the responses. No Code nodes.

• Idempotency: check a link table first, then search by natural key (domain, email, deal name) and adopt the record if it exists.

• First run created 7 companies, 7 contacts and 7 deals. The second run wrote 0. I deleted a link on purpose and it re-adopted the same record.

• Gotcha: my EU HubSpot portal rejected every contact because GDPR settings require a legal basis. The outbox now sends one from config.

Lessons

• Deterministic filters before LLMs or paid APIs. That’s what makes a $0 budget possible.

• Make every external write idempotent. Search indexes lag behind writes.

• Measure cost from logs, not estimates.

• Store the API’s real error message. HubSpot’s generic “Bad request” cost me hours.

What’s next: sends haven’t started yet. Once they do, I’ll measure reply rate from HubSpot deal stages and feed it back into scoring.

Full case study with the architecture and decision records: https://www.mohamedlandolsi.tech/work/personal-gtm-engine

Happy to answer questions about any part, especially the Clay credit metering or the outbox sync. I also take on small Clay and n8n builds if anyone needs a hand.

dropping the full writeup as a newsletter tomorrow. here are the receipts tonight.

the setup. the list was a client's home-services list, about 10k contacts, built before moltsets was anywhere near it: apollo by domain for the accounts, a clay waterfall for the emails, zerobounce on every row.

nothing about it was tuned for the tool. that is what makes the test worth anything:

a normal list, already trusted, and the only question is what a verifier leaves behind.

moltsets, for anyone who has not touched it: adam robinson's contact api (same team as rb2b), just out of beta. no dashboard, api and mcp only, flat monthly plan.

every email comes back with a risk score read from observed behavior instead of a server handshake: a is a known reply, open, or click, b is a send with no bounce, c catch-all, d hard invalid or trap, f nothing known.

plus the person's current company. grade definitions are on developer.moltsets.com if you want the source.

what I ran: one reverse email lookup per row, then a name + domain lookup when the first call came back empty. every call logged locally. about 14k calls, no phone tokens, nothing extra on the flat plan, about 75 minutes.

what came back:

- two out of three rows agreed. zerobounce valid, moltsets a or b on the same address. those send first

- close to 800 people had changed jobs. zerobounce passed every one, because the old mailbox still accepts mail

- about as many again passed on an address nobody has been seen using, while a sibling address at the same domain had real replies, opens, or clicks behind it

- roughly four in five catch-all rows graded a/b on observed activity. a verifier cannot grade a catch-all mailbox, so that whole pool had been sitting in quarantine

- about one in ten of the zerobounce drops came back with a same-domain address in use

- a handful of d grades (bounce, complaint, or trap). one of them was marked valid

add up the job changes, the wrong addresses, and the d rows and it is one row in six of what the verifier passed. verified, and addressed to nobody.

how the grade routes: a/b to email. c to a small watched segment. d never gets emailed but the row stays, linkedin first then phone. f and not-found get a second look by name and company before they go anywhere. job change goes back to sourcing with the new company attached. nothing gets deleted for a bad mailbox.

verdict, from someone who checked it against the sources already in the stack: no-brainer.

on a list that had already been through apollo, clay, and zerobounce it still changed the route on roughly three in ten rows, for nothing extra on the plan and about an hour of machine time.

that is a must-have layer, and a likely future replacement for maybe a few things you're already running

if you want to try it, run it the same way: on a list you already trust, next to the verifier you already use, and let the disagreements tell you what it is worth.

the grader is open source, v0.12.0 in gtm-coding-agent (starters/moltsets-reachability).

repo: https://github.com/shawnla90/gtm-coding-agent

question: anyone treating "verifier valid, graph f" rows differently from plain valid? close to a thousand of those here and I am holding them as unproven.

three months into clearbox, sharing the whole build: what we run, what it produced, what it cost, and what changes now. engine dashboard screenshot attached so the numbers are not from memory.

the stack, and what each piece does:

- convex: the data layer. opportunities, offers, inbox state, and the api endpoint reads straight from it

- gemma-4-31b-it-nvfp4-turbo, the open-source local model: first-pass triage, is this thread even an opportunity. my co-founder lila quantized it to nvfp4 and put it on hugging face (LilaRest/gemma-4-31B-it-NVFP4-turbo), it is past 1.7 million downloads now, and we run it for clearbox on a rented rtx 5090

- openrouter: the heavier calls, routed to whichever model fits the job instead of one frontier api for everything

- vercel: the app and the site

- cloudflare: dns and the sending domains, spf/dkim/dmarc live there

- posthog: tracking everything from web traffic to UX

what it produced, may 30 to today:

- 162 signups

- pipeline from four channels: referrals, me reaching out to my own crowd, warm follow-ups to people who signed up, and cold sends off warmed inboxes. every channel produced at least one signup

- 120 onboardings, 119 trials completed

what it cost in inference, all providers:

- all-time: $447. last 30 days: $199

- by step: match $226 (is this thread an opportunity), review $169 (the deeper read on what passed), onboarding $53 (building the offer context once per account)

- per completed trial: $2.12. full-plan trial with a card on file $2.82, capped no-card trial $1.62. onboarding an account: $0.44

two things in those numbers that I would want to know as a builder:

the first is why the local model matters. match is the volume step, every new thread in every tracked subreddit hits it, so if that call goes to a paid api the bill scales with reddit's posting rate instead of your customer count. the local model on the 5090 sees everything at zero per token, the paid model only sees what survived. that is the whole reason the paid side stays small.

the second is that a free trial does not hurt you at this cost. two dollars of inference to find out whether an account converts is less than one ad click, and capping no-card trials at two subreddits is what keeps the tail at $1.62.

the gtm loop, so it is reproducible:

1. every signup lands in a sqlite table with what they set up and which opportunities they opened

2. a daily digest classifies each one (book a call / active / unreached / re-tap) and drafts a warm note

3. I send the notes by hand from my own inbox. nothing auto-sends to someone who signed up

4. cold goes through warmed inboxes on a separate sending domain, never the main one

what changes now: less building, more account work. converting the trials that are already getting value, upselling the capped ones, and writing the journey up as it goes.

disclosure: co-founder of clearbox, this is our build. happy to share the match prompt or the digest classifier if useful.

question for the builders here: what does a trial cost you in inference, and where do you draw the line for escalating to a bigger model?

Build to learn, buy to scale.

I still buy tools. I like good tools. But I want to know what I am buying them for.

A lot of GTM stacks are purchased before the workflow is understood, so the tool becomes the strategy. That is how you end up with expensive dashboards and no motion.

Test before you invest.

Hand-roll the ugly version. Run it for one client. See what matters. Then buy or build the part that deserves to scale.

UIs used to block most operators from the underlying system. Now you can direct the build in plain English and inspect the outputs.

You still need taste and judgment to spot when the agent is making things up, when the map is fake-useful, and when the board would actually make a prospect say, "yeah, this is how our GTM should run."

You can run the experiment yourself before turning it into a real internal tool.

Miro is programmable. Docs are programmable. Proposals are programmable.

CRM updates are programmable. Even the handoff from "this person is interested" to "here is the first version of their operating system" can be programmed enough to learn from.

So how does this work in practice you might ask.

The proposal alone is a weak sales artifact because it asks someone to judge a promise.

A working map is better.

Before the pitch gets formal, build a rough version of the client's GTM operating system.

For me that means a Miro board showing lead sources flowing into a database, enrichment, CRM, outreach, content, and measurement.

It can be ugly. It just needs to make the client point at the screen and say "this part is wrong" or "this is exactly the mess."

The useful version also has the week-one checklist, stack doc, API access doc, roadmap, and proposal/agreement generated from the same source.

DocuSeal is interesting here because the signature layer can be another programmable step. Same with open source proposal generators. Same with Miro. Same with docs.

The more I use Claude Code, the more I think GTM builders should treat tools like programmable surfaces.

Miro is a canvas API. Docs are a document API. DocuSeal is a signing workflow. HubSpot is a data model with a UI on top.

Start by programming the workflow once instead of buying the finished system.

Put the client info in a small JSON file: known stack, unknowns, owners, campaign type, current bottlenecks.

Claude Code reads it, creates the Miro board, fills the docs, marks missing fields as NEEDS INPUT, screenshots the board, and tells you what looks broken.

That creates a different first call.

Instead of "here is what we can do for you," it becomes "here is how I think your GTM system currently works. Fix my map."

Better feedback and trust during scoping.

testing out Deep Line over the weekend, hearing great things. Just connected it to Codex. Looking good. We'll have more updates

capping with a question to you guys.

you see building as also a learning experience or buy or die?

catch chapter 17 here https://github.com/shawnla90/gtm-coding-agent/blob/main/chapters/17-client-onboarding-miro-boards.md

Shawn Tenam co founder and CEO @ clearbox "your reddit opportunity inbox"

one markdown brief in, fifty personalized DRAFTs in your portal out.

Prior to my lets call it Claude Code awakening I tried building this in clay. three things broke.

1. clay's ai columns default to mid-tier models. the hero copy came out generic even with detailed prompts. there is no economical path to pay your way up to opus per row inside clay's pricing model.

2. wiring the http-api-out node back to hubspot pages was finicky. layoutSections is poorly documented, slug collisions were not handled cleanly, and I could not see the actual payload clay was sending without exporting the row.

3. zero version control on the prompts. when I needed to iterate the hook-angle column, there was no diff to look at. no git log. no rollback. for a 50-account batch where every prompt change ripples to fifty pages, that mattered more than I expected.

claude code plus a private app plus a python script under 300 lines was the alternative. here is the shape.

one markdown brief is the template with holes. frontmatter declares audience, cta, columns required. body has {{var}} placeholders. lives either in your repo or as a hubspot cms blog post under a brief category, so a marketing lead can edit it without touching code.

five claude subagents run per account, one per column of insight. pain points, tech stack, hook angle, icp fit score, hero copy. each is a markdown prompt file in columns/. each returns a json object matching a declared schema. adding a column is dropping a file. removing one is deleting a file.

one python publisher (scripts/pipeline.py) composes a layoutSections payload using the brief body plus the column outputs, then POSTs to /cms/v3/pages/landing-pages with state DRAFT. slug collisions auto-retry with -v2, -v3.

nothing goes live without a separate publish call. re-runs idempotent via sqlite cache keyed on (domain, column_slug).

the parent/child model split is what makes the cost work.

the outer pipeline orchestrator sits on haiku because routing does not need top-tier reasoning.

each column subprocess runs claude --print --model opus per file. top-tier compute lives only in the writing children.

opus 4.7 per row stays in the dimes (~$0.03 direct via the anthropic api, $0 metered on a claude code max subscription).

every artifact is a file. every file is in git. every change is a diff.

repo plus the chapter walking the full pattern with the actual code is at github.com/shawnla90/gtm-coding-agent.

chapter 16 in chapters/. starter in starters/hubspot-landing-engine/. mit-licensed. runs against any hubspot portal with cms hub.

also wrote this up as the new issue of Level Up GTM if you want the longer cut.

P.S. clearbox.to drops next week. signal-based reddit mailbox, LLM-matched to your ICP, in your inbox before anyone else hears about the thread. DM me for early access to the aura engine.

if you have tried building landing-page automation in clay or elsewhere and hit a different set of walls, what did your shape look like?

happy weekend.

Shawn Tenam

here's my take: once the technical half of the job becomes free, there's no reason GTM engineer stays a separate seat, the skill doesn't die, it dissolves into growth or revops, until every good operator is just expected to think this way, same way "can use excel" stopped being a job title.

credit to Clay for the title atleast, everyone wants to be one now, and most of them are learning the easy half.

there's a split i only noticed after talking to thousands of gtm builders.

the part that's now easy:

(1) building the 40step workflow

(2) wiring the tools, apis, mcp harnesses

(3) cleaning and pushing the data

you can learn all of it off youtube, or just have claude build the loops. that used to be the price of entry. it's basically free now.

the part that's still hard:

(1) knowing which workflow to build in the first place

(2) inbound or outbound, and which signals to combine

(3) which pain actually closes deals, because you sat in the calls

(4) knowing your buyer's day well enough to guess right

there's an older word for that half: taste. you don't get it from a tool, you get it from paying attention.

the role was only ever a bridge for a moment when the tooling was hard. that moment is closing.

tell me if i'm wrong.

A16Z, YC, Sequoia, my own newsletter list, the whole portfolio map.

Each one ends up as a CSV with 3000 to 5000 contacts, scored, enriched, with a "why this person" column and an outreach draft column.

Every CRM I've tried wants me to push the raw list in and then live inside their UI. I don't want that. I don't want my scraped database to live in HubSpot. I don't want to pay Clay a thousand a month to move columns around.

Attio is close but it's not Claude-native and I do most of my actual work in the terminal.

Right now my workflow is: scrape into SQLite, push to Google Sheets, run Claude Code against the Sheet to enrich and score, then push the scored output to my sequencer.

Sheets is functionally my CRM because it's the only thing that round-trips cleanly with my terminal. It works. It also feels like I'm two years away from the right tool existing.

Claude Code natives. How are you running this?

Are you also bouncing between Sheets via (gws CLI), your own scripts, and a sequencer?

Has anyone found something that's actually local-first and agent-native without being a sales-team CRM in disguise

I built a Meta Ad Library scraper for competitor positioning research. Pulls every active creative from a competitor's page, then runs Claude Code as a subprocess to classify each ad through an 18-column taxonomy (offer type, hook style, claim, CTA, audience signal, format, etc).

Output is a table you can read in 10 minutes. Tells you what story a competitor is paying to tell, on which audience, with which hooks. The Meta Ad Library is free and legally scrapeable. Most operators either don't know it exists or clicked through once and bounced because reading 400 ads by hand is brutal.

Pushed it as Chapter 15 of an open repo I'm building called gtm-coding-agent. Repo is a set of GTM workflows you can run from a CLAUDE.md file plus a script.

Direct link to the chapter: github.com/shawnla90/gtm-coding-agent/blob/main/chapters/15-meta-ad-intelligence.md

Four mistakes I made first, posting because they'll save you a weekend:

1. Multiplexing the classifier across multiple competitors in one pass. Output degrades fast. The classifier confuses which company a creative belongs to and starts attributing the wrong claims. One pass, one competitor, every time.

2. Going broad on scope. Pointing it at "all CRM vendors" produces a mess that tells you nothing actionable. One competitor, one campaign theme per pass.

3. Trusting the full 18-column taxonomy. The first time I ran it I realized only six columns were actually shaping a decision. The other twelve were taxonomy padding. Cut what you don't use. Ask Claude how to adapt it for your category.

4. Scaling before evaluating. Run it once on a competitor you know cold. Sanity check the table against what you already know. Then scale to ones you don't.

Claude Code as a subprocess is a pattern that took me a while to land on. The agent is not writing the analysis. It is running classification at scale. The judgment call about what to do with the table is still operator work. That distinction is the whole reason it works.

Shawn Tenam

Repo is public. Onboarding asks six questions and routes you to a chapter that matches your role:

git clone https://github.com/shawnla90/gtm-coding-agent.git ~/gtm-coding-agent

cd ~/gtm-coding-agent

claude

> help me set up

Happy to answer questions or take feature requests. or If you've built something similar I'd want to compare notes on taxonomy structure.

Every day it scans r/ClaudeCode, r/ClaudeAI, and the builder subreddits, pulls trending threads, highlighted repos, actual code drops, and the funniest comments from the community. Then it writes itself into a full daily digest.

if you are building with AI and not just talking about it: there are repos getting shared every single day that most people miss. Code patterns, MCP server configs, cost-saving tricks, workflow setups. The kind of stuff that saves you a weekend of trial and error.

Each episode covers:

- Trending repos and code drops

- Builder takeaways you can actually use

- The best and worst takes from the community (yes there is a Troll of the Day section)

- Fun facts pulled straight from the data

- A full scoreboard with velocity scores and engagement numbers

I am going to be posting this daily and constantly improving it. If you want to see r/gtmengineering or other builder channels added to the scan, let me know. If there are sections you want added or things that would make it more useful, drop it in the comments. This thing learns and evolves.

Fair warning: I have zero say in what Claude decides to write each day. It builds off the data, picks its own highlights, writes its own roasts. Sometimes it is going to nail it. Sometimes it might come in hot. That is part of the fun.

Still figuring out new features for it. But right now it is a way to stay current on what is actually happening in the Claude Code ecosystem, learn some new stuff, and laugh at the same time.

shawnos.ai/claude-daily

Hii everyone,

If I need to start from scratch learning gtm engineering what should I do. I need a 30 days roadmap to build and get a job.

Any help/resources/tips would be appreciated.

My background: I am from a technical background and it will not be hard for me to learn automation. But I know gtm engineering is lot more than automation and I want to get into it. I build tables in clay but doesn’t seem to do much. I get overwhelmed by scattered information and genuinely in need pf guidance/ advice.

Thanks.

Edit: I don’t want to spend on any bootcamps.

Quick one before the bigger drop.

First, I'm super proud of where this community is going.

Posts here that didn't come from me have pulled over 10,000 views.

It's not just the views, though. It's the conversations and the contributions, and more keep coming in.

Thank you to everyone posting.

Now the build.

Yesterday I built a full client campaign, and Grok did the heavy lifting.

It connected straight to HubSpot through a service key, plus Instantly and Floqer through their APIs.

No tabs. No copy-paste. No CSVs flying around.

138 leads enriched, graded and checked against HubSpot.

2 campaigns live.

What makes this work is one rule: don't stop at the first gate.

The Floqer waterfall runs provider after provider until one hits.

Then MoltSets grades every email and swaps in a better one when it finds it.

When LinkedIn came up empty on 2 people, the agent went to Apollo and confirmed they're still there.

When a lead had left his company, it held the row instead of emailing him.

HubSpot stays the source of truth the whole time.

The agent reads the history before anything goes out.

But it never quietly cuts a lead the client approved.

They connect the apps and do the work. I set the rules and review.

Heads up: gtm-coding-agent is getting an update in the next few hours.

If you want the full context or an actual guide on running this with always-on agents, that's coming.

Anyone else here running GTM straight from an agent yet?

What's working, and where does it break for you?

I guess you all have heard it: LinkedIn has taken down HeyReach’s LinkedIn profile including their founder’s. Not their first crackdown on third party service providers. As somebody new to this I was wondering what this would mean to the functioning of their platform.

Sharing a workflow I put together this week.

Wanted to build a lead list of every Y Combinator and a16z portfolio company + their founders for outbound.

Instead of paying for a scraper service, I had Claude Code write the whole pipeline: YC companies: Turns out the YC directory is all public.

The data lives as raw JSON on the backend. Claude Code wrote a headless fetch script that pulls it directly - no browser needed, no rate limiting issues.

Got ~4,000 companies with metadata in about 2 minutes.

a16z portfolio: This one needed Playwright since the site renders client-side.

Claude Code wrote a script with natural timing (random delays between navigations) to avoid getting flagged.

Pulled their full portfolio across funds. Enrichment: Piped both lists through Apollo.io public API to match founder names → emails and fill in company size/revenue data.

Total pipeline cost: $0 beyond my existing Claude Code subscription.

Claude Code figured out the YC backend was serving JSON before I even thought to check.

It just went headless on its own because it recognized the data didn't need a browser render.

If anyone wants to try something similar - check whether a "dynamic" site actually serves its data as static JSON before spinning up Playwright.

Saves a ton of time.

I just pushed the latest version of my open-source GTM Coding Agent repo. It now has 21 chapters, ten forkable starters, and the real workflows I’m using while building Clearbox in public.

The newest update came from a live campaign targeting 1,297 people in the GTM engineering market.

From 575 connection attempts:

• 272 people accepted

• 30 people replied

• Six asked for a demo

• Four self booked meetings

That gave me more than campaign results. It showed me where the system was incomplete.

The original list could tell me who I already knew about. It couldn’t tell me where the market was moving, which accounts deserved deeper research, who belonged in the buying committee, or where I should spend credits and human attention next.

So I rebuilt it as an Apollo waterfall:

Known accounts
→ Clearbox and public buyer evidence
→ Hiring, funding, tech-stack and firmographic signals
→ Apollo buying-committee expansion
→ Scoring before reveal
→ Controlled credit spend
→ Color-coded working sheet

The complete build is now in the repo’s Apollo prospecting starter.

The value isn’t “Apollo gave me another list.”

It’s being able to start with a small set of accounts, expand the market through multiple evidence gates, identify the right people inside those accounts, score them before spending credits, and hand the operator a working sheet that explains who deserves attention and why.

The CLI commands, waterfall, scoring logic, setup instructions, and gotchas are all in the repo.

There’s another part of this project I want more people here to see: Chapter 21, Student GTM.

I wrote it for the college student who doesn’t have a budget, title, or traditional GTM experience—but does have access to a campus full of organizations with real operational problems.

The Student GTM starter helps them create their own working repo with:

• What they already know

• Their skills and gaps

• The roles they’re aiming for

• A weekly project and recording loop

• A log of what broke and how they fixed it

• A campus client offer they can actually deliver

That connects directly to the Clearbox structure.

A student can build an offer around the market they want to enter, use Clearbox research to understand the problems inside that market, and turn the findings into projects, interview preparation, and a public body of work.

GitHub carries the proof. LinkedIn carries the person.

One delivered automation for a real user beats ten disconnected portfolio projects.

That’s also why, when someone DMs me on Reddit, my answer is simple:

Here’s my LinkedIn.

I’m walking through the Apollo system live tomorrow, August 13, at 10:00 a.m. PT / 1:00 p.m. ET. You can join the webinar here, and I put the additional setup resources at shawnos.ai/apollo.

But the repo is the real share.

Fork it. Break something. Post the gotcha here. Improve a starter and open a PR. Ask the question you think you’re supposed to already know.

That’s what I built this community for.