How to Build a GTM agent on Claude

Before your first email goes out, someone on your team spends twenty minutes on the account. They open the company site, check headcount in a data tool, scan the funding history, look at the open roles, find the person who owns the problem you solve, find that person’s work email, and then write an opener that mentions something recent enough to prove a human looked. Forty accounts a week, and that is most of an SDR’s job.

This article shows you how to hand that job to an agent running on Claude. By the end, you will have Claude Code on your laptop, a short context file that says who you sell to, two skill files (one researches an account, while one drafts the first email), a Crustdata connector that gives the agent company and people records while it works, and a step that writes the result into your CRM. On each run, the agent searches for companies that match your ICP, pulls a record on each one, scores it, drafts an email for the ones that pass, and leaves the draft for you to send.

Most of that is fixed. Claude Code is the runtime, CLAUDE.md and skills are how you instruct it, and your CRM is where results land. The one choice you make is where the agent gets its company data, and that choice takes up most of this article because it decides whether the emails are right. Connecting Claude to live company data is a connector and a sign-in, not an integration project.

What does a GTM agent on Claude need?

A GTM agent on Claude has five parts. These are all decided for you, except for the data source.

• Claude Code is the terminal app that runs the agent on your own machine.

• CLAUDE.md is a plain text file naming who you sell to, what rules out an account, and how you sound.

• Skills are markdown files holding one task each, like researching an account or drafting a first email.

• An MCP connector, which you add yourself, is how current company data reaches the agent mid-run.

• Your CRM is where the finished record is stored.

Does Claude come with company data?

No, Claude does not come with company data – instead, what it has is training data, a snapshot of text gathered before a cutoff date, and the ability to reason over whatever you put in front of it. Only the second helps you prospect, because the snapshot is already months old on the day the model ships.

Plenty of things can change at a company in six months.

• People change jobs, move teams, or leave.

• Headcount rises or falls by a third after a raise or a round of layoffs.

• A funding round closes, and the new budget gets assigned to specific teams.

An agent working from training data alone will write a well-structured email to a director of demand generation who left eight months ago, at a company that has since doubled its sales team. Whoever opens it will spot the wrong name or the wrong headcount in the first line.

The model reasons fine. It lacks the records. Your agent needs to fetch a fresh record partway through a task, without anyone pasting anything into a chat window, so it needs a data API it can call on its own at the moment it needs the answer.

How do you connect any data source over MCP?

Connecting a data source to Claude means adding an MCP server entry, and any MCP-compatible client can do it. The entry is only a few lines – a name you choose, a URL the provider gives you, and an auth header if the provider requires one.

Save that once, and the agent can reach the source on every run afterward.

Most B2B data providers worth considering now publish a server. Clay, Explorium, LeadMagic, Exa, Apollo, and ZoomInfo all ship one, so MCP support will not narrow your choice.

Attaching a source takes a minute, and choosing which one to attach is the rest of this article.

Which calls should the agent make first?

An agent makes three kinds of calls, and they behave differently enough that the order changes what you pay.

• Discovery takes filters like industry, headcount range, or location, and returns a list of matching rows.

• Lookup takes an identifier you already have, such as a domain or a profile, and returns one full record.

• Watching takes a saved query and tells you when something changes, which runs on the API and pushes results to a webhook rather than answering a question in the moment.

Your loop uses discovery and lookup on every run, in that order. Filter with the discovery call first, then look up only the companies that pass the filter. Run it the other way around, and the agent pays full price for a record on every company in the search and then throws most of them away, and once the loop runs on its own, nobody is watching it do that.

Put the rule where the agent reads it on every run, in CLAUDE.md or in the skill that runs the loop: never enrich a company that has not passed the ICP filter. A rule in the instructions applies every time. A habit you apply on the runs you happen to check does not, and that is why enrichment cost is decided in your instructions rather than in the contract you sign with a provider.

