AI-Powered Sales Outreach Engine
Personalised outreach at scale, on your own hardware.
A custom system designed and built to run B2B prospecting end-to-end. Researches prospects, writes personalised emails in the sender's voice, schedules and sends safely, and keeps every account moving, with a human reviewing, not retyping.
Running outreach across the Nordics, Baltics and Netherlands: thousands of prospects, dozens of live accounts, and a CRM that does not research, write, or follow up on its own. Done manually, true personalisation does not scale. Done with templates, response rates collapse. This system eliminates that trade-off.
Privacy by architecture, not policy
What it does
Researches every prospect automatically
A research engine profiles each company and contact (what they do, their tech stack, competitive replacement signals, country-specific buying culture) and writes a structured dossier with a personalisation hook. 45 deep-research reports generated; 6,675 prospects profiled across 9 countries.
Writes in the sender's voice, not AI voice
A multi-stage writing pipeline drafts each message, then runs it through automated editorial gates: mechanics, fact-checking, voice-match, and an 'AI-tell' detector that strips the giveaways that get cold email deleted. Anything that fails is held back rather than sent.
Sends safely and on schedule
A sequence scheduler enrols prospects into multi-step campaigns with a send-claim architecture: idempotency keys and fail-closed guards so nothing double-sends or loops. Every send is logged and auditable. 670 emails drafted, 482 sent, across 11 campaign types.
Connects without API access
Reverse-engineered session-replay integrations for HubSpot CRM, Apollo.io, and a licence portal where no developer API was available. Live CRM, enrichment and licensing data surfaces directly into the workflow. Website-visitor signals (790 companies tracked) feed warm leads in automatically.
Keeps the pipeline warm on its own
Daily automations graduate new prospects into campaigns, draft follow-ups for deals that go quiet, and send a morning briefing, so accounts keep moving without manual chasing. Live opportunities at SSAB, Eidsiva, GleSYS, Vektus and others sourced through the system.
By the numbers
Figures pulled live from the system's database. Conversion and reply rates are deliberately omitted, as they are not yet reliably tracked. The honest proof point: sourced live deals including SSAB, Eidsiva and GleSYS.
6,675
Prospects researched & profiled
670
Personalised emails drafted
482
Emails sent through the pipeline
Which accounts have gone quiet in the last three weeks?
12 accounts with no inbound since 20 Jul. Highest value: SSAB (licence renewal, Q3), Eidsiva (pilot scoped 2 Jul). Follow-ups drafted for review.
Draft the follow-up for SSAB in my voice
Draft ready. Passed mechanics, fact-check and voice-match. Held one claim for review: renewal date cited from CRM, last updated 14 Jul.
Privacy and data flow
The system runs on an NVIDIA DGX Spark, not on rented cloud infrastructure. Prospect records, CRM data, and licensing information live on the device and stay there. There are three data paths, separated by design.
Local-only automation
Pulling firmographics, enriching contacts, reconciling licences, and writing the results back to the CRM all run as deterministic processes on the device. No model is involved and nothing leaves the hardware.
Local-model generation
Open-weight models running on the DGX Spark do the bulk of the drafting, research and editorial work. Prospect data is processed on-device and never transmitted.
Controlled frontier escalation
When a task genuinely needs frontier reasoning, Claude (Opus) is called across a single, deliberate boundary, and only the minimum, abstracted context crosses it. Customer-identifying detail is held back on the device.
What makes it different
Privacy by architecture, not policy
Generation, enrichment, CRM and licence operations run on a single device under direct control. The frontier model is an opt-in escalation across a controlled boundary, not the engine the system depends on.
Frontier where it counts, local everywhere else
Open-weight models handle volume and routine reasoning on-device; Opus is reserved for the hardest judgement calls. Cost and exposure both scale with how rarely the boundary is crossed.
One egress chokepoint
A single LLM client mediates every model call. The routing rule (local by default, frontier only when required, sensitive data never raw) is enforced in one place and is auditable.
Stack
Hardware
NVIDIA DGX Spark: GB10 Superchip, 128GB unified memory, NVMe storage. Runs entirely on-device.
AI Models
Open-weight models locally for drafting, research, and editorial gates. Claude (Opus) reached headlessly only when frontier reasoning is required.
Orchestration
Claude running headlessly as the orchestrator. It routes each step to a local model or the frontier model through a single LLM client.
Backend
Python (FastAPI) services, a sequence scheduler with send-claim/idempotency architecture, and a React dashboard.
Integrations
Reverse-engineered session-replay bridges to HubSpot CRM, Apollo.io where no developer API exists.
Security
Hardened Linux, TOTP-gated administrative access, least-privilege read-only roles, and full audit logging of sends and model egress.
The same principle, applied to your outreach
The system is a specific answer to a specific problem. The underlying principle applies broadly: most sales and GTM functions can be restructured so that the sensitive work stays on your hardware, the AI is directed rather than trusted, and the human in the loop reviews decisions instead of making them one at a time.