Queue LinkedIn outreach
queue_linkedin_outreachA campaign already sending without a flow keeps calling this tool without
node_id, as do a one-off send outside a campaign and a resolve look-up.
Every other campaign sends through its flow, even a single message or
connection requests with nothing after: create it with define_sequence
and add the prospects with track_prospects, and the flow's steps call this
tool with their node_id. A call without node_id on an agent that has no
flow and hasn't sent any outreach yet is refused.
Only call this AFTER the user has explicitly confirmed the outreach.
BATCH: pass ALL recipients in a single call. The tool is designed to
batch — provider_id recipients queue directly (resolving before send
unless already verified) and URL/slug recipients route through the
background resolving queue with rate-limited, business-hours pacing.
Calling once per recipient multiplies prompt overhead by ~N and produces
no observable benefit. If you have 27 prospects to queue, that's ONE call
with recipients of length 27, not 27 calls of length 1.
Dict with known_queued (provider_id recipients queued directly),
deferred_count (URL/slug recipients queued for background resolution),
awaiting_approval (how many of those the user's approval settings hold
until the user approves them in Sliq — tell the user these wait on their
approval; only the rest are on their way. A row whose profile is still
being looked up counts by those settings and reaches the approval queue
once its lookup finishes; the lookup can also hold a row the count left
out, when it shows the user already talks with that person on LinkedIn),
tracking_skipped (recipients already tracked in another campaign, so
nothing queued for them — each entry names existing_agent_title /
existing_agent_id; surface these and let the user place them), skipped
(recipients the queue helper refused — each entry has target_name,
provider_id, reason, error, plus existing_agent_id /
existing_agent_title when a row on another campaign is what
blocked the send; name that campaign to the user rather than calling it
a duplicate on this one), accept_followup (present only when connection
requests queued to this agent but no sequence node or accept trigger
will fire a message on acceptance — names how to wire one), and
rate_limit_estimate — an ETA for the batch covering expected profile
resolution and sending days given the user's current rate-limit budget.
Its summary names the rows awaiting approval and gives the ETA for the
rest only.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"recipients": "<recipients>",
"action_type": "<action_type>"
},
"name": "queue_linkedin_outreach"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| enrich | No | When True, look up each prospect's verified work email via Apollo and stamp it on the tracking row. Requires each recipient to have `target_name` plus a `linkedin_slug` (a profile slug or URL). Costs 1 Sliq credit per verified hit (a zero Sliq balance skips the whole lookup); free with BYO Apollo. Recipients missing inputs are silently skipped. | |
| notify | No | Only for action_type='resolve'. False (default) = a silent data lookup the person is NOT notified of. True = a visible "View Profile" visit that DOES notify them ("X viewed your profile") — a no-message warm-up touch, typically placed later in a sequence, not a data read. Same paced lookup and daily cap either way. Rejected on non-resolve actions. On a sequenced call the resolve node's own `notify` field is authoritative and is OR'd in, so a "View Profile" node always visits. | |
| node_id | No | Optional. The id of the sequence-DAG node this batch enacts (a node in the agent's `sequence`, authored via `define_sequence`). Stamped on every queued row so the Campaign Flow view can place each prospect and count per node. Pass it whenever the agent has a sequence. Rejected with ModelRetry if it isn't a node in the agent's sequence. | |
| agent_id | No | Optional. Pass for campaigns or when inside an existing agent. Omit for ad hoc sends — the tool auto-uses the "LinkedIn Quick Actions" default agent. Every send lands in the agent you name; recipients already tracked in a different one are reported in `tracking_skipped` rather than queued (see Returns). | |
| recipients | Yes | List of recipient dicts. Each dict must carry one of `linkedin_slug` (a profile slug or URL), `provider_id`, or `chat_id`, copied verbatim from the tool result that surfaced the person — never a slug rebuilt from a display name, which enrolls the wrong person. Other attributes go under `data`; unknown top-level keys are rejected. If you have no identifier for someone, omit them rather than guess. When a recipient's `target_name` shares no tokens with any LinkedIn name already held for that `provider_id` (a verified prospect or a post engager), the whole batch is rejected with ModelRetry before anything queues — fix the pairing and re-send (use the person's LinkedIn URL/identifier if the pid is wrong; use one consistent name if it's the same person). A pid with no held name isn't gated here — it resolves before send and the resolver adjudicates the name then. | |
| action_type | Yes | 'resolve', 'connection_request', 'message', 'inmail', or 'follow'. For 'resolve' and 'follow', the `message` field is unused and rejected with ModelRetry. Follow auto-sends by default (its own `linkedin_follow` approval subtype); gate it via outbound-approval settings. 'resolve' commits NO outreach — it queues a paced profile lookup that fires a `resolved_profile` trigger event per person; use it when the per-person action depends on looked-up data (see the trigger-code skill for the branching example). Pair with `notify=True` for a visible "View Profile" visit (see `notify`). The event carries the looked-up profile — `already_connected`, `network_distance`, `connections_count`, `follower_count`, `headline`, `title`, `company` — and the same fields land on the prospect's row under `data`, so a later turn reads them with `query_prospects` instead of resolving again. A connection-count rule can read `connections_count` from here; when the rule turns on the count alone, `enrich_linkedin_profiles` returns it for the whole list in one call without spending account budget, so filter there first and queue only the recipients that pass. | |
| linkedin_api | No | For inmail only. Leave unset — the tool bills the InMail against the pool for the LinkedIn plan Sliq recorded when LinkedIn was connected. Only pass an explicit 'classic', 'sales_navigator', or 'recruiter' to force a pool. | |
| on_behalf_of | No | A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account. |