The price difference is large. On Crustdata, a search result costs 0.03 credits per row, a person record costs 1 to 7 credits depending on which fields you ask for, and a company record costs 2 to 4. Take a search that returns 1,000 companies. Enrich them all, and the enrichment step alone costs at least 2,000 credits. Filter first, keep the 50 that fit, and you spend 30 credits on the search and 100 to 200 on the records. Credit costs vary by plan and entitlement.

Which data source should sit behind MCP?

The right data source is the one that serves the calls your loop makes. No provider is strongest at discovery, lookup, and watching at once, and choosing by reputation means paying for a layer, usually a UI, that your agent never touches.

Three types cover most of the market.

A workflow surface pools several providers behind one connection and gives you a table you can open, sort, and correct by hand. Pick it when a person needs to review the list before anything is sent. The cost is that your agent runs inside the platform’s sequencing rather than its own.

A web search API answers questions with no fixed schema, such as what a company said about its roadmap last quarter or how it describes its own customers. It returns pages, not records with stable IDs, so matching a result back to a CRM row is work your agent has to do itself.

A data API returns structured records and nothing else. Pick it when the agent reads the data and acts on it with no one reviewing a table in between. The filtering, scoring, and sequencing logic then lives in your CLAUDE.md and skills, and writing that logic is the price of controlling it.

There is a fourth option that costs nothing new. If your team already pays for seats on a sales intelligence platform, reusing that contract can beat signing another one, as long as you check the export ceiling first. Seat licenses cap how many records can leave the platform each month, and a loop that does not know about the cap stops partway through a run when it hits it.

Crustdata is a data API that answers with records and leaves the reasoning to your agent, which fits a loop that filters, enriches, and drafts without a person in the middle.

Connecting Crustdata over MCP

You add Crustdata as a custom connector and sign in. There is no API key to copy and no configuration file to write.

In Claude.ai or the desktop app, open Customize, go to Connectors, and choose Add custom connector. Name it Crustdata and paste this URL.

https://install.crustdata.com/mcp

In Claude Code, you need two commands for the install.

Then run /crustdata:login inside Claude Code. That opens a browser sign-in, and signing in authorizes the connection on its own, which is why nothing lands in a config file and no key needs storing or rotating. Backend jobs that run with nobody present use a bearer token against the same endpoint instead, which is a different setup for a different reader. If you would rather skip the browser sign-in, set CRUSTDATA_API_KEY in your environment, and the plugin uses it instead.

Both paths, in short.

• On Claude.ai and Desktop, add a custom connector pointing to the install URL.

• In Claude Code, add the marketplace, install the plugin, then run /crustdata:login.

Note: On either path, one sign-in stands in for the whole key management step.

Write the context file and load your skills

A CLAUDE.md file holds what the agent always knows, while skill files hold what it does on request.

Put four things in CLAUDE.md.

• Who you are: company, product, and the problem it solves, in two or three lines, so the agent knows who is writing.

• Your ICP, written as the same filters your discovery call accepts: industry, headcount range, location, funding stage, roles being hired. If a rule cannot be expressed as a search filter, the agent cannot apply it at the discovery step.

• Hard constraints, including the filter-before-enrich rule from the last section and anything that disqualifies an account, such as existing customers or competitors.

• How you sound, such as a line or two on tone, plus one example opener you would be happy to send.

Here's the whole thing as a template. Copy it into a file called CLAUDE.md at the root of your project, and fill in the brackets.

# CLAUDE.md

## Who we are

[Company] sells [product] to [buyer]. It solves [problem].

## ICP (written as discovery filters)

- Industry: [e.g. B2B SaaS]

- Headcount: [e.g. 50–200]

- Location: [e.g. US, UK]

- Funding stage: [e.g. Series A–B]

- Hiring signal: [e.g. open roles in RevOps]

## Hard constraints

- Never enrich a company that has not passed the ICP filter.

- Disqualify: existing customers, direct competitors, [others].

## How we sound

[One or two lines on tone.]

Example opener we'd send: "[paste a real one]"

