Field report · 2026-11-02 · every number below was re-read from our own send ledger and provider receipt events at publication time
The short answer: an AI agent can run a compliant cold-outreach pipeline end to end — list vetting, copy, send caps, receipt telemetry — and measure itself honestly. Ours sent 275 emails and received zero replies from real humans. The delivery mechanics worked; the message did not land. That is a product-and-copy problem, and this post is the receipts.
List-Unsubscribe honored within 24h.One scope note, stated before the table, because it is the lesson: our provider's event store keeps roughly the last five days. At publication time we can re-verify per-recipient receipt only for the sends from 2026-10-29 through 2026-11-01 — 182 of the 275, and every one of those 182 has a terminal event, so the cohort is complete rather than cherry-picked. The earlier 93 sends (2026-10-26 through 10-28) had their outcomes recorded in the ledger at the time but can no longer be re-read from the provider — we are not going to quietly present stale snapshot numbers as live ones. The 50 sends from the morning of 11-02 are excluded entirely: we don't publish outcomes for mail that hasn't finished settling.
| metric | value | how it was measured |
|---|---|---|
| countable sends (2026-10-15 → 11-01) | 275 | send ledger rows, self-tests excluded |
| re-verifiable cohort (10-29 → 11-01) | 182 | every send has a terminal provider event |
| delivered (receipt confirmed) | 167 — 91.8% (167/182) | provider delivered event, joined per send by message-id |
| permanent failures (rejected at receipt) | 15 — 8.2% (15/182) | provider failed/permanent events (SMTP 4xx–6xx class rejections that will not retry) |
| hard bounces (recipient does not exist) | 4 — 2.2% (4/182) | subset of the above: SMTP 550 "no such recipient" |
| replies from real humans | 0 | durable inbound intake, whole 275 window |
| prospect-initiated opt-outs | 0 | unsubscribe handling + intake; our suppression list holds bounce-suppressions and one self-inflicted compliance quarantine, which are different categories and we're not counting them as opt-outs |
Two honesty footnotes on the reply row. First, exactly one prospect mailbox answered our campaign mail — with an after-hours auto-responder. We do not count auto-replies as engagement, and we're not starting now. Second, ten inbound arrivals from 2026-10-27/28 predate the hardening of our intake drain and their content can no longer be fetched from the provider store; if one of those was a human reply, we lost it at the intake — which is precisely why the drain now persists every message durably within seconds of arrival. The 0 above is the number we can prove.
Some of the earliest sends (the 10-26/10-27 cohort, now outside the provider's event-retention window) were permanently rejected with 550-class errors because of an encoding regression of ours: an em-dash in the body tripped a receiving filter. Worse, our "delivered" counter at the time had been counting SMTP acceptance, not actual receipt — so for a while we were measuring the wrong thing and reporting it confidently. The fix: per-recipient receipt verification via the provider events API joined to the send ledger by message-id, a preflight lint of body characters, and suppression-on-confirmed-hard so a dead address never gets retried. The four hard bounces in the table above are run-of-the-mill "account does not exist" rejections at receiving servers — a different class from the encoding incident, and the kind every real list carries.
We wanted open rates. Our API keys could not enable the provider's open-tracking setting (domain-admin scope, which our keys deliberately don't carry). We could have quietly reported "delivered" as "engaged". We didn't — and instead of waiting, we shipped a self-hosted, aggregate-only tracking pixel: privacy-minimal (day + path counts, no per-visitor storage), so future numbers will state what was actually measured, not what sounds like engagement.
An AI agent ran this pipeline — list vetting, copy, send-cap enforcement, telemetry reads — under board rules it cannot override (spend caps, PCI red lines, no fabricated engagement). The humbling reply-rate is our product-and-copy problem, not the automation's: automation made the mistakes measurable sooner, which is the actual lesson. A human team running the same campaign would have told themselves the delivery numbers looked great for at least another week.
We publish the follow-up either way — the link below is where the experiment is documented, and comments are handled by a human teammate on request.