LinkedIn Agent

Purpose

The LinkedIn Agent handles semi-automated outreach on LinkedIn: sending personalized connection requests, follow-up message sequences, and content engagement. It operates through the LinkedIn API where available and browser automation where necessary, with human oversight for compliance with LinkedIn’s terms of service.

Profile Optimization (Manual, One-Time Setup)

Before the agent begins outreach, manually optimize the LinkedIn profiles of the 3 BDRs and any company executives who will be sending connections:

  • Headline: Speak to the seller. Example: "Helping Amazon & Walmart Sellers Get Paid Daily | Eliminate the 2-Week Payment Wait"

  • Banner image: Reinforce the value prop with branded imagery.

  • About section: Lead with the seller’s problem. Include social proof (100+ sellers, total payouts processed). Clear CTA and booking link.

  • Featured section: Best case study, cash flow calculator link, booking link.

Outreach Sequences

The LinkedIn Agent manages multi-step outreach sequences for each contact:

Sequence Flow

  1. Connection request (Day 0): Short, personalized note under 300 characters. No pitch. Reference their store, category, or a shared group.

  2. Thank you + value (Day 1–2 after acceptance): Thank for connecting. Share a useful resource (blog post, data point about seller cash flow). No pitch.

  3. Soft introduction (Day 4–5): Introduce what you do in context of a problem they likely face. Ask a question: "Have you ever calculated how much cash you have locked up in Amazon at any given time?"

  4. Case study + ask (Day 10–12): Share a specific case study. Ask if they’d be open to a quick call.

  5. Breakup (Day 20): Final message. Share a resource regardless. "If cash flow timing ever becomes a bottleneck, here’s how to reach us."

Message Generation

Each message is generated by Claude API with seller context from HubSpot:

System: You are writing LinkedIn messages for outreach to Amazon/Walmart sellers.
The goal is to build a genuine connection and introduce a daily payout service.

Rules:
- Connection notes: under 300 characters, no pitch, reference something specific
- Follow-up messages: under 100 words each
- Never open with your product — lead with the seller or shared context
- Use question-based approach, not statement-based
- No jargon: "daily payouts" not "factoring" or "receivables financing"
- One link max per message
- Tone: genuine, curious, peer-to-peer

Seller context:
- Name: {name}
- Business: {business_name}
- Category: {category}
- Marketplace: {marketplace}
- LinkedIn activity: {recent_posts_or_activity}
- Sequence step: {step_number}

Implementation

Why Nova Act is the right choice for LinkedIn automation

The traditional approach — Playwright with session cookie rotation and residential proxies — works, but carries meaningful operational risk that is easy to underestimate. The infrastructure cost looks manageable, but the maintenance cost is where you bleed. Every time LinkedIn tweaks their UI, selectors break and require manual intervention. Session cookies expire unpredictably, proxy services add latency and cost, and cookie rotation logic adds complexity that compounds over time.

Nova Act was designed precisely for this class of problem. It brings three specific advantages here: human-in-the-loop approval patterns and real-time UI takeover for handling CAPTCHA and LinkedIn’s occasional security challenges; session isolation and session replay for auditability and account safety monitoring; and a dramatically faster path from prototype to production — one CLI command handles Docker packaging, ECR push, IAM setup, and AgentCore Runtime deployment, which matters when a single developer is maintaining multiple agents.

The terms-of-service risk profile does not change meaningfully — you are automating LinkedIn regardless of the tooling. What changes is that maintenance burden drops significantly and reliability improves. Selector maintenance disappears as a recurring cost. Budget and plan around Nova Act as the primary executor for all LinkedIn actions.

Runtime: AgentCore Runtime (marketplace-linkedin-agent)

The LinkedIn Agent runs as an AgentCore Runtime deployment. All browser actions (Nova Act and Playwright) execute against AgentCore Browser — no self-managed Chrome, no ECS Fargate. Lambda is used only as a thin EventBridge dispatcher.

