Cold Outreach Lead Generation: Which Steps Should Be AI and Which Shouldn't

Every cold outreach lead generation tool launched in the last two years calls itself "AI-powered." But when you ask what the AI actually does, the answers get vague fast. "We use AI to find leads." Which part? The search? The scoring? The email lookup? When a lead turns out to be garbage, which step in your cold outreach pipeline failed? Was it the AI hallucinating a company that doesn't exist, or a stale database entry dressed up with a GPT badge?

Nobody tells you. And that vagueness costs you money.

Here is the question you should ask every outreach vendor before you sign a contract: for each step in your pipeline, is it deterministic or AI-powered? Deterministic steps are rule-based code that produces the same output every time for the same input. Domain deduplication is deterministic. SMTP email verification is deterministic. Credit charging is deterministic. AI-powered steps use a language model to make a judgment call. Interpreting a web page is AI. Scoring ICP fit is AI. Generating a personalized outreach hook is AI.

This distinction matters because the failure modes are completely different. When a deterministic step fails, the output is binary: it either passed or it didn't, and you can trace exactly why. When an AI step fails, the output looks plausible but might be wrong, and tracing the failure requires understanding what the model saw and how it interpreted it.

Any outreach tool that won't tell you which steps are deterministic and which are AI is asking you to trust a black box with your pipeline. The ones that blur this line are usually hiding the fact that their "AI" is a thin wrapper over a stale database, or that their "verified" data was last checked months ago.

This post does two things. First, it gives you a framework for evaluating any cold outreach lead generation pipeline, whether it's ours or a competitor's. Second, it walks through Kustiq's 4-phase pipeline as a concrete example of how the deterministic/AI split works in practice. Every step is labeled: either a verified step (deterministic, rule-based, same output every time) or an AI-powered step (the model reads, interprets, and makes a judgment call). Real numbers on web budgets, scoring rules, credit costs, and email verification included.

Use this framework when you evaluate Clay, Apollo, ZoomInfo, or anyone else. The vendors who can answer the deterministic/AI question clearly are the ones worth talking to.

Disclosure: This is published by the Kustiq team, and we use our own pipeline as the example throughout. We'll be honest about what works well, what the limitations are, and where AI adds genuine value versus where code handles the job better. But the evaluation framework applies to any tool, not just ours.

The 4-Phase Cold Outreach Lead Generation Pipeline at a Glance

Think of the pipeline as a funnel with four gates. Every prospect enters at the top, and each gate either passes them forward with richer data or filters them out. Each phase has a strict web budget. The AI can't go on infinite research rabbit holes. It gets a fixed number of web searches and fetches per prospect, and when those are used up, it works with what it found.

Notice that Qualify uses zero web budget. By the time a prospect reaches qualification, all the web data has already been gathered. Qualify analyzes only what Discover and Research already found. Same input always produces the same tier. Costs stay predictable.

The pipeline processes prospects in sequence: Discover finds them, Research investigates them, Qualify scores them, Enrich finds the people to contact. Each phase charges credits independently based on the quality tier you select. At standard quality (Sonnet), discovery costs 0.75 credits per prospect, research costs 2.00, qualification costs 0.50, and enrichment costs 2.00. Economy tier (Haiku) cuts those costs roughly in half. Premium tier (Opus) costs more but brings the most capable model to bear on nuanced ICP matching.

You can run Discover, review the results, and decide whether to spend credits on Research. No phase forces you into the next one. Each phase also has plan-gated access: Discover is available on all plans including the Free tier, Research requires the Insight plan ($99/mo), and Qualify and Enrich require the Pro plan ($249/mo). Test discovery for free, validate that the pipeline finds relevant companies, then upgrade when you're ready for the full workflow.

Phase 1: Discover, How AI Finds Companies That Match Your ICP

Discovery starts with two inputs: your ICP Config and a set of seeds.

The ICP Config is where you define your ideal customer in plain language. It includes several fields that guide every subsequent phase:

• Product and value prop: What your product does, what problem it solves, and why they should care
• Target profile: Who your ideal customer is (industry, size, characteristics)
• Verticals and personas: Which industries to target and which job titles to reach (VP Sales, Head of CS, etc.)
• Qualification signals: Positive indicators of fit. These matter a lot. Things like "growing customer base," "hiring for CS roles," or "recently funded" tell the pipeline what a good prospect looks like, and they directly shape how the qualifier scores every company later.
• Disqualification signals and exclusions: Red flags (B2C only, government focus, direct competitor) and categories to skip entirely

