Agent-driven lead gen,
defined.

1. What "agent-driven" actually means
2. Why the category exists now
3. Three eras of outbound: database, workflow, agent
4. The operator-vs-driver split
5. What agents fix, and what they do not
6. How to evaluate an agent-driven tool
7. Frequently asked questions

Agent-driven lead generation is outbound work where an AI agent calls documented, authenticated actions on the user's behalf. The available actions depend on the product's real API, permissions, and review gates. In Coil today that means bounded source runs, organization-scoped lead inspection, reviewed recipe execution, exports, and explicit downstream handoffs through the API or JSON CLI. It does not mean a general sequence queue, chat integration, reply loop, or universal audit log.

That definition is doing work. It rules out three things people confuse with the category. The first is a sales chatbot that gives advice but cannot take action. Helpful, sometimes, but the human is still the one clicking through the dashboard at the end. The second is robotic process automation, where a script clicks a browser at recorded coordinates and breaks when the UI shifts a pixel. The third is a workflow builder where a human stitches steps together and the AI fills in a text field somewhere in the middle. None of those are agent-driven in the sense this primer uses.

The shared property of agent-driven tools is that the tool exposes an action surface the agent can reason about and call. That surface is typically delivered as a Model Context Protocol skill pack, but it can also be a CLI with structured output or a REST API with action-shaped endpoints. The shape matters more than the protocol. An endpoint named createScrape with a typed input schema is something an agent can use. A page-scraping bot driving a hidden Chrome window is not.

You can test whether a tool is genuinely agent-operable by asking whether the agent can call a useful, bounded action through a supported interface, receive structured state, and remain attributable under the same organization and role policy as other actors. Completeness is a separate question: consequential actions may require human approval, and products should publish their parity gaps instead of hiding them.

The category did not exist two years ago. It exists now because four things landed roughly together, and each one was necessary. Without all four, the version of agent-driven outbound described above would not work in production.

The first thing is tool-use itself. Frontier models gained reliable structured tool-use during 2023 and 2024. Before that, an agent could draft a function call but would routinely hallucinate parameters, skip required fields, or invent endpoints. By late 2024 the major model families could call dozens of tools in sequence, recover from errors, and reason about which tool to use for which subtask. That is the floor the rest of the category is built on.

The second thing is the Model Context Protocol. Anthropic published MCP as an open standard in November 2024. Before MCP, every agent integration was bespoke: an OpenAI function definition here, a custom adapter for Claude there, a different shape for each new model. MCP gave the industry a single way to describe tools, resources, and prompts that agents could consume. The protocol is supported in Claude, in third-party IDEs like Cursor, and in a growing list of MCP-aware clients. For a product that wants to be usable from any AI the buyer happens to use, that is the unlock.

The third thing is the rise of agent-native runtimes outside of consumer chat. Developer environments like Cursor and Claude Code, multi-agent platforms like Manus, and a long tail of open-source agent frameworks all converged on tool-use as the primary interaction pattern. The agent is no longer just a chat window. It runs in the terminal, in the IDE, in scheduled background jobs, and increasingly inside other SaaS products. Each of those runtimes needs tools, and the tools have to be the same ones the human-driven flow uses or the data diverges.

The fourth thing is buyer behavior. The kind of founder running their own outbound spent 2024 and 2025 learning to live inside a chat window. They drafted in Claude or ChatGPT, they wrote code in Cursor, they used agents to clean spreadsheets. By the time MCP shipped the muscle memory was already there. Asking that buyer to leave the chat window and go run a campaign in a separate SaaS started to feel like a step backwards. Agent-driven lead gen is the version of outbound that meets the buyer where they already are.

To see what agent-driven actually changes, it helps to compare it to the two previous shapes of the outbound stack. Each era solved a real problem; each one left a residue the next era tried to clear. None of the three is wrong. They are layered, and most teams still run a mix.

The database era was the first wave. The defining products were giant contact databases with filter builders bolted on top. You logged in, you filtered by title and geography and headcount, you exported a CSV, you imported it into a sequencer, you wrote your copy by hand. The good thing about this era is that it taught the market that outbound runs on data and gave operators a way to build a list without scraping by hand. The residue it left is that the work of personalization, sending, and reporting is on the operator. The database is a starting point, not a system.

The workflow era followed. Once contact data was a commodity, the bottleneck moved to orchestration: enriching records, scoring leads, branching logic on signals, plugging the output into a sequencer with the right copy. The defining products were workflow builders with hundreds of connectors and a learning curve to match. They are spectacular in the hands of an operator who knows them. The residue is that they transfer the cognitive load from clicking around to building and maintaining the workflow itself. If you are a founder doing your own outbound, you have just acquired a part-time job as an integration engineer.

The agent era is the version that becomes possible once reliable tool use meets action-shaped product interfaces. The category ambition is a set of capabilities a buyer's agent can call across research, drafting, sending, and learning, but each vendor must distinguish that ambition from its shipped surface. Coil currently exposes bounded sources, reviewed recipes, exports, a separate SmartLead handoff, and explicit webhook runs through shared services; automatic signal research, general sender choice, reply analytics, and comprehensive audit browsing remain out of scope. The residue this era is going to leave is genuinely uncertain. Probably some mix of model dependency, policy questions about agent autonomy, and the discovery that some categories of creative judgement cannot be automated. We will see.

The era boundaries are not clean. Some of the database-era products have added workflow features and AI-assisted copy. Some of the workflow-era products have added MCP servers. The point is not that the older products are bad. It is that the shape of the buying decision is shifting from "which tool has the deepest dataset" or "which tool has the most connectors" to "which tool does my agent actually know how to operate." That shift is the one this primer is about.