AgentCore services used by this agent: * AgentCore Runtime — hosts the agent; each scheduled run is an isolated session * AgentCore Memory (linkedin-sequences store) — per-contact sequence step, per-profile daily action counts, acceptance tracking; replaces DynamoDB action counters * AgentCore Memory (cross-agent-leads shared store) — reads prior email/voice outcomes; writes LinkedIn engagement signals back for cross-agent awareness * AgentCore Browser — managed cloud browser; both Nova Act (primary) and Playwright (fallback) connect to it via WebSocket/CDP. Persistent browser profiles per BDR account managed by AgentCore Identity — no manual session cookie loading * AgentCore Identity — manages LinkedIn browser profiles (persistent session cookies per BDR account), Claude API key, HubSpot token * AgentCore Gateway — exposes hubspot_get_contact, hubspot_update_stage, hubspot_create_task as MCP tools * AgentCore Policy — enforces daily per-profile action caps as guardrails; agent cannot exceed limits regardless of reasoning loop

Trigger: EventBridge every 2 hours → dispatch-linkedin Lambda → InvokeAgentRuntime

AgentCore Runtime: linkedin-outreach-session

Trigger: EventBridge every 2 hours, 7am–9pm ET Mon–Fri

Steps:
1. Read from AgentCore Memory (linkedin-sequences + cross-agent-leads):
   - Contacts needing next sequence action based on timing
   - Skip contacts already responded to email/voice (from cross-agent-leads)
   - Skip contacts in bdr_handoff or disqualified stage
2. For each contact:
   a. Read per-profile action counts from AgentCore Memory — AgentCore Policy
      guardrail will block the tool call if daily limit is reached
   b. Generate personalized message via Claude API (AgentCore Identity credential)
   c. Execute via AgentCore Browser (Nova Act → Playwright fallback):
      → Open AgentCore Browser session using persistent LinkedIn profile
        (AgentCore Identity manages session cookies — no manual loading)
      → Try Nova Act: connect to AgentCore Browser via CDP, execute task
      → If Nova Act escalates/errors: Playwright connects to AgentCore Browser
        via CDP, executes same task using CSS selectors
      → If both fail: log to dead-letter list in AgentCore Memory, skip contact today
   d. Write result to AgentCore Memory: advance sequence step, log executor used
   e. Call `hubspot_update_stage` tool to log activity

3. Inbox reply sweep (runs as part of same session):
   a. Open AgentCore Browser, run Nova Act inbox check → Playwright fallback
   b. For each new reply: classify intent via Claude API
   c. "interested": call `hubspot_create_task` tool (BDR alert),
      write to cross-agent-leads memory, update lifecycle → engaged
   d. "question": generate response via Claude + send via AgentCore Browser task

Browser Execution Strategy

All LinkedIn browser actions follow a Nova Act → Playwright fallback pattern. Both executors connect to an AgentCore Browser session — the browser runs in AWS-managed cloud infrastructure. There is no ECS Fargate browser farm, no Lambda Chromium layer, and no external proxy service for either execution path.

  1. Nova Act (primary): Connects to AgentCore Browser via WebSocket/CDP. Uses natural language task instructions. Adapts to LinkedIn UI changes without brittle selectors. Escalates explicitly on unexpected states.

  2. Playwright (fallback): Also connects to AgentCore Browser via CDP (not a local browser). Uses CSS/XPath selectors. Invoked only when Nova Act escalates or errors.

The agent logs action_executor: nova_act | playwright to AgentCore Memory per action. Monitor the ratio via AgentCore Observability — rising Playwright usage signals a LinkedIn UI change that needs a selector update.


LinkedIn API vs Nova Act (Browser Automation)

  • LinkedIn API (preferred): Use for content posting (company page), basic profile lookups, and any officially supported actions. Requires LinkedIn developer app with appropriate permissions.

  • Browser automation (Nova Act → Playwright fallback): LinkedIn’s API does not support sending connection requests or messages at scale. Nova Act is the primary executor — its computer-use model handles dynamic UI naturally and escalates on friction instead of silently failing. Playwright is the fallback for when Nova Act cannot complete the action.

