For a GTM engineer, Clay is a place to build revenue systems, not a place to look things up. The work is designing a table with a clear input, a cost-aware path through enrichment and AI research, verified outputs, an explainable score and a destination where someone acts on the result, then proving that the whole thing changed pipeline. Anyone can run a lookup. The engineering is in the design around it.
If you're new to the tool, start with What is Clay?. This article assumes you know what waterfalls, Claygent and signals are, and focuses on how to use them the way a GTM engineer would.
Tasks vs systems in Clay
Clay's own writing on the role frames GTM engineering as building automated revenue systems with AI, data and workflow automation, where the unit of work is a system rather than a task (Clay). In Clay, the difference shows up in very concrete ways:
| Task mindset | System mindset |
|---|---|
| "Enrich this list" | "Which accounts should a rep call this week, and why?" |
| Every column runs on every row | Expensive columns run only on rows that passed earlier checks |
| AI output pasted into messages | AI output verified, sourced, and allowed to say "unknown" |
| CSV export at the end | Write-back to the CRM or a webhook, with an owner |
| Done when the table is full | Done when a metric moved |
That's the same idea behind MitHub's build systems, not just tasks: a system keeps producing value after you stop touching it.
The MitHub Clay Build Spec
Before building any table that matters, write a one-page spec. It takes 20 minutes and saves days of rework. It also becomes a portfolio artifact.
- The money question. What decision does this table support, and how does it connect to revenue? Trace it backwards the way Follow the money teaches: payment → decision → conversation → first contact → source.
- Input contract. What must every row have to enter (a domain, a CRM ID, a form timestamp)? What happens to rows that don't?
- Spend gates. Which checks must a row pass before it gets expensive enrichment or AI research?
- Enrichment path. Which fields, from which waterfall, in which order, and why each field is needed.
- Research questions. Each Claygent column: input, one question, output format, rule for uncertainty.
- Verification. How many rows you'll check by hand, and what error rate is acceptable before the column is trusted.
- Score. The components and the thresholds, written in plain language.
- Destination. Where the result goes (CRM field, sequence, webhook, alert) and who owns acting on it.
- Success metric. What will you measure in two to four weeks to know it worked?
If you can't fill in 1, 8 and 9, don't build yet.
Design principles that separate engineers from operators
1. Gate spend with conditions
Every enrichment and AI step uses platform capacity, and many data lookups also use credits. Clay's docs describe these as two meters: Actions for platform work and Data Credits for data purchased from providers, with the option to connect your own keys for some providers (Actions & Data Credits – Clay Docs). Pricing details change, so read the current docs, but the design lesson doesn't change: cheap checks first, expensive steps last, and only for rows that earned them.
A typical order:
- Free or cheap filters (country, industry, is the domain valid?)
- Firmographic enrichment
- Fit score
- AI research, only for rows above a fit threshold
- People search and contact waterfalls, only for accounts you'll actually work
2. Design waterfalls with evidence
Clay lets you reorder, add and remove providers in a waterfall (Waterfalls – Clay Docs). Don't set the order once and forget it. Output which provider answered, and after a few hundred rows look at the results for your segment. Reorder based on what actually found valid data for your market.
3. Treat AI answers as hypotheses
Clay describes Claygents as agents that take inputs, follow instructions and write structured output (Claygent). Structured doesn't mean correct. Every research column should:
- Return a fixed format (yes / no / unknown, a number, a short list).
- Include the URL where the evidence was found.
- Be allowed to return "unknown" without penalty.
- Be spot-checked on a sample before it influences a score.
A useful rule: anything that will appear in a message to a prospect must be traceable to a public source. Inferences about a company's problems stay internal. They can shape which accounts you prioritize; they never become claims.
4. Keep scores explainable
A single number from 0 to 100 hides why a record ranks where it does. Score components separately (for example fit, timing and reachability, as in our Clay guide) and route on the combination. When a rep asks "why is this account on my list?", the table should answer in one sentence.
5. Every table needs a destination
Outputs go somewhere: a CRM field, a sequence, a Slack alert, or a webhook to a workflow tool. Clay can receive data through webhooks and send it through HTTP API columns (Webhooks in Clay – Clay Docs). Webhook sources have submission limits described in that same guide, which is one more reason to design inbound tables deliberately. When routing gets complex (branches, retries, approvals, multiple apps), hand the result to a workflow tool. Clay vs n8n walks through that split.
6. Version and document
Name tables and columns so someone else can understand them. Keep a changelog in the spec: what you changed, why, and what happened. If you're the only one who understands the table, it's not a system yet.
Worked example: a lookalike list for a multi-location business
This is a hypothetical example to show the method, not a MitHub client result.
Imagine you work with a company selling scheduling and follow-up automation to multi-location service businesses. Their best customers have many locations, handle lots of inbound calls, and lack online booking.
Money question: Which multi-location businesses in our target states should sales contact this month?
Table design:
| Step | Column | Gate |
|---|---|---|
| 1 | Company domain (input) | Must be a valid domain |
| 2 | Industry, headcount, HQ state (waterfall) | Industry in target list |
| 3 | Claygent: "How many physical locations does this company list on its own website? Return a number or unknown, plus the URL." | Headcount within range |
| 4 | Claygent: "Does the website offer online booking? Return yes, no or unknown, plus the URL." | Locations ≥ threshold |
| 5 | Fit score (locations, industry, state) | — |
| 6 | Timing: recent public job posts for front-desk or call-center roles | Fit is high |
| 7 | People search: operations leader | Fit is high |
| 8 | Email waterfall + verification | Person found |
| 9 | Write to CRM with score, reasons and source URLs | Verified contact |
Verification: check 25 rows by hand for steps 3 and 4. If the location count is wrong often, refine the prompt (for example, point it to a "locations" page) and rerun on the sample before running the full list.
Success metric: in four weeks, compare reply and meeting rates on high-fit accounts against the team's previous list. If there's no difference, the score is wrong, and that's a finding worth documenting too.
The Clay skills that make you hireable
Knowing where the buttons are gets you started. What companies need is judgment. Using MitHub's capability ladder:
- Doer: runs enrichments and builds tables from templates.
- Director: writes precise research prompts, judges output quality, catches bad data.
- Designer: writes the Build Spec, gates spend, designs the score and the destination.
- Owner: is accountable for whether the table produced meetings and pipeline.
Aim for Designer, and document every table you build as proof of work. If you're mapping out that path, read how to become a GTM engineer and the broader view of what a GTM engineer does.
Checklist before you hit "run all"
- The money question is written down
- Rows that fail the input contract are filtered out
- Expensive columns have conditions
- Waterfalls record which provider answered
- Research columns return a fixed format, a source URL and allow "unknown"
- A sample has been checked by hand
- The score can be explained in one sentence
- The destination and its owner are defined
- The success metric and review date are set