Outbound Engine

outbound-engine

The problem this solves: you're paying for a $700+/mo prospecting stack (Apollo, Hunter.io, whatever else) to do something you could be doing from signals you already have — who's visiting your site and looking like a buyer. One AMM member (Bryan Fikes) already solved this for himself: Smartlead + LinkedIn Sales Navigator + Visual Visitor + his own website + the Search Atlas MCP, no Apollo, no Hunter, 34% cold-email open rate, real sales calls booked. This tool packages that shape — signal in, scored + enriched, personalized draft out, you approve, it loads to your outreach platform — so a second member can run it without reverse-engineering his setup.

What it isn't: an auto-send bot. Every draft this produces sits in a review queue until you approve, edit, or reject it. And in this specific build, even the "load to Smartlead" step is a dry-run preview — it shows you the exact payload that would go out, and calls nothing.

Say this to your agent

"Run my outbound pipeline." (or: "Build my ICP for the outbound engine." / "Show me my outbound review queue." / "Generate my weekly outbound report.")

That's the whole interaction model. Underneath, the agent runs:

cd tools/outbound-engine
python3 run.py pipeline --dry-run   # signals -> enrich -> personalize
python3 run.py review               # approve / edit / skip / reject, interactively
python3 run.py load --dry-run       # preview what WOULD load to Smartlead
python3 run.py report               # weekly HTML report

If config/icp.yaml doesn't exist yet, run python3 run.py wizard first — a short guided interview that builds it.

The pattern (five stages, one review gate)

1. Signals — pull recent website-visitor hits (company, page visited, visit count, referrer type, and a named contact if your signal source resolved one). v1 ships exactly one signal source.
2. Enrich — score each hit against your ICP: industry match, trigger-signal strength (which page, how many visits, paid vs. organic), hard excludes (competitor agencies, .edu domains, your own current clients). This step is plain deterministic logic, not an LLM call — you can read exactly why a prospect got the score it did.
3. Personalize — draft a short outreach email per non-rejected prospect, using your own voice examples as a style reference only — never copied verbatim, never inventing facts about the prospect that aren't in its record.
4. Review (the gate) — every draft is pending_review. You approve, edit, skip, or reject each one before it goes anywhere. This is not optional and not skippable by config — it's the shape of the tool.
5. Load + Report — approved drafts get built into the exact payload your outreach platform would need; the weekly report shows what moved through the pipeline and (once live) what it produced.

Why this build never actually sends anything

Two separate reasons, either one alone would be enough:

• This build's own rule. Real external-send wiring — a live Visual Visitor pull, a live Smartlead POST — is a JD-approval matter, not something enabled during a build. So signals/visual_visitor.py and load/smartlead.py ship as mock/dry-run-only, on purpose, with a LiveModeNotImplementedError that fires if you (or an .env file) tries to flip a live-mode flag.
• An open wiring question. The product spec for this tool explicitly calls for getting Bryan Fikes' field-by-field wiring — his exact Visual Visitor plan/API, contact-enrichment setup, and Smartlead campaign structure — in a 30-minute call before writing the real adapters, so the tool packages his actual reality instead of a plausible-looking guess. That call hasn't happened yet. See README.md's "Live mode" section and the docstrings at the top of signals/visual_visitor.py and load/smartlead.py for the full detail, including exactly what's needed before either adapter can go live.

None of this blocks using the tool today — the whole pipeline (scoring, drafting, the review queue, the report) is real, tested, and runnable; only the two outermost edges (pulling real visitor data, pushing a real send) are intentionally stubbed.

What a good result looks like

• You get a short list of prospects that actually match your ICP, each with a plain-English reason they surfaced — not a firehose of everyone who touched your site.
• Every draft you see in the review queue reads like something you'd actually send, references the real reason the prospect showed up, and never claims a stat or fact that isn't in the prospect's record.
• Nothing leaves your review queue without your explicit approve/edit — the tool cannot send on your behalf even if you wanted it to, in this build.
• The weekly report tells you honestly what's real (prospects surfaced, drafted, approved) vs. what's a placeholder until live sending is wired (opens, replies, calls booked all read "n/a — dry-run build" rather than a made-up number).

How it pairs with the other Founding Circle tools

• bug-hunter and this tool share the same "find-and-report first, dry-run before any write" posture that SECURITY.md requires of anything touching a live account or an outbound send.
• client-dashboard is the natural next step once real sending is live — a client-safe weekly view of pipeline/booked-call numbers, never the machinery behind them.
• connection-monitor is worth putting on top of this once it's live: the moment a Smartlead or Visual Visitor connection silently drops, you want a ping, not a week of an empty pipeline you didn't notice.

Where things land