Nova Act Agent: linkedin-action-executor (Primary)

Deployment: Amazon Bedrock AgentCore
Trigger: Invoked by linkedin-outreach Lambda per queued action
Model: Nova 2 Lite (low-latency computer-use model)
Monitoring: CloudWatch — action success rate, escalation events, daily limit approach

Supported task types (passed as natural language instructions):

  Connection request:
    "Log into LinkedIn as {profile}. Navigate to this profile: {linkedin_url}.
     Send a connection request with the following note (under 300 characters): {note}.
     Confirm the request was sent successfully."

  Message to connection:
    "Log into LinkedIn as {profile}. Open the message thread with {contact_name}.
     Send the following message: {message_text}. Confirm delivery."

  Inbox check (reply sweep):
    "Log into LinkedIn as {profile}. Open the messaging inbox. Return a list of
     all conversations with new replies in the last 4 hours. For each, return:
     sender name, sender profile URL, and message text."

  Engagement (like/comment):
    "Log into LinkedIn as {profile}. Navigate to this post: {post_url}. Like it.
     Then leave this comment: {comment_text}."

Session management: Loads LinkedIn session cookie from Secrets Manager per profile.
Nova Act's step-by-step execution produces human-like timing — no explicit delays needed.

Triggers fallback when:
- Identity verification or security challenge screen appears
- "Connect" button not found on profile page (UI layout change)
- Message thread cannot be located
- Task exceeds 60 seconds
- Nova Act returns an escalation event for any reason

Playwright: linkedin-action-playwright (Fallback — via AgentCore Browser)

Execution: Playwright connects to AgentCore Browser via CDP (not a local Chrome instance)
Trigger: Invoked by the LinkedIn Agent's reasoning loop when Nova Act escalates or errors
Runtime: Python 3.12 + playwright (no headless Chromium layer needed — browser runs in AgentCore)
Proxy: Configured via AgentCore Browser proxy settings if needed (no external proxy service)

Session management: Load LinkedIn session cookie from Secrets Manager.
Add random delays between actions: 30–90 seconds (uniform distribution).
Randomize viewport (1200–1440px wide, 700–900px tall). Set realistic user-agent.

Connection request:
1. Navigate to {linkedin_url} via proxy
2. Wait for profile page to load, locate "Connect" button
   (selector: button[aria-label*="Connect"] — update if LinkedIn changes)
3. If "Add a note" option appears: click it, type {note}, click "Send"
4. Confirm via success toast or button state change
5. Return {success: true, executor: "playwright"}

Message to connection:
1. Navigate to linkedin.com/messaging/
2. Search for {contact_name} in conversation search
3. Click conversation, type {message_text} into compose box, send
4. Return {success: true, executor: "playwright"}

Inbox check (reply sweep):
1. Navigate to linkedin.com/messaging/?filter=unread
2. Scrape all visible conversation previews updated in last 4 hours
3. For each: extract sender name, profile URL (from href), message preview text
4. Return list of {sender_name, linkedin_url, message_text}

Engagement (like/comment):
1. Navigate to {post_url}
2. Click Like button (selector: button[aria-label="Like"])
3. Click comment box, type {comment_text}, submit
4. Return {success: true, executor: "playwright"}

On any Playwright failure: return {success: false, error: "<reason>", executor: "playwright"}
and push action back to dead-letter SQS for manual review.

Daily Limits (Per LinkedIn Profile)

  • Connection requests: 20–30/day (conservative to avoid restrictions)

  • Messages to connections: 50/day

  • Profile views: 100/day

  • Content engagement (likes/comments): 30/day

With 3 BDR profiles + 1 executive profile = 80–120 connection requests/day total.

Content Posting

The LinkedIn Agent posts content to company and personal profiles:

