Claygent is the most powerful column in Clay.
It is also the most expensive one to misuse.
Most people add a Claygent column, write something like "find the CEO's email and summarize the company," run it on 5,000 rows, and wonder why their credits disappeared in 20 minutes and half the results are garbage. Then they conclude Claygent doesn't work.
It works. The problem is they treated a research agent like a lookup field.
Claygent is not a database query. It is a real-time AI research agent that browses the web on your behalf, reasons about what it finds, and returns structured output. Getting value from it requires the same discipline you'd apply to any AI system — prompt engineering, model selection, cost architecture, and validation design.
This is that guide.
What Claygent Actually Is
Most enrichment columns in Clay hit a data provider's API and return a result from a database. Clearbit looks up the company. Apollo finds the contact. Hunter verifies the email.
Claygent is different. It does not query a database. It browses the web in real time — searching, reading pages, extracting information, and reasoning about what it found. This is why it can answer questions that no database can: "Does this company use AI in their core product?" "Has their VP of Sales posted about outbound challenges in the last 30 days?" "Do they have a self-serve motion or is everything sales-led?"
Those are judgment calls, not lookups. Claygent makes them.
The tradeoff is cost. Real-time web research with AI reasoning is orders of magnitude more expensive than a database lookup. This is not a bug — it is the price of capability. The engineering challenge is using that capability precisely, not liberally.
Two models. Very different jobs.
Claygent runs on two models:
Helium is faster and cheaper. Use it for straightforward lookups — finding a specific piece of information on a known page, extracting structured data from a website, yes/no qualification against clear criteria. When the task is "find the pricing page and tell me if they have a free tier," Helium is correct.
Argan is more capable and more expensive. Use it for reasoning-heavy tasks — synthesizing information from multiple sources, making nuanced qualification judgments, writing account summaries. When the task is "determine whether this company has a product-led growth motion based on their website, job postings, and recent LinkedIn content," Argan earns its price.
The mistake is defaulting to Argan for everything because it sounds more capable. That is like using a sledgehammer to hang a picture frame.
The Prompt Engineering Layer
The quality of Claygent output is determined almost entirely by prompt quality.
A vague prompt produces vague output. "Research this company and tell me about them" returns a paragraph that sounds like a Wikipedia summary you could have written yourself. It costs credits. It tells you nothing useful. And it runs on every row whether or not you needed it.
A specific prompt returns actionable data.
Anatomy of a strong Claygent prompt:
- What to find — the specific information you need, not a general topic
- Where to look — constrain the search when you can (their website, their LinkedIn, their job board)
- What format to return — JSON, yes/no, a specific field, a score from 1-10
- What to return if nothing is found — "return null" or "return false" — never leave this implicit
Weak prompt:
Research
{{company_name}} and tell me if they use AI.
This returns paragraph prose that you cannot act on programmatically. Half the rows will return "yes, they mentioned AI on their about page." The other half will return uncertainty dressed up as a summary.
Strong prompt:
Visit
{{company_website}} and determine whether AI is a core component of their product — not a feature or integration, but the primary mechanism of value delivery.Return a JSON object:
{"ai_native": true/false, "evidence": "one sentence quoting specific evidence from the page", "confidence": "high/medium/low"}If you cannot determine this from the website, return:
{"ai_native": null, "evidence": "insufficient data", "confidence": "low"}
Now you have structured output you can act on. You can filter, route, and validate it. You can build conditional logic on top of it.
The test-first rule.
Before running any Claygent prompt on your full table — run it on 10 to 20 rows first.
Review every result manually. Check the evidence field. Check whether the classification matches your judgment. Adjust the prompt. Run 10 more. Only when you have 90%+ accuracy on the sample do you run on the full table.
This step eliminates 80% of credit waste. A bad prompt on 5,000 rows is expensive. A bad prompt on 15 rows is a learning.
Cost Architecture
Claygent credits are not unlimited. The goal is not to minimize Claygent usage — it is to use it exactly where it adds value that cheaper methods cannot.
The hierarchy:
- Check if cheaper enrichment columns already have the data. If Apollo already returned the email, do not run Claygent to find the email.
- Use "Run only if" conditional logic. Only fire Claygent on rows where the preceding columns returned empty or insufficient results.
- Use Helium for simple tasks. Use Argan only when reasoning is genuinely required.
- Run prompts on samples before tables.
The "Run only if" pattern:
This is the single most important cost-saving mechanism in Clay. Every Claygent column should have a condition: run only if [the field I need is still empty after other providers ran].
Without this, Claygent runs on every row including the ones Apollo already handled. You pay twice for the same data. On a 5,000-row table, that is a significant cost difference.
The math:
Assume Argan costs 10x more than Helium. A table with 2,000 rows where you default to Argan on every row costs 10x more than one where you use Helium for simple qualification and Argan only for the 200 accounts that passed initial qualification.
Your enrichment bill is a direct reflection of your conditional logic discipline.
Confidence Scores: What They Mean and What They Don't
Claygent returns a confidence score with most outputs. This is useful. It is not a substitute for validation.
A confidence score of 0.9 means Claygent is highly confident in its answer. It does not mean the answer is correct. It means the model found clear evidence and its internal reasoning was consistent. If the website has misleading copy, Claygent can be confidently wrong.
For low-stakes enrichment — finding a job title, summarizing a company description — confidence scores are sufficient. Flag low-confidence results for manual review and move on.
For high-stakes qualification — "is this company AI-native?", "does this contact have budget authority?", "is this company actively evaluating vendors in our category?" — confidence scores alone are not enough.
You need two-step validation.
The Two-Step Validation Pattern
High-stakes Claygent output needs to be verified, not trusted.
Step one: the extraction run. Claygent finds the information and returns a structured result.
Step two: the verification run. A separate Claygent column — or a different prompt against the same data — checks whether the step one result holds up.
Example: qualifying "AI-native" companies.
- Step 1 prompt: "Visit
{{company_website}}. Is AI a core component of their product delivery? Return yes/no with evidence." - Step 2 prompt: "Given that this company was classified as AI-native based on their website, verify this by checking their LinkedIn page and most recent job postings. Do the postings reference ML/AI roles as core engineering, not support? Return verified/unverified with evidence."
Two independent checks from two different angles. If both return the same answer, you can trust it. If they diverge, that row goes into the approval queue.
Building the Approval Queue
Not every Claygent result needs human review. Most do not. The goal is to route human attention only to the borderline cases.
The tiered architecture:
- Confidence ≥ 0.85, both validation steps agree: Auto-approve. The row moves forward.
- Confidence 0.65–0.84, or validation steps disagree: Queue for human review. A human makes the call.
- Confidence < 0.65: Flag as insufficient data. Either re-run with a better prompt or mark as unqualified.
In Clay, you implement this with conditional logic and a status column. High-confidence, validated rows get status: approved. Borderline rows get status: review. Low-confidence rows get status: insufficient.
Your sales team reviews only the status: review rows. Everything else moves automatically.
This is the architecture that lets you run AI research at scale without introducing noise into your pipeline. You are not automating the decision — you are automating the routing of decisions to the right level of scrutiny.
The Most Valuable Use Cases, In Order
Not every use case justifies Claygent. Here is where it earns its cost:
1. Nuanced ICP qualification.
This is the primary use case. Databases cannot filter for "AI-native," "product-led growth motion," "sales team of 10+," or "actively evaluating vendors in our category." These are judgment calls that require reading websites, job boards, and LinkedIn. Claygent makes these calls at scale.
2. Account intelligence for Tier 1 personalization.
For your highest-priority accounts, you want the opening line of your outreach to reference something specific — a product launch, a hiring pattern, a LinkedIn post, a funding announcement. Claygent can research this and return a ready-to-use sentence. "I noticed you just launched {{feature}} last week — that aligns directly with what we're solving."
3. Contact finding when enrichment fails.
Apollo missed the email. Hunter couldn't find a valid address. Datagma came up empty. Before giving up, run Claygent against the company website and LinkedIn. It will find what the databases missed — personal pages, contact forms, staff directories, email patterns.
4. Tech stack detection for complex criteria.
BuiltWith tells you the public-facing tech stack. Claygent can go further — reading job postings, engineering blogs, and LinkedIn profiles to infer internal tools that don't show up in any database. "They posted 3 jobs this month requiring Salesforce Admin experience" tells you they're a Salesforce shop even if BuiltWith doesn't detect it.
Prompts Are Assets
Every prompt that works is worth keeping.
A well-designed Claygent prompt for "does this company have a VP of Sales with budget authority over outbound tools?" took you 45 minutes to build and test. It works for every client in a similar ICP space. It is reusable, refinable, and compounding.
Build a prompt library. Document every prompt: what it does, which model it uses, what confidence threshold to apply, what the validation step looks like. Treat these like code — version them, preserve them, improve them.
The GTM engineers who differentiate themselves in competitive job markets are not the ones who know what Claygent is. They are the ones who have a library of validated prompts, cost-efficient architectures, and documented performance data across dozens of client engagements.
That is the advantage that compounds. Anyone can add a Claygent column. Very few people can architect a validated, cost-efficient AI research workflow from scratch.
How to Start
Pick one ICP qualification criteria your current enrichment setup cannot handle.
Something that requires judgment. "Does this company have a data engineering team?" "Is their primary sales motion inbound or outbound?" "Have they publicly mentioned a competitor in the last 90 days?"
Write a Claygent prompt following the structure above: what to find, where to look, what format to return, what to return if nothing is found.
Run it on 20 accounts from your current pipeline.
Review every result manually. Check the evidence. Adjust the prompt. Run 20 more.
When you have 90%+ accuracy, build the conditional logic and the confidence-tiered approval queue. Run it on your full table.
Document the prompt. Document the performance. Move to the next qualification criteria.
That is how you build a research infrastructure that compounds. One validated prompt at a time.
Claygent is not a magic button. It is an AI research agent that requires the same engineering discipline as any other system you build — clear requirements, precise inputs, validated outputs, cost constraints. Get that architecture right and it becomes one of the highest-leverage tools in your GTM stack.