- Claygent reads live web pages for every row in a Clay table and writes typed columns back, so judgment work becomes a column instead of an SDR's browser tabs.
- Clay's own models are fixed price per row: Helium 1 data credit, Neon 2, Argon 3, plus 1 action per row.
- On the $167 Launch plan that is roughly $0.06 to $0.17 a researched row, and the 3,000 monthly data credit allowance binds long before the 15,000 action allowance does.
- Prompts that hold up at scale name the source, define the decision rule numerically, declare typed output fields, and specify a NOT_FOUND fallback.
- Six chained recipes cost 12 credits an account, roughly $0.67, and replace eight to ten minutes of manual research per account.
Claygent is Clay's AI research agent. You give it a prompt and a few input columns, it reads live web pages row by row, and it writes structured answers back into your table. Clay's own models cost 1 to 3 data credits per row, which works out to roughly $0.06 to $0.17 per researched account on the $167 Launch plan.
TL;DR: Summary
- Claygent runs one prompt per row against live pages and writes typed columns back into the table, so research that used to be an SDR switching browser tabs becomes a column that fills itself.
- Clay's three in-house models are priced per row: Helium at 1 data credit, Neon at 2, Argon at 3. Every row also consumes 1 action on top of the credits.
- On the Launch plan and its 3,000 monthly data credits, that is 3,000 Helium rows, 1,500 Neon rows, or 1,000 Argon rows a month, so roughly $0.06 to $0.17 a row.
- Every prompt that returns clean data has the same five parts: a role, a named source to read, a decision rule, typed output fields, and an explicit fallback value for not found.
- Claygent is a research layer that sits on top of your data providers. It reads pages no provider indexed, and it fails on login walls, heavy JavaScript, and anything behind a paywall.
Most teams meet Claygent as a novelty, ask it a vague question like "what does this company do", get a paragraph of mush in a cell, and never use it again. The teams getting value from it treat it as a typed data pipeline with a research step in the middle. The difference is entirely in how the prompt is written and which model is doing the reading.
| Model | Data credits / row | Best for | Avoid for |
|---|---|---|---|
| Helium | 1 | Single-fact lookups on one page, run at volume | Multi-part questions, judgment calls |
| Neon | 2 | Qualification, several typed columns from one page | Research needing several clicks |
| Argon | 3 | Deep research, long documents, multi-step reading | High-volume yes or no checks |
| Frontier models | Variable, by tokens | Unusual reasoning tasks, long outputs | Anything where the bill must be predictable |
What is Claygent?
Claygent is the AI agent inside Clay that performs open-ended research on each row of a table. A normal enrichment asks a provider for a field that already exists in a database. Claygent goes and reads pages to produce a field that exists nowhere, then writes it into columns you define.
The practical shape of it is a prompt, a set of input variables from other columns, a choice of model, and a set of output fields with data types. Clay counts more than 5 billion Claygent runs to date, and the agent is available on every plan including the free tier.
The part worth internalising is that Claygent produces columns, not prose. When you define output fields with types, text, number, true or false, URL, select, or email, the answers become filterable and usable as conditions for the rest of your workflow. When you leave the output as one free-text blob, you get something readable by a human and useless to a machine, which is why most first attempts feel underwhelming.
How Claygent differs from Clay's AI formula columns
Clay has a simpler AI column that reasons over data already sitting in your table. It does not browse. Claygent browses, follows links, and reads what it finds, which is the whole reason it costs more per row and takes longer to finish.
The rule we use: if the answer is already somewhere in the row, use the cheap AI column. If the answer only exists on a page somewhere on the internet, use Claygent. Teams that ignore this distinction end up paying browsing prices to reformat data they already had.
How does Claygent actually work on a row?
Claygent takes the input variables you map from other columns, resolves a source to read, fetches and parses the page, reasons over the text against your instructions, and writes each answer into its matching output field. If a field cannot be filled, it returns empty unless you told it what to return instead.
Two configuration choices change the output more than the prompt wording does. The first is whether you hand it a specific URL or let it search. Handing it {{company_domain}}/pricing gets a far more consistent answer than asking it to find the pricing page itself, because you have removed the step where it can go wrong. The second is whether web search is enabled, which matters for anything time-sensitive like funding, launches, or news.
Clay's agent builder also gives you a free test bench. You can run up to 10 test inputs without spending credits, compare two models side by side on the same rows, and roll back to any earlier version of the prompt. Every prompt in this article was written the same way: draft, test on 10 deliberately messy rows, fix the fallbacks, then deploy to the table.
What does Claygent cost per 1,000 rows?
Between about $56 and $167 per 1,000 rows on the Launch plan, depending on the model. The data credit allowance is the constraint that bites first, well before the action allowance does.
Clay bills two separate meters. Actions cover the orchestration, one per enrichment run per row. Data credits cover the data or the model call. Clay's in-house Claygent models are fixed price per row, so the arithmetic is predictable, while frontier models bill by token consumption and are not.
| Model | Credits for 1,000 rows | Share of monthly credits | Approx. cost / 1,000 | Approx. cost / row |
|---|---|---|---|---|
| Helium | 1,000 | 33% | ~$56 | ~$0.06 |
| Neon | 2,000 | 67% | ~$111 | ~$0.11 |
| Argon | 3,000 | 100% | ~$167 | ~$0.17 |
| Three chained Neon steps | 6,000 | 200% | ~$334 | ~$0.33 |
Costs are derived from published Clay pricing as of August 2026: Free at $0 with 500 actions and 100 data credits, Launch at $167 a month with 15,000 actions and 3,000 data credits, Growth at $446 with 40,000 actions and 6,000 data credits. Divide the plan price by its credit allowance and you get the effective credit price.
That division produces a result worth knowing before you upgrade. Launch works out near $0.056 a data credit and Growth near $0.074, so moving up a tier buys you a much larger action allowance and slightly more expensive credits. If Claygent volume is what is squeezing you rather than table runs and exports, buying credits is the thing to solve, and the cheaper lever is usually model choice.
The habit that actually controls the bill is conditional running. Filter the table so Claygent only touches rows that passed a cheaper check first. A list of 10,000 accounts filtered down to the 1,200 with a live careers page costs a fifth of running Argon across all of them, and the 8,800 rows you skipped were the ones that would have returned nothing anyway.
How do you write a Claygent prompt that returns clean data?
Every prompt that survives contact with a real list has five parts: a role, a named source, a decision rule, typed output fields, and a fallback value. Drop any one of them and you get the specific failure that part was preventing.
The role sets the standard of evidence. A single line like "you only report what you can read on the page" cuts invented answers more than any other instruction, because the alternative behaviour, guessing plausibly, is the default.
The named source removes the search step. Pass the exact URL when you know its shape. Ask for a search only when the page location genuinely varies between companies.
The decision rule is where you move judgment out of the model and into your own criteria. "Is this a good fit" produces a different answer every row. "Count open roles whose titles contain SDR, BDR, or Account Executive, and return strong at 3 or more" produces the same answer every time.
Typed output fields turn the answer into data. Name each field in the prompt and tell the agent what belongs in it, because defining the fields in the interface without naming them in the prompt is the most common reason columns come back empty.
The fallback value is the part almost everyone forgets. Without it, a failed row and a genuine negative both look like an empty cell, and you cannot tell whether the company has no open roles or whether the careers page timed out. Ask for a literal NOT_FOUND and the difference becomes visible and filterable.
Three Claygent recipes for account research
These three run first in our tables and produce the inputs the personalization recipes depend on. Each one is written to be pasted in and edited, with the model and the per-row cost noted so you can budget before you run.
1. Hiring signals that prove someone owns outbound
The most reliable buying signal for outbound services is a company already paying people to do outbound. This recipe reads the careers page and turns it into a filterable tier rather than a summary.
ROLE
You are a B2B research analyst. You report only what you can read on a page.
TASK
Read {{company_domain}}/careers and any job board it links to. Decide whether
this company is hiring roles that indicate it owns outbound pipeline.
DECISION RULE
Count only open roles whose titles contain: SDR, BDR, Sales Development,
Account Executive, Demand Generation, Growth Marketing, or GTM Engineer.
Ignore support, engineering, finance, and HR roles.
OUTPUT FIELDS
gtm_open_roles (Number) count of matching open roles
top_role_title (Text) exact title of the most senior matching role
careers_url (URL) the page you read
hiring_signal (Select) strong / weak / none
strong = 3 or more matching roles
weak = 1 or 2 matching roles
none = 0 matching roles
RULES
Use the exact titles printed on the page. Do not infer roles from the homepage.
If the careers page does not load or lists no roles, return NOT_FOUND in every
text field and 0 in gtm_open_roles. Two details do the work here. Listing the exact title strings removes the model's opinion about what counts as a sales role, and the numeric thresholds mean the tier is reproducible if you rerun the table next quarter. For the wider set of signals worth reading this way, see our guide to buying signals in B2B.
2. Pricing model and entry price, with a verbatim quote
Whether a company sells self-serve or through a sales team changes your offer, your sender, and your call to action. It is also one of the few facts almost no data provider carries, and it sits in plain text on a page.
ROLE
You are a pricing analyst. Every claim you make must be supported by a
sentence printed on the page you read.
TASK
Read {{company_domain}}/pricing. If that page does not exist, read the pricing
page linked from the main navigation. Classify how this company sells.
OUTPUT FIELDS
pricing_model (Select) self-serve / sales-led / hybrid / not published
self-serve = a plan can be bought without contact
sales-led = every tier requires a demo or a quote
hybrid = both a buyable tier and a quoted tier
entry_price_usd (Number) lowest published monthly price, USD, excluding free
billing_unit (Text) per seat / per workspace / usage based / NOT_FOUND
pricing_url (URL) the page you read
evidence_quote (Text) one verbatim sentence that supports pricing_model
RULES
evidence_quote must appear word for word on the page. Do not paraphrase.
If pricing is only available by contacting sales, return sales-led and leave
entry_price_usd empty. If no pricing page exists, return not published and
NOT_FOUND in every text field. The evidence_quote field is a verification mechanism disguised as a data field. Skim 20 quotes against 20 pages and you know your accuracy rate for the whole column in about ten minutes, which is the only honest way to trust a research column before you send anything off the back of it.
3. Integration and tech verification that refuses to guess
This is the one that needs Argon. Confirming a company genuinely integrates with a specific platform usually means reading a docs page, then a marketplace listing, then a changelog, and holding the answer across all three.
ROLE
You are a technical researcher. You never state that something exists
without a first-party page that names it.
TASK
Determine whether {{company_name}} ({{company_domain}}) has a documented
native integration with {{target_platform}}.
SEARCH ORDER
1. The company's own integrations, docs, or app directory pages.
2. {{target_platform}}'s marketplace or partner directory listing.
3. The company's changelog or release notes.
Stop as soon as you find first-party confirmation.
OUTPUT FIELDS
integration_exists (True/False)
evidence_url (URL) the single strongest page you found
evidence_quote (Text) verbatim line naming the integration
confidence (Select) high / medium / low
high = company or platform page names it
medium = a blog post or release note mentions it
low = only third-party listicles mention it
RULES
Never return True without an evidence_url. A tool appearing in a generic
"integrations coming soon" list is False. If you find nothing after all three
steps, return False, low, and NOT_FOUND in the text fields. Explicit search order is what makes this reproducible. Left to itself the agent finds whichever page ranks highest, which is often a comparison article written by someone selling something. The confidence tiers then let you route low-confidence rows to a human instead of into a sequence. That pattern, cheap machine pass then human review on the uncertain remainder, is the same one we describe in our B2B data enrichment guide.
Three Claygent recipes for personalization
These three consume the columns the research recipes produced. Running them against raw company names instead of researched fields is where personalization goes generic, because the agent is left to invent context it never read.
4. A first line that names something real
The output here is deliberately not an email. It is one observation, capped in length, with a boolean that tells you whether it is good enough to use.
ROLE
You write one sentence of context for a cold email. You are not writing
the email itself.
INPUTS
{{company_name}} {{pricing_url}} {{top_role_title}} {{evidence_quote}}
TASK
Produce one specific observation a founder would recognise as true about
their own company, drawn only from the inputs above.
OUTPUT FIELDS
observation (Text) maximum 18 words, no greeting, no sign-off
source_url (URL) the page the observation came from
usable (True/False)
RULES
Name a concrete thing: a plan name, a printed number, a job title, a product.
Never use the words impressive, excited, noticed, love, or congrats.
No adjectives describing the company. No questions.
If the inputs contain NOT_FOUND or nothing specific, set usable to False
and return NOT_FOUND in observation.
GOOD
"You are hiring a Senior SDR while pricing still starts at $29 self-serve."
BAD
"I was impressed by your innovative approach to growth." The usable boolean is the field that protects your reply rate. Filter to usable = true for the personalized sequence and route everything else to a clean, short, unpersonalized email. A weak first line performs worse than no first line, because it announces that a machine wrote it. Our cold email personalization guide covers which variables are worth the credits.
5. Persona classification and channel routing
Job titles are messy, and messy titles are why sequences land on the wrong person. This one classifies against your buying committee rather than a generic seniority scale.
ROLE
You classify contacts against a defined buying committee. You use the title
text only. You do not research the person.
INPUTS
{{full_name}} {{job_title}} {{company_name}} {{hiring_signal}}
COMMITTEE DEFINITION
economic buyer = owns the budget line (Founder, CEO, CRO, VP Sales, VP Growth)
champion = owns the number but not the budget (Head of Sales, Head of
Growth, Sales Director, Demand Gen Manager)
practitioner = does the work (SDR, BDR, AE, GTM Engineer, RevOps)
out of scope = any other function
OUTPUT FIELDS
persona (Select) economic buyer / champion / practitioner / out of scope
pain_hypothesis (Text) maximum 20 words, phrased as their problem
route (Select) email-first / linkedin-first / skip
economic buyer at strong hiring_signal = linkedin-first
champion = email-first
practitioner = email-first
out of scope = skip
RULES
Classify from the title string as written. Do not infer seniority from
company size. If the title is empty or unreadable, return out of scope
and skip. This one runs on Helium because the inputs are already in the row, so nothing needs browsing. It is a good illustration of the cost rule: three quarters of the work in a mature Clay table is cheap classification, and only the browsing steps need an expensive model. If you want the scoring logic behind the committee definition, our B2B lead scoring framework sets it out properly.
6. Offer selection, so the right angle reaches the right account
The last step chooses which of your offers to lead with, based on what the research found. It also decides what to do when the research came back thin, which is the case most sequences handle badly.
ROLE
You assign one outbound angle per account from a fixed list. You do not
invent new angles.
INPUTS
{{hiring_signal}} {{gtm_open_roles}} {{pricing_model}} {{integration_exists}}
{{persona}}
OFFER LIST
A = build the outbound motion (for strong hiring_signal, 3+ open GTM roles)
B = fix an existing motion (for weak hiring_signal, sales-led pricing)
C = short generic proof email (for everything else)
OUTPUT FIELDS
offer (Select) A / B / C
reason (Text) maximum 25 words, cite the input that decided it
confidence (Select) high / medium / low
RULES
If two or more inputs contain NOT_FOUND, return C and low.
If persona is out of scope, return C and low.
Never return A without a numeric gtm_open_roles value of 3 or more. Six recipes chained this way cost 12 data credits an account, roughly $0.67 on the Launch plan, and they replace the research an SDR would spend eight to ten minutes doing by hand. The saving is real, and it only holds if the fallback rules are strict enough that thin rows get demoted to the generic offer instead of receiving a confident email built on a guess.
Where does Claygent fail, and what do you do about it?
Claygent fails in a small number of predictable ways, and each has a specific fix. Recognising the symptom is most of the work, because an empty column looks the same regardless of cause until you have asked for fallback values.
| Symptom | Cause | Fix |
|---|---|---|
| Empty cells across many rows | Login wall, paywall, or a page rendered entirely in JavaScript | Pass a specific URL, and require a NOT_FOUND fallback so failures are visible |
| Format changes row to row | One free-text output instead of typed fields | Define typed output fields and name each one inside the prompt |
| Confident but wrong answers | The agent inferred rather than read | Require an evidence URL and a verbatim quote in every row |
| Bill three times the forecast | Argon left as the default on a high-volume column | Run Helium first, and gate the expensive column behind a filter |
| Great in testing, poor at scale | Tested on 10 clean rows | Test on the messiest rows you have, including missing domains |
| Stale answers on news or funding | Web search off, or no date constraint | Enable web search and require a published date in the output |
The one limitation with no workaround is authentication. Claygent reads the open web, so anything requiring a logged-in session stays out of reach, including LinkedIn profile pages. Clay covers that gap with separate people and company datasets, and mixing them up leads teams to write prompts that can never succeed.
When should you not use Claygent?
Skip it when the fact already exists in a database, when the answer needs to be right every time, and when your list is too small to justify a pipeline. Each case has a cheaper or safer alternative.
Firmographics like headcount, industry, location, and funding are already sold by providers at a fraction of a browsing run, and a provider will be more consistent than a live page read. Use a data enrichment tool for those and save Claygent for the fields nobody sells.
Accuracy expectations matter too. A research column with a 90% hit rate is excellent for choosing an outbound angle and unacceptable for anything a contract or a compliance decision depends on. Keep the agent on the reversible side of that line.
List size is the last filter. Below roughly 200 accounts, an SDR reading pages by hand produces better research than any prompt, because they notice the thing you forgot to ask about. Claygent earns its place when the same question has to be asked a thousand times identically.
How does Claygent fit into a working outbound system?
Claygent is one layer of four: a list, an enrichment pass, a research and scoring pass, then sending infrastructure that can actually deliver what you wrote. A research agent on top of a bad list produces well-researched emails to the wrong people.
The order we build in is fixed. Define the ICP and the buying committee first, using something like our ICP template. Build the list against real signals rather than a broad filter, which is the point of signal-based outbound. Enrich with providers for anything commodity. Only then add Claygent for the judgment columns, and only for the columns that change what you send.
Then the infrastructure has to hold. All six recipes above are worthless if the emails land in spam, which is a function of domain setup, warm-up, and volume discipline rather than research quality. Our cold email deliverability guide covers that half, and the GTM engineering guide covers how the layers fit together.
If you would rather have the Clay tables, the research columns, the sending infrastructure, and the reply handling run for you, that is what Reachly's cold email service does. On the Primal account that system produced 85+ sales-qualified leads in six months, six closed deals, a 35% reduction in CAC, and 4.57x ROI. We are a Clay certified partner, so the tables come built rather than described.
Claygent FAQ
What is Claygent in simple terms?
Claygent is an AI agent inside Clay that reads web pages for every row of your table and writes structured answers into columns you define. You supply a prompt, some input columns, and a set of typed output fields, and it does the reading that an SDR would otherwise do one browser tab at a time.
Is Claygent free to use?
Claygent is included on every Clay plan, including the free tier, which comes with 500 actions and 100 data credits a month. That allowance is enough to test prompts and run a small list, and testing inside Clay's agent builder on up to 10 inputs does not consume credits at all.
How much does Claygent cost per row?
Clay's in-house models are fixed price: Helium at 1 data credit, Neon at 2, Argon at 3, plus 1 action per row. On the $167 Launch plan with 3,000 data credits, that is roughly $0.06 a row for Helium, $0.11 for Neon, and $0.17 for Argon. Frontier models bill by token consumption instead, so their cost per row varies with the length of the prompt and the answer.
Which Claygent model should I use?
Use Helium for single facts and classification you run at volume, Neon when you want several typed columns from one page, and Argon when the answer takes several clicks or a long document to reach. Defaulting everything to Argon triples the bill for work the cheaper models handle identically, so it is worth comparing two models on the same 10 test rows before you commit a column.
How accurate is Claygent?
Accuracy depends almost entirely on the prompt rather than the model. A vague question produces inconsistent answers and empty cells, while a prompt that names the source, defines the decision rule, and requires a verbatim quote is checkable row by row. The practical approach is to require an evidence URL in every research column, then audit 20 rows by hand before you trust the column.
What is the difference between Claygent and Clay's AI column?
The simpler AI column reasons over data already in the row and does not browse. Claygent visits pages, follows links, and reads what it finds, which is why it costs more per row. If the answer is already somewhere in your table, the cheaper column is the right tool.
Can Claygent read LinkedIn profiles?
No. Claygent reads the open web, so pages behind a login stay out of reach, and LinkedIn profiles sit behind one. Clay covers person-level data through its own datasets and providers instead, so keep LinkedIn attributes in the enrichment layer and use Claygent for company pages, job boards, docs, and news.
Can Claygent write my cold emails?
It can, and it usually should not write the whole email. The better pattern is to have Claygent produce one short researched observation with a usable flag, then keep the email body as a human-written template. Whole emails generated per row drift in tone, and the drift is the tell that a machine wrote them.
Do failed Claygent runs cost credits?
Clay does not publish a blanket rule covering every failure case, so plan on treating any run that reaches a model as billable. The safe workflow is to use the free 10-input test bench in Clay's agent builder until the prompt is stable, then deploy to a filtered subset of the table before running the full list.
How many rows should I test before running a full list?
Ten, and choose the worst ten you have rather than the cleanest. Include a company with no careers page, one with a JavaScript-heavy site, one with no pricing page, and one with a missing domain. A prompt that returns sensible fallback values on those four will hold up across ten thousand rows, and a prompt tested only on tidy rows will not.
Do I still need a data provider if I have Claygent?
Yes. Providers are cheaper and more consistent for commodity fields like headcount, industry, funding, and verified email, and Claygent is the layer that answers questions no provider sells. Running a browsing agent to fetch a headcount that costs a fraction of a credit from a provider is the most common way teams overspend in Clay.