Seeds are the search strategy. Each seed combines a seed type with a vertical and a region. The five seed types are: funding announcements (highest weight), growth signals, hiring signals, industry directories, and review sites. The pipeline weighs these by historical conversion to qualified prospects, with funding announcements contributing the most because funded companies have both budget and urgency. Seeds are generated automatically from your ICP Config, distributed across your chosen verticals and regions. If you target SaaS and FinTech in the US and EU, the pipeline generates seeds for "SaaS funding announcements in US," "FinTech growth signals in EU," and so on.

What the AI does. The discoverer agent executes a fixed budget of targeted web searches per seed. It adapts its search strategy based on the seed type, and each type has a different query template:

• Funding announcements: Searches for recent Series A and Series B rounds in your target verticals. Queries include terms like "raised," "funding," and year filters. These seeds tend to find companies with budget and growth pressure. Funded companies have both the money and the urgency to buy.
• Growth signals: Inc 5000, Deloitte Fast 500, and similar rankings. Queries target "fastest growing" and percentage growth claims.
• Hiring signals: This one's clever. If your persona is "Head of Customer Success," the AI searches for companies hiring that exact title. Companies investing in the role you sell to are often the ones with the most immediate need.
• Industry directories: G2, Capterra, and curated industry lists for your vertical and region.
• Review sites: Review count on G2 is a reliable proxy for customer base size.

The adaptive search strategy is where the AI earns its keep. After the first 2 queries, the agent reviews what came back and adjusts. Finding too many large enterprises when you want startups? It narrows the search by adding "startup" or "Series A/B" qualifiers. Finding companies that match your exclusion criteria? It adds explicit exclusion terms. Finding results that are too geographically broad? It adds specific country or city names. The remaining queries are spent exploring promising sub-categories that emerged from the initial results.

Each seed typically yields 5 to 15 companies. The AI is instructed to prefer quality over quantity: fewer, high-confidence matches beat a long list of uncertain ones. Every discovered company must have a verifiable website. The AI can't return companies it can't find online.

What verified code does. After the AI returns its list of companies, verified code takes over with three operations.

First, domain deduplication. The pipeline loads all previously discovered domains across every job in your organization and checks each new discovery against that list. If Discover finds "acmecorp.com" but you already have an Acme Corp prospect from a previous job, the duplicate is filtered out. This dedup happens across jobs, not just within the current run. The exclude list sent to the AI is capped at a practical limit to keep prompt sizes manageable.

If the AI returns only duplicates on the first attempt, higher quality tiers include automatic retries. The pipeline adds the duplicate domains to the exclusion list and searches again with fresh constraints, so you can recover from a bad search that happens to find the same companies you already have.

Second, region normalization. The code maps whatever region string the AI returns to one of 8 canonical regions: US, EU, UK, DACH, Nordics, APAC, LATAM, or Other. If the AI says "San Francisco, California" the code maps it to US. If it says "Berlin, Germany" the code maps it to DACH. If it says "Stockholm, Sweden" the code maps it to Nordics. Consistent region labels across every prospect, regardless of how the AI phrased it. The normalization function checks for substring matches and falls back to "Other" if no canonical region matches.

Third, cross-referencing against existing profiles. After discovery completes, the pipeline checks whether any of the discovered domains already have a company profile in your Kustiq account. If they do, the prospect record is linked to that profile, and the vertical, segment, and account tier from the existing profile are pulled in. This means you don't lose the profiling work you've already done when a company appears in an outreach pipeline.

What comes out. Each discovered company gets a structured record.

The confidence score is the AI's self-assessment of how well this company matches your ICP. Scores above 0.8 indicate strong matches with multiple signals. Scores between 0.5 and 0.7 indicate moderate matches. The AI is instructed to prefer fewer, high-confidence results over a large list of uncertain matches.

Model tiers matter here. Economy (Haiku) is the fastest and cheapest, good for broad discovery sweeps. Standard (Sonnet) is the default. Premium (Opus) is the most capable, useful when your ICP is nuanced and the AI needs to make subtle judgment calls about fit. The same tier structure applies to all four phases.

We profiled 500+ companies using the economy tier of the profiling pipeline, and you can browse the results in our public directory. Discovery uses the same model tier options but applied to finding new companies rather than profiling known ones. If you have already profiled companies you care about, discovery will automatically link any matches it finds to your existing profiles.

Phase 2: Research, The Hybrid Deep Dive

Research is where the verified/AI collaboration is most visible. The phase has a fixed budget of web searches and page fetches per prospect. But the AI doesn't always use all of them. Verified code does the grunt work first, and the AI picks up only what the code couldn't handle.