Skills are separate markdown files, one task each. Community GTM skill packs install with a marketplace command, and the Crustdata plugin ships its own under /crustdata. 

The plugin installs eight skills under the /crustdata namespace, and three of them cover the loop this article describes. /crustdata:icp-builder turns one profile URL into your ICP, persona, and writing voice. /crustdata:sales-prospecting builds net-new lists and ranks accounts. /crustdata:sales-outreach drafts cold emails grounded in one recent signal. Run icp-builder once, then open the SKILL.md for sales-prospecting to see what a working skill looks like before writing your own. The source is at github.com/crustdata/skills.

One file you never have to write is the guide to the connector itself. The agent reads the server's own usage documentation at crustdata://catalog, so it does not re-derive the tool list on every run, and you do not have to describe the available calls in your own instructions.

What does a live data call actually return?

A lookup returns a structured record rather than a paragraph of enriched text, which is what makes the result usable by the next step in your loop without any parsing of prose. The response is an array with one envelope per identifier you sent. Each envelope records the identifier it matched on, the identifier type, a match status, and a confidence score, and the profile itself arrives nested inside it.

The nesting is the part to read carefully, because crustdata_person_id and updated_at are inside person_data rather than at the top of the response, and an agent instructed to read them off the envelope will come back empty on every call. Anything you want your skill to reference has to be addressed at the level it actually occupies.

Company records follow the same pattern. Crustdata also ships a separate command-line tool, installed independently of the plugin, and its enrich command shows the shape of the call plainly: you name the domain and the fields you want returned, which keeps the response to the parts your loop uses.

Field selection is an API parameter rather than something the agent negotiates in conversation, so the choice is made in the call, and the response comes back shaped accordingly.

Several billing rules shape how that call should be written. Email and phone data come from a separate contact endpoint rather than the profile lookup, and it bills per type per matched person: 1 credit for a business email, 2 for a personal email, 2 for a phone number. Leaving the fields parameter out requests all three at 5 credits, which is the easiest way to spend more than you meant to.

Contact enrichment also needs enterprise access, so a self-serve key returns a 403 no matter how the request is formed. A single request accepts up to 25 identifiers. Unmatched identifiers are not billed.

Discovery answers in a different shape entirely, returning many rows instead of one record, which is how a set of filters becomes a live target list the agent can work through in order.

What makes data live enough to act on?

A record is live enough when its last check still holds for the action the agent is about to take. That standard moves with the action. Sorting accounts by industry survives a record that has sat untouched for months. Sending an email that names someone's job does not.

Two questions settle it with any provider.

• When was this record last checked?

• What forces a new check?

The second question is the one that gets skipped, and it is where answers differ most. Some records only refresh on a schedule. Others refresh when the agent asks for them.

Speed is a separate matter. An API can answer in 200 milliseconds and hand back something checked in March, which is the line real-time and batch enrichment divide on. Fast response times describe the pipe rather than the contents.

On Crustdata, a record can carry an updated_at timestamp showing its most recent profile refresh, though the field is nullable and some records arrive without one. Person enrichment serves from the stored dataset. The live calls, which fetch from the web at request time, cover a company's current job openings, live person and company search, and a live person enrich at 7 credits a profile. All of them are gated by plan, so check what your entitlement covers before a skill depends on one.

Score the account, draft the email, update the CRM

With the record in hand, the agent scores it against your ICP, drafts the outreach, and writes the result back to your CRM.

Scoring criteria belong in the context file or in a skill, and the score comes back as structured output, so the drafting step can read it without guessing. Anything that fails the bar stops there.

Drafting then works from the fields the call returned. A line about a company's hiring push traces back to a record rather than to something the model half remembers, which is the difference between a specific opener and a plausible one.

Drafts stay review-gated. Nothing sends on its own.

The CRM write-back closes the loop into a system you already run: the agent writes the result back through your CRM's own connector, so there is no integration to build here. Deeper scoring pipelines are their own subject and sit outside this build.

