BDR² (styled “bdr2”) is an agentic outbound-sales decision system. That sentence probably raises more questions than it answers, so here’s what it actually means.

What BDR² is not

Before explaining what BDR² does, it’s worth being clear about what it is not:

• Not an AI SDR. It doesn’t pretend to be a salesperson. It doesn’t send emails. It doesn’t “do outreach on autopilot.”
• Not an email automation tool. There is no send button in BDR². The system boundary stops before contacting.
• Not a growth-hacking tool. It doesn’t scrape, spam, or run mass automated sequences.

The one-sentence version: BDR² finds prospects, qualifies them using explicit AI-driven logic, records evidence for those decisions, and produces research and personalization artifacts. It does not contact anyone.

Qualification as evidence

The central idea in BDR² is that qualification should produce structured, persistent evidence — not just a score or a thumbs-up.

Most sales tools give you a lead score or a “fit” rating. Useful, maybe. But it doesn’t tell you why a lead was considered good. It doesn’t let you reconstruct the reasoning six months later. And it doesn’t help if someone (a manager, a compliance officer, a prospect) asks you to justify why you reached out.

BDR² approaches this differently. Qualification is broken into three layers:

Qualifiers

A qualifier is an atomic question evaluated by an AI agent against available data. Examples:

• “Does this company have more than 10 salespeople?”
• “Is this company headquartered in the EU?”
• “Does their website mention outbound or cold email?”
• “Have they hired a new DPO in the last 90 days?”

Each qualifier produces:

• A result (boolean, score, or category)
• Evidence (citations, extracted snippets, data provider fields, or rationale)
• The prompt and configuration used for evaluation (for reproducibility)

Qualifiers are designed to be atomic — each answers one thing. They don’t decide whether a lead is good on their own.

ICQ mask

An ICQ mask (Ideal Customer Qualification mask) is a logical function applied over qualifier outputs. It defines what “qualified” means for a specific customer at a specific time.

The simplest mask is an AND gate: pass all qualifiers, and you’re qualified. Fail any one, and you’re not. But masks can be more complex: weighted scoring, tiered logic, or conditional rules.

The mask is separate from the qualifiers for a reason: qualifiers are reusable across different targeting strategies, while the mask encodes the specific logic for a particular campaign or ICP definition. When your targeting evolves, you version the mask rather than rewriting all your qualifiers.

ICQ result

For each lead, the system computes an ICQ result by running qualifier evaluations through the mask. The result (pass, fail, or score) feeds into the accept/reject workflow.

The operating loop

Here’s how a typical session works in BDR²:

1. Define the target. The user describes who they’re looking for. This can be conversational; the system helps turn a vague description into concrete qualifiers.

2. Seed the list. Start with a small set of companies (5–10) that represent the target. These can be known customers, competitors’ customers, or companies the user suggests.

3. Build qualifiers. Based on the seed and the target description, define 3–5 qualifier questions. The goal is a set where passing all of them is a strong signal of fit.

4. Evaluate and iterate. Run the qualifiers against the seed and early leads. If a good lead fails a qualifier, the qualifier might be too strict. If a bad lead passes all qualifiers, you’re missing something. Adjust.

5. Expand. Once the qualifiers are stable, use the accepted leads to find more candidates via similarity search, data providers, or prompt-based sourcing.

6. Enrich. Accepted leads get enriched with contact information, research summaries, personalization angles, and draft messaging.

7. Repeat. Triage new leads, refine qualifiers, expand again.

For a worked example of this loop applied to niche targeting, see Finding New Leads for Niches. For background on building qualifiers, see What You Really Want in the ICP.

Evidence logging

Every step produces data that gets persisted:

• Qualifier prompts and results
• ICQ mask version
• ICQ result (pass/fail/score)
• Accept/reject decision and timestamp
• Research and enrichment artifacts

This evidence trail is not an afterthought. It’s the point. You can look at any lead and see exactly why it was qualified (or not), what logic was applied, and when the decision was made.

That’s useful in a few obvious ways. You can audit your own targeting decisions and catch problems early. Anyone on the team can see why a lead was pursued without asking the person who sourced it. And if you’re operating under GDPR, you have structured evidence to support a legitimate interest claim for cold outreach.

The accept/reject model

Users manually accept or reject leads based on the ICQ result and any additional context. The semantics are strict:

• A rejected lead is treated as out of scope. It won’t be re-sourced or re-evaluated as long as it stays rejected. Rejections can be reversed, but in practice they stick — the model keeps marginal leads from cycling back endlessly.
• An accepted lead proceeds to enrichment and enters the outbound pipeline.

There are plans for optional auto-reject on ICQ failures, but for now, the human stays in the loop on every decision.

System boundaries

BDR² deliberately stops short of executing outreach. It doesn’t send emails or manage sequences, and it doesn’t decide intent on behalf of the customer.

The system produces inputs to outreach: qualified leads with evidence, research, and draft messaging. What happens next is up to the user and whatever outreach tools they use. (See OpenClaw + BDR² for one approach to the tasks that live past this boundary.)

This boundary is intentional. Compliance responsibility sits with the customer. BDR² supplies the evidence and decision trail that supports a defensible outreach position, but it doesn’t claim compliance on anyone’s behalf.

Who it’s for

The primary users today are small consultancies and agencies running outbound for themselves or their clients. The secondary audience is BDR managers and compliance-sensitive EU teams who need more structure and auditability in their prospecting.

If you’ve ever struggled with:

• Inconsistent lead quality across reps
• Inability to explain why a prospect was targeted
• Scaling outbound research without losing quality
• Meeting GDPR evidence requirements for cold outreach

…BDR² was built for you.

Try it

You can get started at app.bdr2.com. Describe your target, and the system will help you build qualifiers, source leads, and produce research artifacts.