How to build an agentic M&A flow that discovers leads in your sleep

Agentic SDRs are having their moment, and deservedly so. Point an agent at your market, let it research and draft, wake up to a queue worth reviewing. The good ones work, we build for the teams shipping them, and the tooling has come a long way in a year.

The noise comes from everyone else. Timelines are full of screen-recorded demos where the agent looks brilliant and nobody ever shows where the leads came from, because there was no trigger underneath it, just a static list being researched very quickly. That gap is what separates the builds that hold up from the ones that only look good in a clip, and it is the whole subject of this guide.

So we did the tenth episode of the podcast live, with Francesco Prano, a partner at the RevTech Accelerator who advises on exactly this problem. He did not bring slides about the future. He opened Slack and showed a play that had run ten days earlier, starting from a $7.8B acquisition he had not heard about yet.

The full conversation is below, and I would watch the middle third if nothing else. That is where he stops describing the idea and opens the thing that actually ran.

The shift that makes an agentic M&A flow possible

Francesco frames the last few years as one long move in who does the orchestrating, and I would push everyone to be honest about which stage they are actually standing in. Most teams I speak to describe themselves as further along than they are, usually because one workflow somewhere is agentic and the other forty are still a person and a spreadsheet.

1. Stage 1Human-led
   A person hunts for the data, pulls it in, drops it into the CRM, and writes the notes. Tools help at the edges, but the operator is the orchestration layer.
2. Stage 2System-led
   Rule-based automation. If this, then that. It scales the repetitive part and stays brittle, because every branch was written by hand and every new case needs another one.
3. Stage 3Agentic
   The agent holds the goal rather than the steps. You give it context and access, it works backwards into the process, and it uses whatever tools it has to reach the outcome. This is where the play below runs.
4. Stage 4Autonomous
   The system decides what to pursue as well as how. Real, coming, and not what most teams should be attempting while stages one and two are still unmapped.

The barrier between stages is not capability. It is trust. Moving a team from copy-paste operations to an agentic system asks people to hand over judgement to something they cannot watch, and resistance to that is reasonable rather than a problem to route around.

There is an upside hiding in the chaos, and it is the thing Francesco and I keep coming back to. The people who never caught up with the first wave of technical tooling skipped a generation of complexity. The interfaces got friendlier faster than the laggards fell behind, so what is left to learn is strategy rather than syntax.

How the agentic M&A flow is built

Francesco's setup is deliberately small. One agent living in Slack, connected to his Notion and to the Signalbase API. Four pieces, each with one job:

Step 1: Write your context down before anything else

The agent is only as good as what it reads first. Francesco keeps a Notion page holding the service he sells, the ICP, the personas inside those accounts, the objections he expects, and what a prospect would realistically do instead of hiring him. That page is what makes the play his rather than generic.

Do this part properly and slowly. Everything downstream inherits it, and a vague ICP produces confident nonsense at speed.

Step 2: Connect the trigger, not just the tools

Give the agent an API key and point it at the M&A signal feed so acquisitions arrive as they are detected rather than when someone remembers to check. Pair it with job change signals, because the people worth contacting after a deal are often the ones who just moved into the role that owns the problem.

This is the step the demos skip. Without it the agent researches whatever list you already had, faster.

Step 3: Define the play in one instruction

Francesco asked for a specific outcome rather than a task list: pull high-urgency signals, find these personas at those companies, research them, draft outreach positioning the service as what they need now, and write it all back to Notion. The agent worked out the sequence itself, then asked which signal type to run before starting.

Step 4: Let it qualify before it writes

On the run he showed, it picked Gilead's $7.8B acquisition of Arcellx as the most relevant deal, found ten contacts at the companies involved weighted toward recent movers, and researched each one against the ICP before drafting anything. Qualification first is what keeps the output small enough to be worth reading.

Step 5: Write back with provenance attached

