Lead sourcing with agents that survives review

The thing that breaks an agent-built outreach pipeline is not the sourcing, it is the part where nobody can explain where a name came from. Lead sourcing with agents is outreach automation where a coding agent queries connected tools to find and qualify prospects, while your team still owns scope, review, and verification. The agent will happily fill the pipeline before you have figured out the second half. If you leave receipts in chat, you have built something fast that no reviewer can sign off on.

The fix is not better prompts. It is making every run leave a trail a teammate can read without you standing over their shoulder. Below are the four places these pipelines leak, and a small artifact for each.

Make every sourcing run leave a replay

A sourcing run that lives in a terminal dies in a terminal. If your team runs outreach through the Codex CLI, the commands ran, the work happened, and the reviewer saw none of it. They merge green and trust your summary.

Close that gap with a replay sandwich. Before any PR, the AGENTS.md rules ask for three things in order: one intent line, the command transcript, then a short diff summary. Now a reviewer can reproduce your reasoning without replaying your session. The receipt is the point, not the prose around it.

This is the same move you make everywhere autonomy meets responsibility, and it lands on the Review step of our methodology: the proof shows up in the PR, not in a chat log someone has to dig up later.

Give every MCP connector a card

Prospect data is exactly the data a connector should never touch by accident. Wire up MCP servers in a hurry and you will find one reading something nobody put on the diagram.

So write one card per server and keep it next to the code that calls it. Four lines is enough: what it may do, what it may not, who owns it, how to roll it back. The value is knowing what "off" looks like before an incident instead of negotiating it during one.

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Cursor: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

Make forked agents report back

A parent agent that forks children to enrich and qualify leads gets summaries back, and summaries quietly drop the paths the children actually touched. You green-light a diff you cannot see.

Ask every child to return a small block: paths touched, commands run, and the tests that prove the regression guards held. The parent stops approving mystery work, and you stop discovering surprises after the run.

Give reviewers four gates, not a chat log

Green CI proves the code runs. It does not prove the approach was sane, and people optimize for the checks they can see passing. A decision stub fixes that: the PR template asks for three lines, the constraints you considered, the alternatives you rejected, and your verification proof. The debate moves to explicit tradeoffs.

A reviewer should be able to answer four questions without opening a single chat window.

Here is the checklist a reviewer can paste straight into a PR:

• MCP connectors mentioned (if any) list owners.
• Verification command output is pasted or linked.
• Forked agent work lists parent and child responsibilities.
• Red-folder paths received explicit human acknowledgement.

If the repo cannot clearly say "allowed" and "forbidden," neither can the agent. The same discipline runs through all of agentic coding governance, and the connector half deepens once your agents start hitting vendor APIs, which is its own write-up in headless SaaS for agents.

Keep the hard calls human

Some things stay off autopilot: threat models, customer promises, and any decision about blast radius. Let the agent source and qualify, then route the result through a decision stub and a replay sandwich so a person signs the parts that can hurt the business. For writing those boundaries down, the OWASP Top 10 for LLM applications and the NIST AI Risk Management Framework are the references worth keeping open.

Common questions

• How do I keep lead sourcing with agents reviewable?

  Make every run produce receipts: a replay sandwich in the PR body, a connector card per MCP server, and child receipt blocks for any forked enrichment. A reviewer should be able to trace any prospect back to the commands that found it without replaying the session that ran them. The receipt does the explaining so you do not have to.

• What belongs on an MCP connector card?

  Four lines: allowed actions, forbidden actions, a named owner, and the rollback step. Keep one card per server in the repo, next to the code that uses it, so operators know what "off" looks like before an incident instead of figuring it out mid-incident. Short and current beats thorough and stale.

• Should an outreach agent run without human review?

  No. Hard constraints stay human: threat models, customer promises, and blast radius decisions never go on autopilot. Let the agent source and qualify, then route the result through a decision stub and a replay sandwich so a person signs the parts that can actually hurt the business before anything ships.

• Why not just write a tighter sourcing prompt?

  Because a prompt cannot enforce what a connector is allowed to read. Tuning the prompt for weeks while connector scope stays undocumented just moves the work into PR archaeology. The boundary belongs in the repo, in your .mdc rules and connector cards, where it holds across runs instead of living in one conversation.

Next move

If your pipeline needs receipts before it needs more prospects, our training installs this workflow with your team on a live repo. Start with a connector card for the one MCP server your sourcing agent already calls.