What breaks when the agent runs unattended?

An unattended agent fails on a stale record, and the failure is quiet enough that you usually learn about it from a reply rather than from a log. The agent scores a company on headcount pulled weeks earlier, drafts an opener about a hiring push that has since closed, and sends it into a queue nobody is reading that morning. 

Rate limits and repeated writes deserve a mention here as well, though both are well-understood problems with well-understood fixes, whereas a record that stopped being true has nothing in the loop to catch it.

The answer is a second surface alongside the one you already connected. Your connector responds to questions the agent asks, while a watcher pushes matches to a webhook and starts work nobody requested, which is the difference between an agent that checks when told and a build that reacts when something moves. 

Five watchers are available, covering company entities, person entities, company discovery, person discovery, and jobs. Each delivers to a webhook, Slack, Google Chat, or email, and one watch can fan out to several channels at once.

Funding and hiring are the two signals that repay the setup effort most reliably, since both change the reason for an outreach rather than only the details inside it. How to track hiring signals covers what a watcher takes off your hands once it is running.

Point the agent at live data

Four of the five parts of a GTM agent on Claude are decided before you start. The fifth is the data source, and the right one follows from what the agent does: filters lists, looks up known records, or waits on a change.

Crustdata is a B2B data API that Claude searches, enriches, and analyzes over MCP, returning structured company and person records that the agent can act on directly.

Add it as a connector, sign in once, and point your first skill at a domain you already know well. The record that comes back will tell you quickly whether the loop is worth building out.

Explore Crustdata’s Claude Code plugin today!

Common questions

Can you build a GTM agent on Claude without writing code?

Mostly yes. You write a context file, edit some skill files, and sign in to the connector. Code only enters for custom work.

Can the agent run without your terminal open?

Not on a local install. Unattended runs need a hosted runtime, which is this same build with a different runner behind it.

What do sub-agents change?

They keep heavy tasks out of the main context. Research, scoring, and drafting each run in their own space, so a long research pass does not crowd out the drafting step.

Before your first email goes out, someone on your team spends twenty minutes on the account. They open the company site, check headcount in a data tool, scan the funding history, look at the open roles, find the person who owns the problem you solve, find that person’s work email, and then write an opener that mentions something recent enough to prove a human looked. Forty accounts a week, and that is most of an SDR’s job.

This article shows you how to hand that job to an agent running on Claude. By the end, you will have Claude Code on your laptop, a short context file that says who you sell to, two skill files (one researches an account, while one drafts the first email), a Crustdata connector that gives the agent company and people records while it works, and a step that writes the result into your CRM. On each run, the agent searches for companies that match your ICP, pulls a record on each one, scores it, drafts an email for the ones that pass, and leaves the draft for you to send.

Most of that is fixed. Claude Code is the runtime, CLAUDE.md and skills are how you instruct it, and your CRM is where results land. The one choice you make is where the agent gets its company data, and that choice takes up most of this article because it decides whether the emails are right. Connecting Claude to live company data is a connector and a sign-in, not an integration project.

What does a GTM agent on Claude need?

A GTM agent on Claude has five parts. These are all decided for you, except for the data source.

• Claude Code is the terminal app that runs the agent on your own machine.

• CLAUDE.md is a plain text file naming who you sell to, what rules out an account, and how you sound.

• Skills are markdown files holding one task each, like researching an account or drafting a first email.

• An MCP connector, which you add yourself, is how current company data reaches the agent mid-run.

• Your CRM is where the finished record is stored.

Does Claude come with company data?

No, Claude does not come with company data – instead, what it has is training data, a snapshot of text gathered before a cutoff date, and the ability to reason over whatever you put in front of it. Only the second helps you prospect, because the snapshot is already months old on the day the model ships.

Plenty of things can change at a company in six months.

• People change jobs, move teams, or leave.

• Headcount rises or falls by a third after a raise or a round of layoffs.

• A funding round closes, and the new budget gets assigned to specific teams.