Each Notion record came back with the signal ID and date, the deal context, the specific data reconciliation problem that deal creates, why that persona cares, a 150 to 190 word email referencing the actual deal, and a table showing which field came from which source.

The provenance table is the part I would steal first. Every row says where the fact came from, so what the agent knew versus inferred is visible before anything gets sent. That is the difference between an agent you supervise and an agent you hope about.

Step 6: Put it on a schedule and keep the human at the end

Once the agent knows the playbook it does not need you present to run it. Francesco's read on cadence is that M&A does not demand more than a weekly check, though the API call costs little enough that daily is reasonable, so the practical setup is to have it run overnight and hand you a queue in the morning. The constraint is never the agent. It is how many drafts a human can approve in a day.

Everybody has the same M&A data

The obvious objection to any of this is that acquisitions are public. Anyone can read the same announcement, so where is the edge. Francesco's answer is the one I would give, and it splits in two.

Timing is the first half. A signal is worth something while the window is open. Three separate times in March, companies asked us to pull a signal down because it had surfaced before they were ready to announce it. That is the end of the range worth building on, and it is why his agent checks continuously rather than on a monthly review.

Context is the second half, and it is the one people skip. An evergreen signal is contextual tooling, not straight intent qualification. Plenty of teams see an acquisition and send congratulations on the merger, which is the same generic outreach with a fresher hook. The event should sharpen who is on your list and what you say to them, and then disappear from the message itself. That argument in full is the signal-based copy playbook.

Why M&A is a qualified pain

An acquisition is not interesting because it is big news. It is interesting because it guarantees a specific kind of mess on a known timeline, and somebody inside the company owns that mess.

Two organisations now have to reconcile systems. ERPs have to talk to each other, CRMs have to merge or migrate, and customer data arriving from both sides has to be cleaned before anyone can trust a number. Every delay in that integration compounds into everything downstream, which is why time to value is the metric the acquirer is quietly panicking about.

Francesco borrows Jordan Crawford's pain-qualified segment framing here and it is the right lens, so I will put it bluntly. The signal is not the message. It tells you which people are about to feel a specific pain on a specific timeline, and everything you write should come from the pain rather than from the deal. Send congratulations on the acquisition and you have wasted the best trigger you will get all quarter.

How agentic M&A flows fail

We spent a good part of the episode on this, because it is the part the demos leave out. None of these failures are the agent being incapable.

Underneath all four sits data quality, which Francesco called his sharply voiced opinion rather than a hot take. Records that are stale, duplicated, or scattered across an ERP, a CRM, a warehouse and three external feeds do not get better when an agent starts reading them. They get amplified. Audit what you have before layering anything on top of it.

Our version of the same point: sourcing data is the easy part. Verification and contextualization are what turn a raw mention into something an agent can act on, which is why reading the earliest layer matters more than reading the most convenient one.

Scaling the flow past one operator

Francesco built this for himself, as a solo operator, and he is direct about that being the point. Start small, at your own scale, and prove it before you generalize it.

His sketch of the scaled version keeps an agent at the top and adds a context engine underneath it, holding the ICP, the service library, and the playbooks in one place so every downstream agent reads the same source of truth. Copy generation and delivery then hand off to specialist tools. The shape stays identical. Only the number of agents changes.

On team size his answer was refreshingly unfashionable. Work out how few people you can get away with and move deliberately. I would go further. Most of the agentic projects I watch stall because five people each own a piece and nobody owns the outcome, which is a staffing problem wearing a technology costume.

The boring advice that decides it

I asked for underrated advice at the end, expecting a tactic. Francesco's answer was that the underrated advice is the boring advice. Infrastructure. Hard questions. Documentation. None of it makes a good post, and all of it decides whether the system is still running in eight months.

The counterweight I would add is on the outreach itself. Send the message you would want to receive. Reference something real, keep it short, and let the signal do the qualification while the message does the talking. We put the full version of that in the Claude Code prospecting guide, which is the same architecture Francesco is describing with a different agent at the top.