What Is Clay? Enrichment, AI Research Agents, Signals and Scoring Explained

That's the short answer. The longer one matters more, because Clay is easy to use badly. A table full of enriched rows that nobody acts on is just an expensive spreadsheet. This guide explains what Clay does, how its main pieces work, the architectures GTM engineers actually build with it, and when you should reach for something else.

In short

• What it is: a table-based workbench for finding, enriching, researching, scoring and routing GTM data. Clay describes itself as infrastructure to get data, run agentic workflows and launch GTM plays (Clay).
• Enrichment: instead of trusting one provider, you query several in sequence until one returns a valid match (Clay docs on waterfalls).
• Claygent: an AI agent that reads a row, researches the web or documents, and writes a structured answer (Claygent).
• Signals: changes that suggest timing, like job changes, funding news or website visits (Clay Signals).
• Scoring: columns that turn all of the above into a priority you can route on.
• Where it fits: it is mainly MitHub's first family of GTM systems, lists and enrichment, with a growing reach into agentic AI.
• When not to use it: no ICP, no volume, no destination for the output, or a job that needs real-time orchestration.

What Clay actually is

Picture the manual version of prospecting. Someone exports a list of companies, opens each website, looks up the right person on LinkedIn, tries three tools to find an email, reads the latest news, writes a note on why this account matters, and pastes everything into the CRM. It's slow, inconsistent and impossible to scale.

Clay turns each of those steps into a column. You define the step once, and it runs on every row. That's the core idea: the unit of work becomes the column, not the lookup.

A Clay table has three kinds of columns:

1. Input columns. What you already know: a company domain, a name, a LinkedIn URL, an email from a form. Data arrives by import, CSV, a CRM sync, a search inside Clay, or a webhook.
2. Enrichment and AI columns. Columns that call something: a data provider, an AI model, Claygent, or a generic HTTP API. A generic HTTP API column lets a table call almost any tool that exposes an API, in either direction.
3. Logic and output columns. Formulas, conditions, scores and "send" actions that write to a CRM, add to a sequence, or post to another system.

The value is not any single lookup. It's that the whole chain is visible, repeatable and adjustable in one place.

Enrichment and waterfalls

Enrichment means adding facts to a record you already have. Given a company domain, you might add industry, headcount, location, tech stack and funding. Given a person, you might add title, work email and phone.

The problem is that no single data provider is complete. One is strong on emails in North America, another on phone numbers, another on small businesses. If you pick one, you inherit its blind spots.

A waterfall solves this. You choose several providers for the same field and put them in order. Clay asks the first; if there's no valid result, it asks the second, and so on, stopping when it finds a match. Clay's documentation explains that you can reorder, add or remove providers in the sequence and skip steps (Waterfalls – Clay Docs).

How to think about waterfall order

Order is a design decision with cost and quality consequences. A simple way to decide:

• Put the cheapest reliable source first. If it finds the answer, you never pay for the expensive ones.
• Put a verification step after emails. Finding an address and confirming it is deliverable are different jobs.
• Record which provider answered. Over time you learn which sources actually work for your market, and you reorder based on evidence instead of habit.
• Stop enriching what you won't use. Every field should earn its place by feeding a score, a message or a routing rule.

How Clay meters this work

Product pricing changes, so check Clay's pricing page before you plan a budget. As of this writing, Clay's docs describe two separate meters: Actions, which measure platform work like running enrichments, AI and syncs, and Data Credits, which measure data bought from its provider marketplace. You can connect your own API keys for some providers, which removes Data Credit charges for those calls while still consuming Actions (Actions & Data Credits – Clay Docs). The practical lesson: a sloppy table that enriches every row with every field costs more and teaches you less.

AI research agents: Claygent

Databases store facts that someone already collected. A lot of what makes an account interesting was never collected: whether a clinic network lists online booking, whether a company's careers page mentions a new sales team, whether a lender's website offers a specific loan product.

That's what Claygent is for. Clay describes Claygents as agents that take inputs, follow your instructions and write a structured output (Claygent). In practice you give it a row (say, a domain), a question, and the shape of the answer you want.

Write Claygent prompts like specifications

Vague prompts produce vague columns. A good research column has four parts:

1. Input: exactly which fields it can use ("the company domain in column B").
2. Task: one question, not five ("Does this company show more than one physical location on its website?").
3. Output format: a fixed shape ("Return yes, no, or unknown, then a count if found, then the URL where you found it").
4. Rules for uncertainty: "If you cannot find evidence on the company's own site, return unknown. Do not guess."

The last rule matters most. An AI answer is a hypothesis, not a fact. Asking for the source URL lets a human spot-check a sample before the column drives any decision. That's the same discipline MitHub teaches in Prove value fast: facts, not opinions, and never let an unverified claim reach a customer.

If you want the broader picture of how agents differ from fixed automations, read What is an AI agent?.

