DEV Community

Axel Freeman
Axel Freeman

Posted on Originally published at tapacapi.com

Your outbound pipeline has three steps, and the agent only sees one of them

Three steps stand between an empty list and a sent email: find the contact, verify the address, send. When a human runs that pipeline, all three steps happen in one place and one brain. Move the pipeline into an agent and the steps stop being visible to each other, which is where the bounce rate comes from.

What each step can actually see

Step What the agent sees What it cannot see
Find Search results, names, addresses Whether any address still works
Send A successful API response Whether the mailbox existed
Bounce Nothing — it lands in a human inbox, days later That its own send caused it

That last row is the whole problem. Bounce reports are asynchronous and addressed to a person, not to the agent's context window. An agent that books 400 sends from a search result has no feedback loop that says "37 of these were dead". The human finds out from the provider's reputation dashboard.

Why "verified at import" does not survive the gap

Data decays between the moment it is validated and the moment it is used. The published numbers on this are not subtle:

  • 23% of contacts change jobs every year (ZoomInfo, 2025)
  • 40% of email addresses are dead within two years (NeverBounce)
  • Freshly collected data outperforms stored databases by 42% (Harvard Business Review, 2024)

A list verified last quarter is a list with an unknown number of dead rows today. For a human, that shows up as a slightly worse reply rate. For an agent running on autopilot, it shows up as a send reputation event nobody planned.

The fix is structural, not a better list

If the agent can only see one step, verification has to be a property of the step it can see. Find and verify in the same call, so the thing the agent books already carries its own verification state:

curl -s -X POST https://tapacapi.com/v1/contacts/search \
  -H "Authorization: Bearer $TAPAC_KEY" \
  -H "Content-Type: application/json" \
  -d '{"industry":"saas","job_titles":["head of growth"],"verify":true}'
Enter fullscreen mode Exit fullscreen mode

What comes back is a contact with a verification verdict attached, not a row that needs a second, later pass. Same idea through an agent, one line:

npx -y @tapacapi/mcp
Enter fullscreen mode Exit fullscreen mode

The practical result of verifying at the moment of use is a bounce rate of 2-5% instead of the 10-35% that stored databases produce. That is not a claim about better data — it is a claim about a shorter gap between verification and send.

What this does not fix

  • A catch-all mail server accepts anything; a probe against it returns unknown, not verified. Unknown addresses still need judgement.
  • SMTP probing is not free of rate limits per domain. High volume needs pacing, which the server handles rather than the caller.
  • The pipeline still needs a human for the last decision. The point is that the human decides with a live verdict in hand, not a stale list.

The three steps are not going away. They just cannot be allowed to live in three different places, one of which the agent can never read.


TAPAC is an MCP server that searches B2B contacts by industry, title, size and location, and verifies each address over SMTP at the moment of use. Pay per use, $0.10-0.50 per contact, 100 free searches. Sources for every number above: AGENTS.md.

Top comments (0)