Verified code goes first. The Serper API fetches the company's website pages. Internal page scraping pulls content from the homepage, about page, team page, and integrations page. A regex-based junk detection system strips out CSS declarations, JavaScript boilerplate, hex color codes, and framework noise. WordPress and Divi sites are notorious for returning thousands of characters of theme configuration that looks like content but contains zero business information.

The junk detector separates meaningful prose from CSS declarations, JavaScript boilerplate, and framework noise using a word-level filter. Pages heavy on theme configuration get flagged as junk even if the raw character count looks healthy. The detector measures real business content, not markup noise.

The code does the cleanup first for a simple reason: no point burning AI tokens on HTML boilerplate.

AI fallback kicks in when content is thin. If the cleaned content falls below a minimum threshold or the scraper couldn't fetch enough pages, the AI activates its own research protocol. We calibrated this threshold through extensive testing to find the point below which the qualifier can't make a reliable tier decision. A company with a one-page marketing site and no about page needs external research to produce useful intelligence.

When fallback triggers, the AI runs a structured research protocol with a fixed budget of web searches and page fetches. The protocol prioritizes in order: company profile (what they do, who their customers are), customer base signals (case studies, review counts, "trusted by" claims), tech stack (CRM, tools, job posting signals), growth trajectory (funding, headcount, news), and competitive intelligence (existing solutions).

Customer base research is the most valuable step. A company with 200+ G2 reviews has a meaningfully different profile than one with 3 reviews. This data feeds directly into the qualifier's signal analysis.

Tech stack discovery is where job postings become gold. A posting that requires "Salesforce experience" confirms the CRM. An integrations page listing 50 partners reveals the company's ecosystem.

The AI allocates its search budget across these priorities, cutting from the bottom if budget runs short. Competitive intel is the first step to skip.

The AI prioritizes customer base and tool stack research because those signals have the highest impact on qualification accuracy. If the budget is tight, competitive intel is the first step to skip.

Three boolean flags that feed into disqualification. The researcher sets three detection flags based on what it finds. These matter because they become hard rules in the next phase.

• is_competitor: True if the company sells a product that directly competes with yours (as defined in the ICP Config product field). The researcher looks at the company's product description, positioning, and market category. If your product is a customer intelligence platform and the researched company also sells customer intelligence, this flag gets set.
• is_b2c: True if the company sells primarily to consumers, not businesses. The researcher checks for consumer pricing pages, app store listings, direct-to-consumer language, and the absence of B2B indicators like "enterprise," "teams," or "organizations."
• is_gov_edu: True if the domain ends in .gov or .edu, or the company name includes "University," "Department of," "Ministry of," or similar institutional markers.

These aren't soft signals. They become hard disqualification rules in the Qualify phase. If the researcher flags a company as a competitor, no amount of other positive signals will save it in qualification. The researcher is explicitly instructed to be factual and flag what it finds. It doesn't try to judge whether a competitor might still be a good partnership target. That judgment is deliberately excluded from the research step.

What comes out. Research produces a structured intel package:

• Employee count (estimated range, like "50-100" or "200-500")
• Customer base profile (B2B or B2C, estimated customer count with evidence source, customer segments served, notable customers, presence on G2 and Capterra with review counts)
• Tool stack (CRM platform, customer success tools, analytics tools, tech stack signals from job postings, integrations page URL)
• Growth signals (recent funding, hiring activity, growth trajectory, notable recent news)
• Competitive intelligence (existing solution for the problem your product solves, solution maturity level, specific competitive tools detected)
• Evidence array (3 to 6 key factual findings with source URLs, passed directly to the qualifier)
• Detection flags (is_competitor, is_b2c, is_gov_edu)

Every field follows a strict rule: null over guessing. If the researcher didn't find evidence of a CRM platform, the field is null, not "probably Salesforce." The qualifier needs to know the difference between "they use HubSpot" and "we don't know what they use." This discipline in the research output is what makes qualification reliable.

Research produces raw evidence. It doesn't decide anything. That's the qualifier's job.

Phase 3: Qualify, No Web Searches, Pure Analysis

The qualifier receives everything that Discover and Research already gathered and makes a decision: is this prospect worth pursuing, and if so, how hard?

Why zero web budget matters. By qualify time, all web data has been collected. The qualifier works with the same evidence every time. Run it today, run it next week with the same research data, get the same tier. You know exactly what qualification costs per prospect because there are no variable web search charges. And the qualifier can't go down a rabbit hole and find some obscure signal that changes its mind. It works with what it has.

How the AI scores prospects. The qualifier assigns one of three ICP tiers based on how many of your qualification signals it can confirm in the research data:

