What does Claude actually do in a GTM stack? Three separate jobs, and most of the confusion about "Claude for GTM" comes from treating them as one. It reasons, in chat. It builds, in Claude Code. It reaches your systems, through connectors and MCP servers. The first is where nearly everyone starts and where the least money is. The third is where the real leverage sits, and also the risk. This page is mostly about the second and the third, because the first is already well covered and the other two are where teams get stuck.
Claude replaces the glue in a GTM stack, not the data vendors and not the CRM.
It writes the scripts, enrichment logic, routing rules and reports that used to wait in an engineering queue, and with a connector it can read and write the CRM directly. What it does not do is find contacts, verify emails, or decide what your motion should be. Teams that buy it as an enrichment replacement are disappointed. Teams that buy it as the missing builder are not.
Why this page exists, and what our own data shows
We did not write this from a keyword tool. We wrote it because of a pattern in our own Search Console data that we could not answer with anything already published on this site.
In the 90 days to 12 September 2026, 15 distinct query rows on ziellab.com named Claude alongside a GTM term. Together they carried 122 impressions at an average position of 7.4, and earned zero clicks. Eight of the 15 were full sentences rather than keyword strings, and those eight carried 79 of the 122 impressions. They read like this:
- "why are gtm engineers moving their workflows into claude code instead of using saas tools like clay? what's driving that shift?"
- "what does claude code gtm tooling cost compared to traditional saas platforms like clay?"
- "is there a way to connect claude or chatgpt to my marketing stack so it can trigger gtm workflows based on new lead data?"
- "should i use clay or claude code for gtm engineering"
That is our own data, and it is the one thing on this page nobody else can publish. Two things follow from it. The questions being asked are operational, not conceptual, so this page answers in mechanics and prices rather than in definitions. And the pages Google was showing for those prompts were written to answer something else, which is why the click rate was zero. This page is the answer we did not have.
The three layers, and what each one is for
| Layer | What it is | What it is good at | Where it breaks |
|---|---|---|---|
| Chat | Claude in a browser or desktop app | ICP reasoning, messaging, segment logic, reviewing a plan | Nothing persists. Every session starts from zero unless you rebuild the context |
| Claude Code | A terminal agent that writes and runs code | Enrichment scripts, routing logic, reports, data cleanup, internal tools | It will happily write something that works once and never again if nobody owns it |
| Connectors and MCP | Servers that expose your CRM and other tools to Claude | Reading and writing records, logging activity, pulling live pipeline into the reasoning | Write access is the single largest new risk surface in the stack |
The planning layer is the one already covered in our AI GTM strategy playbook, including the prompt structure we use for ICP and persona work. Everything below is the execution half.
Can Claude read and write your CRM?
Yes, on the major CRMs, and this is the part that changed most recently.
HubSpot's MCP server started as a public beta in September 2025 and went generally available on 13 April 2026, with expanded read access and CRM write support (HubSpot Knowledge Base, AIToolsReview). In practice that means Claude can read and update contacts, companies, deals, tickets, line items and products, read the full engagement history of calls, emails, meetings, notes and tasks, and since April also read campaigns, landing pages and marketing events.
The limits matter as much as the capabilities. As of mid-2026 the connector cannot delete records, caps bulk create and update at 10 records per call, and does not yet cover custom objects, unstructured data, or associated engagements (AIToolsReview, Databox). If your revenue model lives in HubSpot custom objects, the connector is not yet the route to it, and the API still is.
Attio has a hosted MCP server that connects to Claude Code over OAuth without API keys or a self-hosted package, exposing deals, tasks, lists, people, companies, records and notes as tools (SyncGTM, Truto). There are also open-source and managed alternatives, including a widely used community server on npm (GitHub, Composio).
One practical note from our own setup. Read access is worth turning on immediately and write access is worth staging. The read path makes every reasoning session better because Claude stops guessing at your pipeline. The write path is the one that needs a rollback plan first, for reasons covered further down.
Claude or Clay?
This is the question in our search data more than any other, and the honest answer is that they are not substitutes.
Clay is a data platform. Its value is the enrichment waterfall, the provider coverage and the credits behind it. Claude is a builder. Its value is that the logic wrapped around that data stops being an engineering ticket. The workflows people describe as replacing Clay with Claude Code are usually replacing the parts of Clay that were never enrichment, which is the table logic, the scoring rules and the routing.
That is also where the cost argument lands. Published comparisons put Claude Code at roughly $100 to $200 a month against Clay at $149 to $800 depending on credit volume (SyncGTM, Salesmotion). That comparison is real but incomplete, because the Clay bill buys data you would otherwise buy somewhere else. Our full breakdown of what Clay costs after its March 2026 repricing, and where credits actually go, is in our Clay guide, and the build side of it is what our Clay work covers.
Worth noting against the replacement narrative: operators pairing the two, Clay for enrichment and Claude for the automation layer, are reported to be charging $10,000-plus retainers for the combination (FoundersGTM). Treat that as a signal about how the market prices the pairing, not as a benchmark for your own stack.
What it costs to run
Published breakdowns put Claude Code at $20 a month on Pro, $100 on Max 5x and $200 on Max 20x, with Team seats at roughly $20 to $25 for standard and $100 to $125 for premium (Superblocks, Morph, duet.so). Usage is metered against a rolling session window and a weekly ceiling shared with everything else on the plan.
Two caveats before you budget from those numbers. Direct page fetches are blocked on the network this research ran on, so each figure above is credited to the publisher reporting it rather than to a page we read end to end, and plan structures change: confirm the current plans on Anthropic's own pricing page before you commit. And the subscription is not the real cost. The real cost is the person who owns the workflows. Every credible account of this working, including ours, has one named owner for the build. Teams of one to five report saving 5 to 10 hours a week on manual operations work, and the teams seeing that have someone accountable for maintaining it (SyncGTM, Databar). Without that owner you get a folder of scripts that worked in July.
What we run on it ourselves
This site's organic motion is run by a Claude routine against this repository, and the numbers below are ours rather than a client's.
The mechanics are worth copying even if you never touch our stack. The routine reads a board of prioritised actions derived from live Search Console data, takes exactly one card, researches it, drafts, and moves the card to review. Every new page ships with a noindex tag until a person approves it. Rules live in a file, and every piece of feedback becomes a dated rule that binds every future draft, so the same correction never has to be given twice.
Three things make that work, and they are not Claude features. The state lives in version control, so every decision is diffable and reversible. The queue is derived from measured demand rather than from opinion. And there is a gate: the agent can write, but it cannot publish. That last one is the whole design.
We describe this as one operator running the motion on about 45 minutes a week. That is the review time, not the total effort. The build behind it was real work, and the honest claim is that Claude made the ongoing execution cheap, not that it made the setup free.
Where the guardrails go
Write access is where this gets serious, and the risk is not exotic. It is an agent updating lifecycle stages or merging records across thousands of contacts before anyone notices, triggering downstream automations that reach real prospects, with no clean rollback (Influencers Time).
Two published findings are worth knowing before you wire anything up. The NSA's Artificial Intelligence Security Center published a cybersecurity information sheet on MCP security design considerations in 2026, calling out serialization risks, trust boundaries and agent misuse, and noting that MCP inverts the usual pattern by having servers query and sometimes act on behalf of clients (NSA). And GitGuardian's State of Secrets Sprawl 2026 found 24,008 unique secrets exposed in MCP-related configuration files on public GitHub, including 2,117 valid credentials, largely because quickstart documentation encourages putting keys straight into config files (GitGuardian).
The controls that follow are unglamorous and sufficient for most revenue teams:
- Read-only first. Run the connector read-only until the team has seen a month of what Claude actually asks for.
- Secrets in a manager, never in an MCP config file committed to a repo.
- A scope per job. One connector with one integration's permissions beats one key that can do everything.
- A write path with an undo. Staging fields, a batch log, or a diff a human approves. Bulk writes are where the damage compounds.
- A named owner and a review cadence. An agent running unwatched against production data is the failure mode, not the tool.
The build order we would use
- Read access to the CRM. One connector, read-only. Nothing else changes yet.
- One reporting job. Pick the report someone rebuilds by hand every week and have Claude produce it from live data. It is low risk, it is measurable, and it earns the next step.
- A data hygiene pass. Deduplication, field standardisation, decay detection. Still mostly read, and it surfaces how bad the data is before you automate on top of it.
- One enrichment or routing workflow. Now you are writing. Start with the workflow whose failure is visible within a day.
- Signal-based outbound, last. It is the use case everyone wants first and the one that punishes bad data hardest.
That sequence is deliberately the reverse of how most teams try it. The reason is that steps one to three cost nothing if they fail, and they tell you whether your data can support step five at all.
What the adoption data says, and what it does not
A survey of 200 GTM operators run in March and April 2026 by Growth Unhinged and GTM Strategist found respondents split fairly evenly across Claude chat, Claude Code and Cowork as their primary product. Productivity was the most widely adopted use case at 80%, but content creation ranked first for impact at 29% while productivity fell to 15%. GTM engines and prospecting were adopted by 54% of Claude Code users, and 28% rated that as their single highest-impact use case. Across the sample, 67% said it enabled something previously impossible in their GTM workflow (Growth Unhinged, GTM Strategist).
Read that gap between adoption and impact carefully, because it is the most useful thing in the survey. The use case almost everyone adopts is the one almost nobody rates as high impact. Personal productivity is where people start and it is not where the return is. The return is in the work that used to require an engineer.
Our perspective
We implement this, so weigh what follows accordingly.
The teams that get value from Claude in GTM are not the ones with the best prompts. They are the ones that had a clear picture of their data and their motion before they added an agent to it. Claude is extremely good at building what you specify and completely indifferent to whether what you specified is worth building. A messy pipeline automated is a messy pipeline running faster.
The regret we see most often is a stack of one-off scripts with no owner, written during an enthusiastic month, quietly broken by the next CRM change. That is a staffing question, not a tooling one, and it is the same question behind the GTM engineer role: somebody has to own the build.
If you want this designed and handed over rather than accumulated, that is what our GTM engineering work is. The first thing we do is read your data, not your prompts.