An agent working from training data alone will write a well-structured email to a director of demand generation who left eight months ago, at a company that has since doubled its sales team. Whoever opens it will spot the wrong name or the wrong headcount in the first line.

The model reasons fine. It lacks the records. Your agent needs to fetch a fresh record partway through a task, without anyone pasting anything into a chat window, so it needs a data API it can call on its own at the moment it needs the answer.

How do you connect any data source over MCP?

Connecting a data source to Claude means adding an MCP server entry, and any MCP-compatible client can do it. The entry is only a few lines – a name you choose, a URL the provider gives you, and an auth header if the provider requires one.

Save that once, and the agent can reach the source on every run afterward.

Most B2B data providers worth considering now publish a server. Clay, Explorium, LeadMagic, Exa, Apollo, and ZoomInfo all ship one, so MCP support will not narrow your choice.

Attaching a source takes a minute, and choosing which one to attach is the rest of this article.

Which calls should the agent make first?

An agent makes three kinds of calls, and they behave differently enough that the order changes what you pay.

• Discovery takes filters like industry, headcount range, or location, and returns a list of matching rows.

• Lookup takes an identifier you already have, such as a domain or a profile, and returns one full record.

• Watching takes a saved query and tells you when something changes, which runs on the API and pushes results to a webhook rather than answering a question in the moment.

Your loop uses discovery and lookup on every run, in that order. Filter with the discovery call first, then look up only the companies that pass the filter. Run it the other way around, and the agent pays full price for a record on every company in the search and then throws most of them away, and once the loop runs on its own, nobody is watching it do that.

Put the rule where the agent reads it on every run, in CLAUDE.md or in the skill that runs the loop: never enrich a company that has not passed the ICP filter. A rule in the instructions applies every time. A habit you apply on the runs you happen to check does not, and that is why enrichment cost is decided in your instructions rather than in the contract you sign with a provider.

The price difference is large. On Crustdata, a search result costs 0.03 credits per row, a person record costs 1 to 7 credits depending on which fields you ask for, and a company record costs 2 to 4. Take a search that returns 1,000 companies. Enrich them all, and the enrichment step alone costs at least 2,000 credits. Filter first, keep the 50 that fit, and you spend 30 credits on the search and 100 to 200 on the records. Credit costs vary by plan and entitlement.

Which data source should sit behind MCP?

The right data source is the one that serves the calls your loop makes. No provider is strongest at discovery, lookup, and watching at once, and choosing by reputation means paying for a layer, usually a UI, that your agent never touches.

Three types cover most of the market.

A workflow surface pools several providers behind one connection and gives you a table you can open, sort, and correct by hand. Pick it when a person needs to review the list before anything is sent. The cost is that your agent runs inside the platform’s sequencing rather than its own.

A web search API answers questions with no fixed schema, such as what a company said about its roadmap last quarter or how it describes its own customers. It returns pages, not records with stable IDs, so matching a result back to a CRM row is work your agent has to do itself.

A data API returns structured records and nothing else. Pick it when the agent reads the data and acts on it with no one reviewing a table in between. The filtering, scoring, and sequencing logic then lives in your CLAUDE.md and skills, and writing that logic is the price of controlling it.

There is a fourth option that costs nothing new. If your team already pays for seats on a sales intelligence platform, reusing that contract can beat signing another one, as long as you check the export ceiling first. Seat licenses cap how many records can leave the platform each month, and a loop that does not know about the cap stops partway through a run when it hits it.

Crustdata is a data API that answers with records and leaves the reasoning to your agent, which fits a loop that filters, enriches, and drafts without a person in the middle.

Connecting Crustdata over MCP

You add Crustdata as a custom connector and sign in. There is no API key to copy and no configuration file to write.

In Claude.ai or the desktop app, open Customize, go to Connectors, and choose Add custom connector. Name it Crustdata and paste this URL.

https://install.crustdata.com/mcp

In Claude Code, you need two commands for the install.