Tier A, High Intent. Requires 3 or more qualification signals from your ICP Config to be confirmed, plus at least one urgency trigger. Urgency triggers include recent funding (budget available, growth pressure), rapid growth or scaling (pain increases with scale), hiring for roles matching your target personas (investing in the problem area), no existing solution detected (greenfield opportunity), or public churn and retention concerns (reviews, Glassdoor, news). Tier A prospects are the ones where timing and fit align.

Tier B, Good Fit. Two or more confirmed signals, but the urgency isn't there. The company matches your target profile but may not feel the pain acutely yet. Worth outreach, lower priority than Tier A.

Tier C, Worth a Shot. One signal or a partial match. Right vertical but limited evidence of fit.

Sales Priority Score. On top of the tier, the qualifier calculates a composite score from 0 to 100.

A Tier A prospect with strong signals across all factors scores near 100. A Tier C prospect with limited evidence might score 15 to 20. The score gives you a single number to sort your pipeline by when deciding where to focus outreach effort.

Fit Score. Alongside the sales priority score, the qualifier calculates a separate fit score (also 0-100) that measures how well the prospect matches your product specifically, not just their general attractiveness as a lead. The fit score weights four factors: ICP alignment (how well qualification signals and vertical match), selling context relevance (direct need for your product and use-case fit), buying readiness (budget signals, evaluation activity, urgency), and accessibility (decision-maker reachability and company size fit). The weights emphasize ICP alignment and selling context over readiness and accessibility, because a great-fit company that isn't ready to buy today is still a better prospect than one actively looking for something you don't quite solve.

The distinction matters in practice. A well-funded, fast-growing SaaS company might score 85 on sales priority because it looks like a great lead on paper. But if it already has a mature solution in place and no pain points your product addresses, the fit score might be 40. The sales priority score tells you "this company is worth selling to." The fit score tells you "this company would actually benefit from your product." Both numbers appear on every qualified prospect.

Hard disqualification rules. Before any scoring happens, the qualifier runs boolean checks on the research flags. Competitors are auto-disqualified. B2C-only companies are disqualified. Government and education entities are disqualified due to long procurement cycles. These checks use the is_competitor, is_b2c, and is_gov_edu flags set by the researcher.

This is where rules protect you. An AI might see an interesting angle for reaching out to a competitor. Maybe they're hiring for a role that suggests they need your product. The AI could rationalize it. Maybe their blog post mentioned struggling with the exact problem you solve. An AI evaluating the evidence alone might think "worth a shot." The rules engine says no. Competitors are competitors. The check is binary, and the AI can't override it.

The qualifier also evaluates prospects against your ICP Config's disqualification signals. If you defined "government contracts only" as a disqualification signal and the research found that this company sells exclusively to government agencies, it gets flagged out. If you defined "pre-revenue startup" as a disqualification signal and the research found no customers and no revenue, the prospect is disqualified. These are your own rules, applied consistently to every prospect.

Revenue opportunity mapping. The qualifier also estimates the potential deal size based on your ICP Config's pricing information and the prospect's characteristics. A well-funded company with 500+ customers and rapid growth is likely a top-tier plan buyer. A smaller company with limited growth signals is likely a starter plan or trial conversion. This mapping helps you prioritize outreach by expected value, not just fit.

What comes out. Each qualified prospect gets a full assessment:

• Qualified boolean (pass or fail)
• ICP tier (Tier A, Tier B, Tier C, or Disqualified with reason)
• 2 to 4 outreach hooks referencing specific research findings
• Buying signals (budget indicators, evaluation activity, urgency triggers)
• Pain signals (problems the prospect faces that your product addresses)
• Fit score (0-100, how well the prospect matches your product)
• Sales priority score (0-100, composite score for pipeline sorting)
• Revenue opportunity (estimated tier, expansion potential, reasoning)
• Reflection logic (detailed reasoning chain explaining every scoring decision)

The outreach hooks are worth highlighting because they represent the most direct value the pipeline delivers to a sales rep. These aren't generic templates like "Your company could benefit from our product." Each hook references a concrete finding from research and connects it to your value proposition.

Good hooks look like this: "You have 500+ B2B customers and just raised a Series B, at this growth stage understanding which customers will churn saves you 10x the cost of acquiring new ones." Or: "Your G2 reviews mention onboarding complexity, profiling your customer base by segment helps you tailor onboarding per tier." Or: "Post-acquisition, you are merging two customer bases, our tool profiles and segments them in seconds so you can prioritize retention."

These hooks only work because Research found the customer count, the funding round, the G2 reviews, or the acquisition news. Qualify connected those facts to the ICP value prop and generated an opener that a sales rep can use in the first email with minimal editing. The qualifier is explicitly instructed to reject generic hooks. "Customer intelligence is important for your business" wouldn't pass its own validation rules.

