Outbound AIBenchmark
What an AI SDR Agent Actually Did Across 9,592 Sequences
We read 9,592 AI SDR agent sequence runs from our own database. 2.8% replied. Here is where the rest went, and a number we published that does not hold.
What we ranThree single reads over Kairon's own production database at 2026-08-11 05:39 UTC, over campaign_sequence_run and campaign_node_run joined to campaign_node: every sequence by status and outcome (9,592 rows, no filter), every skip and exclusion reason, and every node by status and type including how all 2,660 finished connection-request waits resolved, split by whether the sequence warmed up before inviting.
Of 9,592 outbound sequences an AI SDR agent ran on Kairon between 2026-06-18 and 2026-08-10, 273 ended in a reply. That's 2.8%. Three reads against our own production database, run 2026-08-11, show where the other 9,319 went — and which of those losses are the agent working, not failing.
Method, exactly: three reads against Kairon's production database at 2026-08-11 05:39 UTC, over campaign_sequence_run and campaign_node_run joined to campaign_node. Aggregate counts only — no lead names, no company names, no message text, no identifiers of any kind. Read 1 counts every sequence by status and outcome, no filter, no limit. Read 2 counts every skip and exclusion reason recorded against those sequences. Read 3 counts every node by status and type, counts how every finished connection-request wait resolved, and — over those waits that ended in an accept — takes the median and mean of the elapsed time between the node starting and finishing. Nothing below comes from a fourth query.
In plain terms: a sequence is one lead moving through one campaign's full chain of steps — invite, wait, message, a like, a profile visit. A node is one step in that chain. The window covers every sequence that started between 2026-06-18 10:30 UTC and 2026-08-10 18:01 UTC: 9,592 sequence runs, 20,516 node runs.
LinkedIn's User Agreement prohibits automated access to the platform. The numbers below describe behaviour we observed on our own test accounts on the date shown — they are not permission, not a safety guarantee, and not advice to breach that agreement. Your account, your risk.
Our own warm-up number does not hold at this volume
Kairon's own seo-loop documentation states, today, that a campaign which warms up before inviting — a like, a profile visit, before the invite goes out — accepts at 40–66%, against 23% for a bare invite (EXP-000). That is the number we have published. It does not hold in this window.
Read 3 splits the 2,660 connection-request waits that finished by whether their sequence ran a warm-up step before the invite: 1,388 warmed waits, 551 accepted, 39.7%. 1,272 bare-invite waits, 426 accepted, 33.5%. That is a six-point gap — 39.7% against 33.5% — not the seventeen-to-forty-three points the published range implies.
This split is observational, not an experiment, and it cannot support a causal claim. The warmed and bare groups are different campaigns, different audiences, different sending seats, and whoever built each sequence chose warm-up or didn't — nobody was randomly assigned to either group. A six-point gap between two self-selected groups is evidence that warm-up correlates with a higher accept rate in this window. It is not proof that warm-up causes the difference, and it does not tell you what gap to expect on a campaign we have not measured.
Where the other 9,319 sequences went
Read 1 counts every sequence once, by its final status and outcome:
| Status → outcome | Sequences | Share |
|---|---|---|
| completed → skipped | 3,550 | 37.0% |
| active → still running | 2,054 | 21.4% |
| completed → invite_ignored | 1,525 | 15.9% |
| completed → completed | 945 | 9.9% |
| failed → failed | 843 | 8.8% |
| canceled → canceled | 277 | 2.9% |
| completed → replied | 273 | 2.8% |
| completed → excluded | 72 | 0.8% |
| pending_approval → awaiting approval | 39 | 0.4% |
| completed → stopped | 14 | 0.1% |
2,054 sequences are still active and 39 are waiting on human approval — neither has reached a final state. Take those 2,093 out and 273 of the remaining 7,499 resolved sequences replied: 3.6%, not 2.8%. Both numbers are correct; they answer different questions. 2.8% is what every sequence the agent has touched has produced so far, including ones still running. 3.6% is what a sequence that actually finished produced.
Read 1 does not break failed down by cause — that would be a fourth query we did not run, so we do not know why any of the 843 failed sequences failed. invite_ignored is the largest single completed outcome after skipped: an invite went out and the lead let it sit past the wait window without accepting or declining.
The ICP gate is most of the volume, and that is not a failure
Read 2 counts every skip and exclusion reason recorded in the window: 3,237 for not matching the campaign's ICP, 323 for contact history, and 76 in a shape the query didn't capture — recorded as unknown, not as zero. Of those 3,636 reasons, 89% are the ICP gate alone.
3,237 of the 9,592 sequences the agent opened — 34% — were skipped and recorded icp as the reason: the lead did not match the campaign's ideal customer profile. Whether an invite had already gone out to any of them is not something these three reads measure. That is more sequences than replied, completed, or failed, combined. Read as a funnel this looks like loss. Read as a gate, it is the agent screening a lead before it acts on it — the same check a human SDR runs by hand before opening a new tab, done here before a single message goes out.
One contact_history skip, shape only, from Read 2:
{"bucket": "in_conversation", "lastContactAt": "2026-01-19T...", ...}That bucket name is what the 323 contact_history skips have in common: the agent found the lead already mid-conversation somewhere else and did not restart it as a new sequence. We read the shape of one row, not the contents of all 323 — what other bucket values contact_history can hold is unknown to this read.
Node by node: what the agent actually did
Read 3 counts every one of the 20,516 nodes by its type and status. The send actions:
| Node | Outcome | Count |
|---|---|---|
| send_invite | sent | 3,292 |
| send_invite | scheduled | 788 |
| send_invite | failed | 681 |
| send_invite | canceled | 610 |
| send_invite | skipped | 170 |
| send_invite | drafted | 40 |
| send_message | sent | 1,524 |
| send_message | scheduled | 233 |
| send_message | canceled | 128 |
| send_message | failed | 52 |
| send_message | drafted | 51 |
The engagement, wait, and delay actions:
| Node | Outcome | Count |
|---|---|---|
| like_last_post | done | 3,100 |
| visit_profile | done | 3,058 |
| wait_connection_accepted | done | 2,660 |
| wait_connection_accepted | pending | 495 |
| wait_connection_accepted | canceled | 485 |
| delay | done | 2,506 |
| delay | pending | 311 |
| delay | canceled | 144 |
| research | done | 81 |
| research | failed | 14 |
| research | canceled | 5 |
| comment_on_post | canceled | 49 |
| comment_on_post | failed | 13 |
| comment_on_post | sent | 13 |
| comment_on_post | skipped | 11 |
like_last_post and visit_profile are the two most-run node types after the invite itself — over 3,000 each. comment_on_post barely ran at all: 13 sent against 9,592 sequences, with more canceled (49) and failed (13) than sent. research is similarly rare, 81 done. Whatever decides which warm-up steps a sequence includes, likes and visits carry almost all of it; comments and research are the exception, not the pattern.
The connection wait: 36.7% accept, and how long it takes
Of the 3,640 wait_connection_accepted nodes, 2,660 finished, 495 are still pending, and 485 were canceled when their sequence stopped. On the 2,660 that finished, the node's own recorded outcome splits: 977 accepted (36.7%), 1,683 timed out (63.3%) — the same 2,660 the warm-up split above divides by whether the sequence warmed up first.
Time from invite sent to accept, measured on the 977 that accepted: median 6.2 hours, mean 23.2 hours. The mean sitting well above the median means most accepts land fast and a smaller number take much longer — a long tail pulling the average up, not a typical wait that runs 23 hours.
What we did not look at
Three reads, one window, no other query. We did not look at why any of the 843 failed sequences failed, what the other bucket values inside contact_history are beyond the one row shown above, or whether any of this differs by industry, seat, or campaign size. Unknown means unknown here, not zero.
We are also not saying what pace or volume is safe to run. Nothing in these three reads measures LinkedIn's response to sending speed — that is a different question, and the automation-liability note above still applies to everything in this piece, in full.
What this is and isn't
None of this says an AI SDR agent should replace a human one, and none of it says warm-up will produce a better accept rate on a campaign we have not measured — the six-point gap above is a correlation from one window, not a rule to plan around. What it says is what happened to 9,592 sequences an agent actually ran, read once, in full, off our own database, with the losses that are the product working named separately from the ones that are just loss.
The 2.8% above counts whole sequences, across every account sending through the product — and its denominator includes the 3,237 skipped at the ICP gate and the 2,054 still running, none of which sent anything. Counted per send instead, on Kairon's own seats only, we later read the reply rate on 923 LinkedIn sends and found 12.2% of invites drew a reply. The gap between the two is mostly the denominator, not the performance: compare against the per-send number if you are judging copy, and against this one if you are judging a whole enrolment list.
If the question in front of you is what actually restricts a LinkedIn account once you automate outreach at any real volume, we measured our own rate-limit incident rather than repeat a vendor's round number. If the question is which server is doing the driving underneath an agent like this one, we read eleven LinkedIn MCP servers at pinned commits, ours included. And what Kairon's agent runs on is the product this data came out of.