Signals: knowing when, not just who

A list tells you who could buy. A signal suggests when. Clay's Signals page lists categories such as job changes and promotions, new hires, website intent, news like funding announcements, social mentions, product usage and technology changes (Clay Signals).

Signals are powerful and easy to misuse. Three rules we use:

• A signal needs a reason. "New VP of Operations" matters if your offer solves an operations problem that new leaders inherit. Otherwise it's noise.
• Signals decay. A funding round from last week is a conversation starter; one from 18 months ago is trivia. Store the date and let the score fall over time.
• Never state an inferred signal as fact to the prospect. "Saw you're hiring" is fine if the job post is public. "Saw you're struggling with follow-up" is a guess dressed as insight.

Scoring: turning data into a decision

Enrichment, research and signals only matter if they change what happens next. Scoring is where that happens. In Clay, a score is usually a formula or AI column that combines fields into a priority.

The MitHub Fit × Timing × Reachability score

We teach a simple three-part structure that keeps scores explainable:

Score each part separately (for example 0–3), then route on the combination instead of one blended number:

• High fit, high timing, reachable: human-led outreach this week.
• High fit, low timing: nurture and keep watching for signals.
• High fit, not reachable: spend more on enrichment for these rows only.
• Low fit: stop spending on this row.

Keeping the parts separate tells you why a record ranks where it does, and it tells you where to invest: better data, better signals, or a better ICP. Numbers are only illustrative; your thresholds should come from your own closed deals, traced backwards the way Follow the money describes.

Common GTM architectures with Clay

Here are five patterns GTM engineers build repeatedly. They're described generically so you can adapt them; none of them is a MitHub client result.

1. Outbound list from scratch (TAM build)

Source companies matching your ICP → enrich firmographics → Claygent checks a criterion databases miss → Fit score → find people in the target roles → waterfall for email and phone → verify → push the top tier to your CRM and sequencer.

The key design choice: enrich people only for accounts that pass the fit score. That single condition is often the difference between a lean table and a wasteful one.

2. Inbound lead enrichment and routing

A form fill hits a webhook into a Clay table (Clay's webhook guide) → enrich company and person → score → write back to the CRM with the score and a short AI summary → send a notification or hand off to an automation tool that routes the lead. Speed matters here, so keep the columns minimal.

3. CRM hygiene and refresh

Pull stale CRM records into a table → re-enrich titles, company status and contact details → flag changes (the champion left, the company was acquired) → update only the fields that changed, with a timestamp. The goal is a CRM people trust.

4. Signal-triggered plays

Watch a list of target accounts or past customers for signals → when one fires, research the context with Claygent → score timing → alert the owner with a suggested angle, or add to a specific sequence. Example: a former champion changes jobs to a company that fits your ICP.

5. Research for personalization

For a small, high-value list, run several Claygent columns that extract specific, verifiable facts (locations, services offered, recent announcements) → a writing column drafts a first line that references only those facts → a human reviews before anything is sent. This is where AI helps most and where review matters most.

When not to use Clay

Clay is excellent at what it does, and it's still the wrong tool for several jobs:

• You don't have an ICP yet. Enriching thousands of rows won't tell you who your customer is. Diagnose first: MitHub's Diagnose chapter covers how.
• Your volume is tiny. If you need 20 accounts researched once, a person with a checklist may be faster and cheaper.
• There's no destination. If no rep, sequence or workflow will act on the output, don't build the table.
• You need a system of record. Clay tables are working surfaces. Your CRM should remain the source of truth for accounts, stages and ownership.
• You need real-time, multi-step orchestration. Branching logic across many apps, retries, approvals and error handling are the natural job of a workflow tool. That's the core of Clay vs n8n.
• The data is regulated or sensitive. Personal data, consent and outreach rules depend on the country and channel. Check the rules before enriching and contacting anyone.

How Clay fits MitHub's four families of GTM systems

In the Foundations of the Faculty of Revenue Reverse Engineering, we group GTM systems into four families. Clay's role in each:

That table is also a hiring lesson. Knowing Clay's buttons is the Doer level. Designing the table so the right rows get the right spend and land in front of the right person is the Designer level. Owning whether it produced pipeline is the Owner level. That progression is what GTM engineering is about.

How to start learning Clay

1. Pick one real question. "Which of these 200 companies have more than five locations?" beats "learn Clay."
2. Build a five-column table: input, one enrichment, one Claygent column with the four-part prompt above, one score, one output.
3. Spot-check 20 rows by hand. Write down where the AI or the data was wrong.
4. Adjust and rerun. That loop is the scientific method from Operate: observe, hypothesize, build, measure, learn, adjust.
5. Document it as proof of work: the question, the table design, what you checked, and what changed.

When you're ready to go deeper, read Clay for GTM engineering for how to build tables that hold up in production.