Phase 4: Enrich, Find 3 Contacts, Verify Their Email

Enrichment takes a qualified prospect and finds the people you should actually talk to. The phase has a fixed search budget per prospect, and it targets three specific roles.

Three contacts, three roles. The enricher looks for a champion (the evaluator or user of your product), an economic buyer (budget holder), and a technical evaluator who influences the decision from a technical angle. These map to the personas you defined in your ICP Config.

The AI adapts by company size. For companies under 50 employees, the CEO or founder often doubles as champion and buyer. The enricher adjusts its search to find 2 to 3 people total without wasting searches looking for a VP of Sales at a 15-person startup that doesn't have one. For companies with 50 to 200 employees, it follows the ICP personas directly plus one level up for the budget holder. For 200+ employees, it searches for the most senior persona match, their VP or Director, and a technical peer.

AI contact discovery follows a structured protocol. The search budget is split into two phases: finding the right people and finding their emails.

Phase A focuses on finding the right people. The AI searches for each role (champion, economic buyer, technical evaluator) using your ICP persona titles, targeting LinkedIn profiles and company team pages. If your personas include "VP Sales" and "Head of Customer Success," the AI searches for those exact titles at the target company.

Phase B shifts to email discovery. This is where the AI gets creative. It checks data provider sites like Hunter.io, RocketReach, SignalHire, and Apollo for the email format at the target domain. It also searches directly for contact names plus the company domain.

Phase C pulls the company's team page, about page, or contact page looking for mailto: links, team listings with email patterns, contact forms that reveal the email domain, and footer emails. Even a generic "info@company.com" confirms the email domain and eliminates one variable from the pattern guess.

Email pattern deduction is the most interesting AI reasoning step in the entire pipeline. The AI takes whatever email signals it found and applies deduction logic:

• Found john.doe@company.com? Pattern is first.last@domain. Apply it to all contacts.
• Found jdoe@company.com? Pattern is flast@domain.
• Found john@company.com? Pattern is first@domain.
• A data provider shows "Email format: first.last"? Use that.
• Partial email like j***@company.com? Confirms the domain and the initial.

When multiple patterns could match, the AI uses the most statistically common B2B email format as the default and ranks alternatives by prevalence. The deduction logic considers evidence strength: a confirmed example from the company's own website outweighs a third-party data provider's format claim.

Each contact gets an email confidence rating: "verified" if the exact email was found in a search result or on the website, "high" if a pattern was detected from a data provider and applied to the name, "medium" if the pattern was inferred from a generic email plus a common format, and "low" if it is a pure guess with no confirming signals. This confidence rating carries through to the prospect record so your sales team knows how much to trust each email before sending.

SMTP verification is where verified code takes over, and it's the clearest example of why the deterministic/AI distinction matters in practice. After the AI guesses an email address for the primary contact, the pipeline runs a multi-step verification process. This is entirely rule-based code with no AI involvement. No model confidence scores. No "probably valid." The mail server either confirms the mailbox exists or it doesn't.

First, an MX record lookup to find the company's mail server. If no MX record exists for the domain, the email is immediately marked as invalid (result code: mx_not_found).

Second, the pipeline connects to the mail server on port 25 and issues an SMTP RCPT TO command for the guessed email address. This is the same protocol that mail servers use to verify recipients before accepting delivery. The mail server responds with a status code: 250 means the mailbox exists and would accept mail, 550 means the mailbox doesn't exist, and various other codes indicate temporary issues (greylisting, rate limiting, etc.). No email is sent. The server simply confirms whether that mailbox would accept delivery.

The proxy exists because most cloud hosting providers block outbound port 25 to prevent abuse. Our primary server's provider blocks it. The verification is proxied through a lightweight service on a separate server where port 25 is open.

