Your Agent Asks. SDR Pilot Decides What Goes Out.

Because the interesting half of outbound is the thinking, and that is where your agent already lives. You have a research step in Claude Code, a scoring prompt you keep tuning, a list in Clay, a workflow in n8n. What you do not have is a safe pair of hands on LinkedIn to act on the result, and building one is a months-long project that ends with somebody's account restricted.

SDR Pilot is the pair of hands. Your agent decides who and why. SDR Pilot decides whether, when and how fast, using the same session, the same dedicated residential IP and the same caps it uses when nobody is driving.

The surface mirrors what the app already does, because an agent should not be able to ask for anything a person cannot do in the product.

• Search for people on your ICP, the same people search the app runs, inside the same monthly search budget.
• Add leads and have them researched: the profile is opened, read and scored against your ICP before anything else happens.
• Send a connection request to the ones that pass, into the day's queue rather than straight out the door.
• Read the inbox: conversations, who replied, what was said, what the agent said back.
• Reply in a thread, or hand a thread back to the human, or stand down on it.
• Post to your feed, and pull the people who engaged with a post in as leads.

That is the intended surface at the point this page was written. It is not a shipped tool list and it is not a contract; treat it as what we are building toward and ask in the DM what is live when you read this.

This is the part that matters, and it is the reason to drive an SDR rather than a raw LinkedIn API. An external agent proposes. SDR Pilot's pacer disposes. None of the following is exposed as something an agent can raise, and none of it changes because a request arrived from a machine instead of a person.

• The daily caps: 20 connection requests a day per sender with a ceiling of 25, 100 messages with a ceiling of 250, 250 profile reads, 30 searches.
• The warm-up: a new sender starts at 5 requests a day and reaches 20 on day 16, whatever anything asks for on day two.
• One LinkedIn action at a time per sender, queued and paced, never a burst.
• One browser identity per sender, captured from the real login, on one dedicated residential IP in the account's own country.
• Your active hours, on your own calendar day. Ask at three in the morning and it goes out when your window opens.
• The ICP score. A request to connect with somebody who fails your own bar is refused, not sent.

An agent that asks for two hundred connection requests gets twenty today, twenty tomorrow, and an honest answer about the rest. That is not a limitation of the integration, it is the integration's entire point.

• Claude Code, for people who already run their GTM work from a terminal.
• Claude Desktop, for the same work without one.
• Cursor, for teams whose agent context lives next to their code.
• n8n, for workflows that already move data between a CRM, an enrichment step and a spreadsheet.

Anything else that speaks MCP should work, and the API is there for whatever does not. Both are in early access.

In early access. The app is allow-listed, there is no checkout, and the MCP server and API keys go out to accounts on the list as they are ready. Nothing on this page is available to install right now. If that is what you need this week, say so in the DM and we will tell you honestly whether to wait.

Because a raw LinkedIn API hands your agent the account and the risk at the same time. Tools call what they are told to call, as fast as they are told, and the judgement about what is safe ends up inside a prompt that nobody tuned for it. Every restriction story in this category starts there.

SDR Pilot is the opposite trade. You give up the ability to fire two hundred requests in an afternoon, which you should not want, and you get an executor whose defaults were set by watching one real account for months. The caps hold whoever is driving.