Here is the framing that makes the rest of the category easier to reason about. Every sales tool has a driver. The driver is whoever holds the operational context, makes the moment-to-moment decisions, and physically issues the actions. The tool itself is the operator: the platform that turns those actions into outcomes. List building is an operator. Sequencing is an operator. CRM updates are an operator.

For thirty years the driver was a human. In the database era it was the founder or the SDR with the Apollo tab open. In the workflow era it was the RevOps engineer maintaining the workflow. The operator stayed the same; the driver got more skilled. The category trend was sold as software, but what was actually happening was that tools got better and humans had to become more sophisticated to extract value from them.

The agent-driven shift changes the driver from a human clicking each step to an agent calling supported actions. That does not automatically create a sequencer, complete parity, or a comprehensive audit log. In Coil, the dashboard, API, and JSON CLI share services for the workflows explicitly documented as supported; human-admin and dashboard-first gaps remain visible. The novelty is in the callable surface and its policy boundaries, not in pretending every outbound layer is already unified.

In practice the split shows up in where repeatable operations happen. A human can use the dashboard, while an approved machine actor can use the authenticated API or JSON CLI against the same supported services. Time to result still depends on provider latency, fetch caps, data quality, recipe complexity, and human review. Costs likewise depend on the chosen providers; Coil shows guidance and requires confirmation where a guarded run can incur spend rather than promising a fixed speed or saving.

The split also clarifies a question that confuses early evaluators. People look at agent-driven products and ask whether they are still buying software or now buying labor. The answer is software. The agent is not a person; it is a driver. The buyer still owns the campaigns, the data, the sending domain, and the strategy. What they are buying is the platform that turns the agent's actions into pipeline. The labor question only enters if you let the agent run unsupervised on irreversible actions, which is a policy choice, not a category property.

The honest version of this category is shorter than the marketing version. Agents fix a specific cluster of operational problems in outbound. They do not fix the hardest problems, and the field is full of products that pretend otherwise. The list below is what the agent can actually take off your plate when the surface is built right.

List assembly is the cleanest current win. An agent can translate a request into explicit source filters, admit a bounded provider run after spend confirmation, and return organization-scoped rows for review. Verification or enrichment is a separate reviewed recipe concern, not an automatic property of every source result.

Typed recipe execution is the second win. If an operator supplies attributable research inputs, an approved recipe can transform them through a schema-constrained model step. Coil does not currently discover funding, hiring, or launch events on its own, so generated fields still require review before downstream use.

Durable run inspection is another practical win. Agents and humans can inspect source, recipe, and webhook execution through organization-scoped API and CLI surfaces. Reply triage, variant reporting, and campaign analytics remain in the sender or analytics system today.

The things agents do not fix, and probably should not, start with deliverability. Whether your emails land in the inbox is a function of your sending domain, your warming history, your provider's shared IP reputation, and your content. An agent cannot fix a cold domain or a broken SPF record. A configured SmartLead connection supports a separate direct handoff; an admin-published webhook automation can deliver approved fields and records its own result. Warming, inbox placement, and campaign controls stay in the external sending system.

Ideal customer profile definition is the next thing agents do not fix. An agent will cheerfully run any ICP you describe, including the wrong one. Knowing which segments respond, which deals close, and which customers are worth pursuing is a judgement call that depends on context the agent does not have. The third thing is creative positioning. An agent can write a competent opener for the angle you give it. It cannot tell you whether the angle is good, whether the category framing is fresh, or whether the message will land with this audience next quarter. That is still your job. The agent is a powerful driver, but the strategy belongs to the buyer.

The category is new enough that a lot of products are stretching the label. Here is a short buyer's checklist for separating real agent-driven tools from chat veneers. Each item maps to a concrete question you can ask a vendor and verify in a ten-minute trial.

First, ask whether the tool has a documented machine action surface or only a chat wrapper. The tell is a published capability matrix: each supported action should name its API, structured CLI or skill contract, role boundary, and known gap. Do not infer MCP support or perfect UI parity when a vendor has not shipped and evidenced it.

Second, look at whether the API is action-shaped or chat-shaped. Action-shaped APIs have endpoints like createList and queueSequence with typed inputs and outputs. Chat-shaped APIs ask the caller to send free text and hope the parser figures out what they meant. Agents do better with the first; humans writing scripts do better with the first too.

Third, check the operational record. Consequential workflow transitions should retain organization scope and an actor type that distinguishes a human from a machine identity. Ask the vendor exactly which actions emit durable activity and which remain request-log only; “everything is audited” is not useful without that coverage evidence.

Fourth, look for admin gates on irreversible actions. Sending a thousand emails is irreversible. Deleting a campaign is irreversible. The right pattern is that some actions require a human role to confirm, not that all actions are equally open to the agent. If the tool does not distinguish reversible and irreversible operations, the category is not mature yet on that surface.

Fifth, check the deliverability handoff. The platform should not pretend it owns the inbox. It should make the boundary explicit, record what it handed to the buyer's sending tool, and stay out of the warming story unless it actually operates that infrastructure. Coil records delivery results for explicit reviewed webhook runs; SmartLead is a separate direct handoff, and the sender owns mailbox health and inbox placement.

If you want the product-level version of this primer, the surface Coil ships is documented across the product overview, the agent API, and the recipe library. The companion pillars cover the buyer wedge in AI cold outreach for founders and the operating method behind the product in the Coil methodology. Background on who maintains this is on the about page.