The verification returns clear result codes: the mailbox exists, the mailbox was not found, the server accepts all addresses (catch-all, meaning specific mailbox confirmation isn't possible), or the check was inconclusive due to network conditions. Each code tells you something different about the email quality, and all results are visible on the prospect record.

The re-enrichment loop. Only two result codes trigger re-enrichment: smtp_550_rejected (definitive proof the mailbox doesn't exist) and mx_not_found (no mail server for the domain at all). We call these definitive failures. Other results like catch_all, timeout, or greylisted don't trigger re-enrichment because they're inconclusive, not proof of failure.

When a definitive failure occurs, the pipeline doesn't just mark the email as bad and move on. It re-runs the AI enrichment phase with additional context: which email failed, why it failed, and which contact name to skip. The AI searches for a different person at the same company, using the same search budget. The failed contact's name is passed as a constraint so the AI doesn't find the same person again.

If the second attempt returns a new contact with a different email, that email also gets SMTP verification. If it passes, the new contact replaces the original. If it also fails, the prospect is saved with whatever data was gathered. The pipeline doesn't chase contacts indefinitely. One retry is the limit. We debated this. Spending 2x the enrichment budget to recover a bad email is worth it; spending 5x isn't.

The cost accounting here matters. The re-enrichment runs at no additional credit charge to the user. The credit was already charged for the enrichment phase. The re-run is absorbed as a cost-of-quality measure. Token costs increase (because the AI runs twice), but those are internal COGS, not passed to the user.

The AI makes the creative guess. The code verifies it. If wrong, the AI tries again with new constraints. This is the hybrid workflow neither system could do alone, and it is the pattern you should demand from any tool that claims to combine AI with verification.

An AI can't verify an email via SMTP. A rule-based system can't read a LinkedIn profile and deduce which person at a company is the economic buyer for your specific product category. The magic is in the loop: AI generates, deterministic code validates, failure feeds back to the AI with concrete constraints so the next attempt is better, not random. This is fundamentally different from tools that run AI and verification as separate, disconnected steps. When your AI email guess fails and the system just marks it "unverified" and moves on, you lose the prospect. When the failure triggers a constrained retry with fresh context, you recover it.

This loop is the gold standard for hybrid AI pipelines. When you evaluate any outreach tool, ask: what happens when the AI gets it wrong? If the answer is "we flag it" rather than "we automatically retry with the failure as input," the tool is leaving recoverable prospects on the table.

What Keeps It All Together: The Verified Backbone

Four systems span the entire pipeline and are entirely rule-based. They handle the infrastructure that makes the AI phases reliable in production.

Atomic credit charging. Every credit deduction is a single database call that checks the balance and deducts in one transaction. No race conditions. If two pipeline phases try to charge credits at the same millisecond, one succeeds and the other fails cleanly. Credits never go negative. If there aren't enough credits remaining, the phase stops with a clear error message rather than running on borrowed balance. Credit-based pricing only works if the billing is precise.

Concurrency management. Each organization has a limit on how many outreach jobs can run simultaneously. Each plan has concurrent job limits that scale with the tier. Higher plans get more parallel execution capacity. A global job queue manages execution slots on the server. If the server is at capacity, new jobs enter a queue and the status updates to "queued" so you can see what's happening.

Pause and resume. The pipeline tracks which seeds have been completed during a discovery run. Every time a seed finishes processing, its index is saved. If you pause a job (or it stops due to credit exhaustion), the progress is recorded. When you resume, the pipeline checks the completed seed indices and skips them. No credits are wasted reprocessing work that already finished. The same pause/resume logic applies to all phases, not just discovery.

Cost tracking. Every prospect accumulates token usage across three models: Haiku (economy), Sonnet (standard), and Opus (premium). Nine counters track input tokens, output tokens, and cached tokens separately for each model. This data is visible in the prospect detail view, so you can see exactly where your credits went.

If a prospect cost more than expected, you can look at the token breakdown and see whether it was a large research phase (lots of web content to analyze, inflating input tokens) or a difficult enrichment phase (multiple contact searches needed, inflating output tokens). If cached tokens are high, it means the system prompt was cached from a previous call in the same batch, which reduces costs. This level of transparency is deliberate: when you pay per credit, you should be able to audit every credit.

The pipeline also tracks total COGS per outreach job, so we know what each pipeline run costs us to operate, separate from what it costs you in credits. We publish our unit economics because if you're paying per credit, you should know what each credit actually costs us to deliver.

Error handling and refunds. If an LLM call fails during any phase (API timeout, invalid response, network error), the pipeline catches the exception and refunds the credits charged for that specific prospect. The prospect is marked with an error message so you can retry it later. Credits are never consumed for a phase that didn't complete successfully.

The Full Deterministic/AI Breakdown: 21 Steps Mapped

Here is the framework applied to our own pipeline. Every step labeled. This is the level of transparency you should expect from any vendor you evaluate.

Of the 21 steps, 12 are purely deterministic. 9 are AI-powered. 1 is both. That ratio is deliberate: the majority of the pipeline is predictable, auditable code. The AI handles only the steps that genuinely require judgment.

The deterministic steps handle reliability. Deduplication, cost control, scoring normalization, disqualification enforcement, email verification, and all infrastructure operations. These steps never surprise you. Domain dedup either finds a match or it doesn't. Credit charging either succeeds or fails. SMTP verification either gets a 250 or it doesn't. Same input, same output, every time. They form the backbone that makes the AI steps safe to use in production.

The AI steps handle intelligence. Interpreting whether a web search result indicates a good ICP match. Deciding which of 5 LinkedIn profiles is the most likely champion. Generating a personalized outreach hook from a set of research findings. These tasks require judgment, and that is exactly where large language models add value that rule-based code can't replicate.

One step, the re-enrichment gate, is both. The deterministic code decides whether to trigger re-enrichment (based on the SMTP 550 response code or MX lookup failure). The AI executes the re-enrichment (finding a different contact with fresh constraints). The trigger is deterministic. The action is intelligent. Rules decide when to act, AI decides how to act. This hybrid pattern is the most important architectural insight in the entire pipeline.

Why this split matters for you as a buyer, regardless of which tool you choose. When something goes wrong, you can trace the failure. If a prospect was incorrectly disqualified, the issue is in the research data (AI step) or the disqualification rules (deterministic step, which means your ICP Config needs adjustment). If an email bounced despite passing SMTP verification, the issue is likely a catch-all server that accepts everything during verification but bounces on actual delivery (a known limitation of SMTP-based verification, not a pipeline bug). If a prospect was scored too low, you can check the sales priority breakdown and see exactly which factors contributed.

Ask yourself: can you do the same failure analysis with your current tool? If the answer is no, you are flying blind on pipeline quality.

How to Evaluate Any Cold Outreach Lead Generation Tool

The deterministic/AI distinction is not a Kustiq feature. It's an evaluation lens you can apply to every cold outreach lead generation tool on your shortlist. Here's how to use it.

The Evaluation Checklist

For each tool you are considering, map every step in their pipeline to one of three categories:

Deterministic (rule-based). The step produces the same output every time for the same input. Examples: domain deduplication, MX record lookup, SMTP mailbox verification, database lookups against a known dataset. Ask the vendor: "If I run this step twice with the same input, do I get the same result?" If yes, it is deterministic. If "usually" or "it depends," it is not.

AI-powered (model-driven). The step uses a language model or ML system to interpret, classify, or generate. Examples: ICP signal analysis, contact role identification, outreach hook generation, email pattern deduction. Ask the vendor: "When this step is wrong, how do I trace the failure?" If they can show you what the model saw and how it reasoned, good. If they can't, you are trusting a black box.

Database lookup (static). The step pulls from a pre-built dataset that was compiled at some point in the past. Examples: contact databases, firmographic records, technographic profiles. Ask the vendor: "When was this data last verified, and how?" A 270M-record database that was batch-verified 3 months ago is a fundamentally different asset than a real-time SMTP check against the actual mail server.

Here is the checklist to apply during every vendor evaluation:

1. For each step the vendor claims is "AI-powered," ask: what happens when the AI is wrong? Does the system detect the failure? Does it retry with constraints? Or does it just pass bad data downstream? A tool that flags AI failures and triggers deterministic verification is architecturally superior to one that treats AI output as ground truth.

2. For each step the vendor claims is "verified," ask: verified how, and when? There is a massive difference between "we batch-verify emails quarterly against our database" and "we SMTP-verify each email against the live mail server at the moment of enrichment." Both can be called "verified." One catches bounces before you send. The other catches bounces that existed 3 months ago.

3. For contact enrichment specifically, ask: what is the verification method? Database match (checked the email against a stored record), API validation (checked against a third-party verification service), or SMTP verification (connected to the actual mail server on port 25 and confirmed the mailbox exists). These are three different confidence levels sold under the same word: "verified."

4. Ask: can I see a per-step breakdown of what ran? If the tool shows you one output and you can't trace which steps contributed what data, you can't debug failures. When a prospect turns out to be a bad fit, you need to know whether the AI misclassified them, the research missed key signals, or the qualification rules need adjustment.

5. Ask: what is the feedback loop when verification fails? The best systems use verification failures as inputs to retry with better constraints. The worst systems just mark the data as "unverified" and move on. The difference determines whether you lose a recoverable prospect or save it.

Applying This Framework to Specific Tools

Static databases (ZoomInfo, Apollo, Lusha). These tools are primarily database lookups, not AI pipelines. Their core value is a large, pre-built dataset of contacts and companies. The "AI" features (lead scoring, intent signals, enrichment) are typically layered on top of the static data. The key question: how fresh is the underlying data, and how is it verified? ZoomInfo re-verifies contacts through a combination of community contributions and automated checks, but the refresh cycle means you are sometimes working with data that is weeks or months old. Apollo's 270M+ contacts are impressive in volume, but bounce rates in the 8-12% range for some verticals suggest the verification cadence does not catch every stale record. Lusha verifies through crowdsourced data and direct partnerships. For all three, ask: "If I pull a contact today, when was this specific record last verified?" The answer is usually "we can't tell you per-record" because batch verification does not track individual freshness.

Workflow builders (Clay). Clay's architecture is fundamentally different: it connects to 75+ data providers and lets you design your own enrichment sequence. This means the deterministic/AI split depends entirely on how you build the workflow. Clay itself is the orchestration layer. The data quality depends on which providers you wire up and in what order. The advantage is flexibility. The risk is that you own the verification logic. If you build a workflow that pulls emails from Provider A and doesn't verify them via SMTP before sending, that is your pipeline's gap, not Clay's. Ask: "Which of the 75+ providers do their own real-time verification, and which are serving cached data?" Then ask: "If Provider A returns a bad email, does my workflow automatically fall back to Provider B, or do I need to build that logic myself?" The answer to the second question is almost always "you build it yourself." That is the cost of flexibility.

Manual research. Still the gold standard for personalization. A human SDR notices that the CEO posted on LinkedIn about a specific challenge last week, or that the company's blog tone suggests they value a particular approach. But manual research is 100% AI-powered in the sense that every step requires human judgment, and there is no deterministic verification built into the workflow. When a rep guesses an email pattern and sends a cold email that bounces, the feedback loop is "check the bounce, try again manually." At 20 minutes per prospect, a full-time SDR researches about 20 prospects per day. The pipeline processes 20 in under 30 minutes with comparable factual depth, though it misses social cues and relationship context.

How Kustiq's Pipeline Maps to This Framework

Kustiq's pipeline sits between manual research and workflow builders. You get live web data (like manual research) with automated orchestration (like a workflow builder) but without the maintenance burden of designing and debugging your own enrichment logic. The tradeoff is flexibility: you can't add your own data providers or customize the research protocol beyond the ICP Config. If you need to wire up 12 different data sources with custom waterfall logic, a workflow builder gives you that. If you want a pipeline that works out of the box and gets you from "target profile" to "verified contact with personalized hook" without building anything, that is what Kustiq does.

Where Kustiq falls short. The pipeline produces 3 contacts per qualified prospect. If you need 50 contacts at a single enterprise account for multi-threaded outreach, a contact database with millions of records gives you more volume. Kustiq's contact discovery is designed for quality over volume: the right 3 people with verified emails, not a long list of names with unknown email accuracy. Similarly, if your outreach strategy is pure volume (blast 10,000 prospects per month), the per-prospect pipeline cost doesn't make economic sense. The pipeline is built for targeted, ICP-driven outreach where each prospect gets meaningful research and personalized hooks.

The pipeline's dependence on live web data means results vary by how much public information exists about a company. A well-funded SaaS startup with a detailed website, active blog, G2 reviews, and press coverage produces a rich research profile. A bootstrapped 10-person consultancy with a one-page website and no reviews produces thinner data. The AI fallback helps, but it can't invent information that doesn't exist publicly.

For detailed side-by-side breakdowns of specific tools, see our comparison of the 7 best ZoomInfo alternatives for small business teams, or the direct comparisons: Kustiq vs Clay and Kustiq vs ZoomInfo. If your team uses HubSpot, Kustiq's HubSpot integration syncs enriched prospect data directly into your CRM records, so pipeline results flow into your existing workflow without manual export.

Key Takeaways

• The deterministic/AI split is a buying framework, not a product feature. Apply it to every outreach tool you evaluate. Ask every vendor: which steps are deterministic, which are AI, and what happens when the AI is wrong?

• Demand per-step transparency. If a vendor can't show you a labeled breakdown of their pipeline steps, you can't debug failures. When a prospect turns out to be bad, you need to know whether the AI misclassified, the data was stale, or your targeting needs adjustment.

• SMTP verification is the gold standard for email quality. It checks the actual mail server in real time. "Verified" from a database lookup that was batch-checked months ago is not the same thing. Ask vendors which method they use.

• The re-enrichment loop is the pattern that separates good AI tools from wrappers. AI guesses, deterministic code verifies, failure feeds back to the AI with constraints. This recovers prospects that simpler tools would lose.

• More deterministic steps means more predictable costs. Kustiq's pipeline is 12/21 deterministic. The qualifier uses zero web budget. These architectural choices keep costs predictable. Ask other vendors what percentage of their pipeline is deterministic.

• Live web data beats stale databases for targeted outreach. If you need 10,000 contacts for a volume play, use a database. If you need 50 deeply researched, verified prospects with personalized hooks, you need a pipeline that queries the live web.