Then run /crustdata:login inside Claude Code. That opens a browser sign-in, and signing in authorizes the connection on its own, which is why nothing lands in a config file and no key needs storing or rotating. Backend jobs that run with nobody present use a bearer token against the same endpoint instead, which is a different setup for a different reader. If you would rather skip the browser sign-in, set CRUSTDATA_API_KEY in your environment, and the plugin uses it instead.

Both paths, in short.

• On Claude.ai and Desktop, add a custom connector pointing to the install URL.

• In Claude Code, add the marketplace, install the plugin, then run /crustdata:login.

Note: On either path, one sign-in stands in for the whole key management step.

Write the context file and load your skills

A CLAUDE.md file holds what the agent always knows, while skill files hold what it does on request.

Put four things in CLAUDE.md.

• Who you are: company, product, and the problem it solves, in two or three lines, so the agent knows who is writing.

• Your ICP, written as the same filters your discovery call accepts: industry, headcount range, location, funding stage, roles being hired. If a rule cannot be expressed as a search filter, the agent cannot apply it at the discovery step.

• Hard constraints, including the filter-before-enrich rule from the last section and anything that disqualifies an account, such as existing customers or competitors.

• How you sound, such as a line or two on tone, plus one example opener you would be happy to send.

Here's the whole thing as a template. Copy it into a file called CLAUDE.md at the root of your project, and fill in the brackets.

# CLAUDE.md

## Who we are

[Company] sells [product] to [buyer]. It solves [problem].

## ICP (written as discovery filters)

- Industry: [e.g. B2B SaaS]

- Headcount: [e.g. 50–200]

- Location: [e.g. US, UK]

- Funding stage: [e.g. Series A–B]

- Hiring signal: [e.g. open roles in RevOps]

## Hard constraints

- Never enrich a company that has not passed the ICP filter.

- Disqualify: existing customers, direct competitors, [others].

## How we sound

[One or two lines on tone.]

Example opener we'd send: "[paste a real one]"

Skills are separate markdown files, one task each. Community GTM skill packs install with a marketplace command, and the Crustdata plugin ships its own under /crustdata. 

The plugin installs eight skills under the /crustdata namespace, and three of them cover the loop this article describes. /crustdata:icp-builder turns one profile URL into your ICP, persona, and writing voice. /crustdata:sales-prospecting builds net-new lists and ranks accounts. /crustdata:sales-outreach drafts cold emails grounded in one recent signal. Run icp-builder once, then open the SKILL.md for sales-prospecting to see what a working skill looks like before writing your own. The source is at github.com/crustdata/skills.

One file you never have to write is the guide to the connector itself. The agent reads the server's own usage documentation at crustdata://catalog, so it does not re-derive the tool list on every run, and you do not have to describe the available calls in your own instructions.

What does a live data call actually return?

A lookup returns a structured record rather than a paragraph of enriched text, which is what makes the result usable by the next step in your loop without any parsing of prose. The response is an array with one envelope per identifier you sent. Each envelope records the identifier it matched on, the identifier type, a match status, and a confidence score, and the profile itself arrives nested inside it.

The nesting is the part to read carefully, because crustdata_person_id and updated_at are inside person_data rather than at the top of the response, and an agent instructed to read them off the envelope will come back empty on every call. Anything you want your skill to reference has to be addressed at the level it actually occupies.

Company records follow the same pattern. Crustdata also ships a separate command-line tool, installed independently of the plugin, and its enrich command shows the shape of the call plainly: you name the domain and the fields you want returned, which keeps the response to the parts your loop uses.

Field selection is an API parameter rather than something the agent negotiates in conversation, so the choice is made in the call, and the response comes back shaped accordingly.

Several billing rules shape how that call should be written. Email and phone data come from a separate contact endpoint rather than the profile lookup, and it bills per type per matched person: 1 credit for a business email, 2 for a personal email, 2 for a phone number. Leaving the fields parameter out requests all three at 5 credits, which is the easiest way to spend more than you meant to.