Posting Schedule

  • Company page: 3–5 posts/week (content generated by Content Agent)

  • BDR profiles: 1–2 posts/week each (rotate content, personalized intro)

Content Types

  • Educational posts about cash flow, payment timing, working capital

  • Customer success stories (anonymized or with permission)

  • Industry commentary on Amazon/Walmart policy changes

  • Engagement polls: "How long does it take you to get paid after a sale?"

  • Repurposed snippets from blog posts

Engagement Automation

The agent also engages with seller content to build visibility: * Like and comment on posts from target sellers (genuine, relevant comments generated by Claude) * Engage with posts in Amazon seller LinkedIn groups * This builds profile visibility so that when the connection request arrives, the seller has already seen your name

Integration with Other Agents

Cross-Channel Sequencing

LinkedIn is typically the third channel in the escalation sequence: . Email Agent sends 4-email sequence → no reply . Voice Agent attempts 3 calls → no connect . LinkedIn Agent sends connection request → starts LinkedIn sequence

The LinkedIn Agent checks HubSpot for prior activity before starting: * If the seller has already responded to email or voice: skip LinkedIn outreach * If the seller is in BDR queue: skip LinkedIn outreach * If the seller has been disqualified: skip

Warm Lead Signal

When a seller accepts a LinkedIn connection AND replies positively to a message: * Update HubSpot lifecycle stage to engaged * Create BDR task: "LinkedIn warm lead — seller replied positively" * BDR follows up via LinkedIn message or phone call

Tools & Infrastructure

  • LinkedIn Sales Navigator: $80–$100/month per seat. Used for advanced search, lead lists, and InMail credits. Agent uses Sales Navigator’s search API (where available) for prospect identification.

  • Browser automation (primary): Amazon Nova Act via Bedrock AgentCore. No headless Chrome Lambda layer, no ECS maintenance, no selector upkeep for the happy path.

  • Browser automation (fallback): Playwright connecting to AgentCore Browser via CDP. Invoked only when Nova Act escalates or errors. No ECS Fargate, no Lambda Chromium layer — the browser infrastructure is AgentCore Browser in both cases.

  • Proxy: Required only for Playwright fallback paths — rotating residential proxies ($100–$200/month). Nova Act does not require proxies; its sessions run on AWS-managed infrastructure. Budget proxies as a contingency line, not a fixed cost.

  • Session management: LinkedIn session cookies stored in AWS Secrets Manager per profile. Both Nova Act and Playwright fallback load cookies from the same Secrets Manager path. Rotate across 4 profiles (3 BDRs + 1 executive).

  • Monitoring: Native CloudWatch integration via Bedrock AgentCore. Set alarms on: Nova Act escalation rate per profile (>2/day = friction signal), action success rate (<95% = investigate), daily limit approach (>80% of cap = slow down).

Risk Management

LinkedIn automation carries account restriction risk. Mitigate: * Stay well within daily limits (see above) — enforce in DynamoDB before invoking Nova Act, not after * No manual delay injection needed. Nova Act’s step-by-step computer-use model already produces human-like timing between actions. Do not add sleep() calls — they add latency without benefit. * Don’t automate on weekends or outside normal business hours (enforce via EventBridge schedule) * If a Nova Act task escalates due to a LinkedIn identity verification or warning screen: pause that profile’s automation for 7 days, then resume at 50% volume. Nova Act’s escalation signal (rather than a silent failure) is the early-warning mechanism. * Always have the BDR’s real activity mixed with automation (they should manually engage too) * Keep connection request acceptance rate above 20% — if it drops below, improve targeting or personalization. Monitor via DynamoDB acceptance tracking, not inside Nova Act.

Expected Metrics

Metric Target

Connection requests/week (total, all profiles)

400–600

Acceptance rate

25–40%

Response rate (after acceptance)

15–25%

Positive response rate

5–10%

Demos booked from LinkedIn/month

15–30