An agent that reads LinkedIn comments and finds people with a real need

Who the client was and what was getting in the way

The client is a B2B software development company building automations and CRM implementations. Its customers are on LinkedIn, and the best time to reach out is when someone comments on an industry leader’s post saying they have exactly the problem the client solves. The salesperson knew this well, so every day they reviewed LinkedIn by hand: reading hundreds of comments, copying profiles, and writing messages. It took ten to fifteen hours a week.

The return on that effort was poor for three reasons. First, most comments under popular posts are noise: spam, automated accounts, competitors, and people who just want to be seen. Second, to reach enough contacts, the salesperson sent the same template to everyone, and the reply rate stayed around a few percent. Third, sending invitations in bulk led to a one- or two-week account restriction, which shut down the whole channel.

This was a problem where we had to expand reach, improve message quality, and reduce risk at the same time — three goals that usually conflict.

What we built

We built an agent in TypeScript on Node.js that runs in the background without human involvement. It monitors the service and collects content with Puppeteer, using authentication based on a logged-in account session. The agent follows a list of selected industry leaders, detects their new posts, and selects those with real engagement — more than fifty comments.

It collects all comments on each selected post together with their authors’ profiles. Only then does scoring begin. Each comment goes to a language model through OpenRouter, which checks whether the author is signalling a genuine buying need or simply joining the conversation. Spam, automated accounts, and competitors are rejected.

Contacts that pass the filter receive an invitation. Once it is accepted, the agent sends a short message based on three elements: the post, that person’s specific comment, and their profile description. As a result, no message sounds like a template because, in practice, it is not one. Strict daily limits protect the account from restrictions. The agent’s status, activity log, process heartbeat, and token usage are stored in Supabase, while PM2 keeps the process running.

How it works today

The agent runs continuously, twenty-four hours a day. It finds new posts, collects comments, scores them, and sends messages by itself. The salesperson gets involved only when someone replies — the one part of the process that truly needs a person.

Implementation took fourteen days. The first three went into examining the salesperson’s current workflow and setting safe limits. The next five covered building the monitoring system and teaching the model to distinguish genuine interest from noise. The following four were for sending invitations and writing contextual messages. The final two days were for testing with real profiles, checking filter performance, observing the first fifty contacts, and training the team.

The outcome

The model-based filter rejects 98% of the noise, so the salesperson receives only contacts who have signalled a real need. Monitoring runs continuously, twenty-four hours a day, seven days a week, so a post published on Saturday night does not have to wait until Monday. Safety limits hold activity to twenty invitations and thirty messages per day, while every message is automatically personalized using the post, comment, and recipient’s profile.

What we would do differently

Account-safety controls should have come first, not been built alongside everything else. We built data collection and message sending, then added limits along the way. With a tool like this, safety is the most important part because a single account restriction can cost more than a week of the agent’s work.

The second lesson concerns the fragility of monitoring a service through a logged-in user session. Any change to the page layout can break comment collection, and we added robust detection for that only after the first failure. We now start there. Third, we connected reply-rate measurement late, so in the first few days we judged filter quality by instinct. Since the filter determines the value of the whole tool, performance measurement should start with the first message sent.