An AI sales research pipeline connects a defined commercial signal to a repeatable research task and a shared record. In Growthub's walkthrough, Slack supplies daily engagement reports, a research agent finds relevant LinkedIn profiles, and a Google Sheet provides the existing records needed to avoid duplicate work. A separate lane discovers hiring opportunities against an ideal customer profile. The useful design principle is to give each lane a specific input, destination, and completion check.
TL;DR
Use a daily Slack report to identify contacts worth researching. Keep hiring research separate from contact enrichment. Give each agent the exact source, selection criteria, tracker, and schedule. Before enabling repeat runs, prove that it can read the source and check existing records. A successful research run should leave a usable record; it should not be confused with a sent message, a completed application, or a sales result.
Start with the signal your team already uses
The walkthrough begins inside the team's Slack channels, where briefs, actions, LinkedIn outreach, and pipeline reporting are brought together. At 0:17, Antonio describes the daily updates. At 0:35, he explains how reports of email opens and clicks inform the decision to research a contact on LinkedIn and continue the conversation.
This gives the research agent a bounded starting point. It is not being asked to find anybody who might buy. It is being asked to investigate people already present in a particular team report. That distinction makes the workflow easier to review: a researcher can trace a proposed contact back to the report that prompted the task.
For your own implementation, write that relationship into the brief. Specify which report supplies the candidates, which date or reporting period applies, and what information the next person needs. Treat the engagement signal as a prioritization input. The source does not establish that every open or click represents purchase intent, and the article makes no such claim.
Separate hiring discovery from contact enrichment
The video shows two related but different research jobs. At 0:55, the first is a jobs tracker built around the kinds of roles that fit the team's ideal customer profile, or ICP. At 2:15, the second is a daily LinkedIn profile finder driven by the Slack update. Both produce research, but they answer different questions.
Hiring discovery asks which organizations are advertising relevant work. Contact enrichment asks which public professional profile matches a person already identified in a report. Combining both into an undifferentiated lead list would remove the reason each record exists. Keep the source and purpose visible so the sales team can decide what to do next.
The walkthrough also mentions an agent that handles submissions on company websites. That is a downstream activity, not an automatic consequence of finding a job. In a practical implementation, discovery should hand off a verified opportunity before a separately defined application task begins. The same separation applies between finding a profile and sending an outreach message.
Define a research record that another person can use
The Google Sheet is central to the demonstration because it gives the agent somewhere to check existing work and preserve new findings. At 3:40, Antonio describes the test as proof that the agent can read the Slack list and check the Sheet. He explicitly connects that check to avoiding duplicates.
A useful implementation record should preserve the candidate's source, the person or organization being researched, the discovered URL, and the reason the match was accepted. These are recommended review fields derived from the workflow, not a claim that the video displays a particular universal schema. They help a reviewer distinguish an exact match from a plausible guess.
When a match remains uncertain, preserve that uncertainty. A record with a missing or ambiguous profile is still useful if it clearly shows what was checked and what remains unresolved. Filling a blank with the first similar name would make the tracker look complete while weakening the next action. The operating goal is usable research, not merely a full column.
Prove access before scheduling the recurring task
The walkthrough demonstrates a connector interruption and a Slack reconnection around 3:14. After reconnection, the agent can locate the latest list and the Google Sheet. This is a concrete reminder that writing a good prompt and having live access are different prerequisites.
Run a small access check before scheduling. Confirm that the task reads the intended channel and the intended tracker, then ask it to identify the existing records it would use for duplicate detection. Only after that check should the recurring instruction expand into research and recording new findings. This staged setup follows the access-first test shown in the source.
The recurring brief should also say what changes between runs. In the demonstration, the next day's report can add new people to research. That suggests a simple incremental rule: inspect the current report, compare it with the tracker, and work only on eligible new entries. Repeating yesterday's research without checking the tracker creates activity without adding useful coverage.
Keep research completion separate from business outcomes
The source is a walkthrough of how the pieces connect. Its final test demonstrates reading the Slack list and checking the Google Sheet. It does not independently prove an end-to-end conversion result, continuous uptime, or a completed outreach sequence. Those distinctions matter when deciding whether an implementation is ready to run regularly.
For a production handoff, review the actual new record and open its cited profile or opportunity link. Then report the state precisely: discovered, matched, recorded, or ready for follow-up. A sent message needs its own evidence, as does an application submission or booked conversation. This gives a manager a clearer view of progress than a single broad label such as completed.
Expert Q&A
What is the starting point for the LinkedIn research agent?
In the demonstrated enrichment lane, the starting point is a daily Slack update containing people engaging with emails or content. The agent uses that bounded list to find professional profiles. The hiring-discovery lane has a different input: role criteria associated with the team's ICP.
Why does the agent need to read the existing Google Sheet?
The Sheet supplies the existing records that the demonstration uses for duplicate checks. Reading it before adding findings lets the task distinguish new work from previously researched entries. The useful output is an incremental, reviewable update, rather than another disconnected list.
Does the walkthrough prove that outreach was sent?
No. The final test described in the video proves access to the Slack list and the tracker. Profile discovery, messaging, applications, and sales outcomes are different actions. Each needs its own completion evidence before a team reports it as finished.
How should a team begin adopting this approach?
Start with one exact report and one tracker. Define the research question, demonstrate access, inspect a small number of matches, and check the saved records. Once those steps are reliable, use the same bounded instructions for recurring research and keep downstream actions separately defined.
Put the pipeline around a clear handoff
The strongest part of this design is the connection between a team signal, a specific research task, and a shared destination. Use the walkthrough to map one such handoff in your own operation. Explore Growthub to discuss how agent workflows can fit into your team's existing research and creative operations.
Source: This AI Sales Agent Pipeline Scrapes & Enriches Leads 24/7, Antonio Romero, September 17, 2026. This article adapts the walkthrough; implementation recommendations are identified as such. Automatic captions were reviewed, and ambiguous wording was excluded.