Contact enrichment also needs enterprise access, so a self-serve key returns a 403 no matter how the request is formed. A single request accepts up to 25 identifiers. Unmatched identifiers are not billed.

Discovery answers in a different shape entirely, returning many rows instead of one record, which is how a set of filters becomes a live target list the agent can work through in order.

What makes data live enough to act on?

A record is live enough when its last check still holds for the action the agent is about to take. That standard moves with the action. Sorting accounts by industry survives a record that has sat untouched for months. Sending an email that names someone's job does not.

Two questions settle it with any provider.

• When was this record last checked?

• What forces a new check?

The second question is the one that gets skipped, and it is where answers differ most. Some records only refresh on a schedule. Others refresh when the agent asks for them.

Speed is a separate matter. An API can answer in 200 milliseconds and hand back something checked in March, which is the line real-time and batch enrichment divide on. Fast response times describe the pipe rather than the contents.

On Crustdata, a record can carry an updated_at timestamp showing its most recent profile refresh, though the field is nullable and some records arrive without one. Person enrichment serves from the stored dataset. The live calls, which fetch from the web at request time, cover a company's current job openings, live person and company search, and a live person enrich at 7 credits a profile. All of them are gated by plan, so check what your entitlement covers before a skill depends on one.

Score the account, draft the email, update the CRM

With the record in hand, the agent scores it against your ICP, drafts the outreach, and writes the result back to your CRM.

Scoring criteria belong in the context file or in a skill, and the score comes back as structured output, so the drafting step can read it without guessing. Anything that fails the bar stops there.

Drafting then works from the fields the call returned. A line about a company's hiring push traces back to a record rather than to something the model half remembers, which is the difference between a specific opener and a plausible one.

Drafts stay review-gated. Nothing sends on its own.

The CRM write-back closes the loop into a system you already run: the agent writes the result back through your CRM's own connector, so there is no integration to build here. Deeper scoring pipelines are their own subject and sit outside this build.

What breaks when the agent runs unattended?

An unattended agent fails on a stale record, and the failure is quiet enough that you usually learn about it from a reply rather than from a log. The agent scores a company on headcount pulled weeks earlier, drafts an opener about a hiring push that has since closed, and sends it into a queue nobody is reading that morning. 

Rate limits and repeated writes deserve a mention here as well, though both are well-understood problems with well-understood fixes, whereas a record that stopped being true has nothing in the loop to catch it.

The answer is a second surface alongside the one you already connected. Your connector responds to questions the agent asks, while a watcher pushes matches to a webhook and starts work nobody requested, which is the difference between an agent that checks when told and a build that reacts when something moves. 

Five watchers are available, covering company entities, person entities, company discovery, person discovery, and jobs. Each delivers to a webhook, Slack, Google Chat, or email, and one watch can fan out to several channels at once.

Funding and hiring are the two signals that repay the setup effort most reliably, since both change the reason for an outreach rather than only the details inside it. How to track hiring signals covers what a watcher takes off your hands once it is running.

Point the agent at live data

Four of the five parts of a GTM agent on Claude are decided before you start. The fifth is the data source, and the right one follows from what the agent does: filters lists, looks up known records, or waits on a change.

Crustdata is a B2B data API that Claude searches, enriches, and analyzes over MCP, returning structured company and person records that the agent can act on directly.

Add it as a connector, sign in once, and point your first skill at a domain you already know well. The record that comes back will tell you quickly whether the loop is worth building out.

Explore Crustdata’s Claude Code plugin today!

Common questions

Can you build a GTM agent on Claude without writing code?

Mostly yes. You write a context file, edit some skill files, and sign in to the connector. Code only enters for custom work.

Can the agent run without your terminal open?

Not on a local install. Unattended runs need a hosted runtime, which is this same build with a different runner behind it.

What do sub-agents change?

They keep heavy tasks out of the main context. Research, scoring, and drafting each run in their own space, so a long research pass does not crowd out the drafting step.