What to do when your LinkedIn inbox gets away from you

Short answer: stop reading and start sorting. A backlog of hundreds of threads is not a writing problem. It is a sorting problem wearing a writing problem's clothes. Classify everything into a few buckets, split the threads you owe a reply from the threads where you are being ignored, read summaries instead of transcripts, and only then write. Most of the pile needs nothing from you.

Why the backlog got this big

A LinkedIn inbox fails differently from an email inbox. Email arrives with a subject line and a thread that stays on one topic. LinkedIn threads are one line at a time, months apart, with no subject and no structure. A recruiter's opener from March and a real question from a customer look identical in the list.

So the cost of deciding whether a thread matters is almost the same as the cost of answering it. That is the trap. Once deciding is as expensive as doing, you stop opening the inbox at all, and the pile grows at exactly the rate messages arrive.

The fix is to make deciding cheap again. Everything below is about that.

Triage before you write

Do not open the inbox and start at the top. Reading down a list is the slowest possible order, because you spend your freshest attention on whatever happened to arrive most recently.

Instead, pass over the whole backlog once and label every thread without writing anything. Four buckets are usually enough:

  • Recruiter inbound. Someone is pitching you a role. Worth a reply only if you want the role or the relationship.
  • Candidate reply. Someone answered your hiring outreach. These are time sensitive and people notice being dropped.
  • Cold outreach reply. Someone responded to a message you sent first. This is a live conversation you started, and it is embarrassing to abandon.
  • Spam. Agencies, lead lists, crypto. Archive without opening.

Your buckets may differ. An investor's four are not a job seeker's four. The rule is that the labels must be few enough to hold in your head and specific enough that the label alone tells you what to do next.

Only after the whole backlog carries a label do you write anything. Now you are working through one bucket at a time in the same voice with the same context loaded, which is several times faster than switching modes every thread.

Split what you owe from where you are ghosted

This is the single distinction that recovers the most value, and almost nobody makes it.

Look at who sent the last message in each stale thread.

If you sent it and nobody replied, you are being ghosted. That thread costs you nothing right now. It needs one short follow up or a decision to let it go. It does not need an apology or a long note.

If they sent it and you never answered, you owe a reply. That is a person who asked you something and is still waiting. These are the threads that damage you. A hiring manager who wrote in April and got nothing does not think you were busy. They think you were rude.

Sorted this way, a backlog of four hundred threads usually contains a few dozen owed replies and a long tail of ghosted ones. The few dozen are the whole job.

Summarise long threads instead of rereading them

The last unhelpful habit is reopening a nine-message thread from five months ago and reading it from the top to remember what it was about.

You do not need the transcript. You need three things:

  1. The core ask. What did this person actually want.
  2. The current state. Where did it stop, and who stopped it.
  3. The next step. What one sentence would move it forward.

Written down, that is four lines for a thread that takes three minutes to reread. Across fifty threads it is the difference between an afternoon and a week.

Write short, and write in the thread

A reply to a five-month-old message should be short. Long replies read as guilt. Two or three sentences that answer the question and propose the next step will outperform a paragraph of explanation for why you went quiet, which nobody wants.

Do not send a fresh connection request or a new message to restart a conversation that already has a thread. Reply inside the thread. The history is right there, the other person gets context for free, and you are not asking a platform for a new relationship you already have.

What Iridium does with this

Iridium is a LinkedIn MCP server. You connect your LinkedIn account once, then your agent, usually Claude, gets your inbox as a set of tools. Everything above is the method. This is the part that runs it.

It classifies the whole inbox

The classifier sorts threads into recruiter_inbound, candidate_reply, cold_outreach_reply and spam by default, with a confidence score from 0 to 100 on each. You are not stuck with those four. You can pass your own label list and get your taxonomy instead. Results are cached until a new message arrives in the thread, so asking twice is free.

It searches your messages properly

Search runs full text over your actual message bodies and takes an operator grammar, so your agent can compose a real query instead of scrolling.

QueryWhat it returns
is:unreadThreads you have not opened
from:priyaThreads with a specific person
company:stripeThreads with anyone at that company
is:unread company:anthropic newer:7dUnread messages from that company in the last week
older:30d has:draftThreads over a month old where a draft is already waiting
after:2026-06-01 before:2026-07-01Everything inside a date window

The operators combine. That is the point. "Unread, from anyone at these two companies, older than two weeks" is one call, not an afternoon.

It finds stale threads and tells you which kind they are

The stale thread scan returns each thread tagged ghosted or owed_reply, using the same rule as above. It excludes archived threads and excludes anything that already has a send pending, so you never draft a second reply on top of one waiting to go out.

Honest limit: the scan has a ceiling on how many rows it examines in one pass. A very large backlog comes back in batches. You run it more than once. It is not a single call that empties four hundred threads, and anyone telling you otherwise has not run it on a real inbox.

It summarises a thread instead of dumping it

Ask for a summary and you get the participants, the company, the core ask, the current state and a suggested next step. That is the four-line shape from earlier, generated. You read it and decide. You do not scroll.

It backfills your history once

A new account starts with only what LinkedIn hands over live. The one-time backfill paginates through your history in bulk reads rather than one call per thread, so the classifier and the search index have your real inbox to work with from the first day instead of the last week of it.

It drafts the reply

Reply drafting reads up to 30 messages of thread context before writing. Drafts are capped at 600 characters, with no emojis and no exclamation marks, which is roughly the length that gets answered. One draft per thread, so the queue cannot fill up with variations of the same message.

Nothing sends on its own. A draft is a draft until you approve it, and approving is a separate step. You can rewrite it, edit it, or skip it.

Replies do not eat your daily cap

Iridium caps new outreach at 25 a day with a rolling backstop of 90 invites per 7 days. Replies are exempt from that cap. The reason is mechanical rather than generous: replying inside an existing thread creates no new connection, so it is not the activity the cap is there to limit. Clearing a backlog of owed replies does not spend your outreach budget for the day.

Two things it does not do

Both are worth knowing before you start, because the opposite is easy to assume.

The stale scan is batched, not exhaustive. It reads a bounded number of rows per pass. On a very large backlog, plan on several passes rather than one.

You choose the send time. There is no timezone inference on any inbox path. Replies go out immediately unless you pass a timestamp when you approve. Activity-based scheduling exists in one place only, and that place is outreach connection notes, not your inbox. If you want a reply to land on Tuesday morning, say Tuesday morning.

A worked pass over a real backlog

  1. Run the backfill once so your history is present.
  2. Classify everything. Read the counts. The spam bucket usually explains a third of the pile.
  3. Scan for stale threads. Take the owed_reply set first and ignore ghosted entirely for now.
  4. Summarise each owed thread. Three lines each, no transcripts.
  5. Draft replies for the ones that deserve one. Read them. Fix the ones that are wrong. Approve.
  6. Come back to ghosted when the owed pile is empty. Most of it deserves nothing.

Steps two through five are one conversation with your agent. The reading you would have done is the part that disappears.

Questions people ask next

How many threads can it handle at once?

Classification and search run over your whole inbox. The stale thread scan is the bounded one: it examines a capped number of rows per pass and then applies your limit, so a large backlog comes back in batches across several calls. This is a deliberate ceiling, not a failure. Run it, work the batch, run it again.

Can I use my own labels instead of the default four?

Yes. The four defaults are what most people want on day one, but the classifier takes any label list you pass. A founder might use investor, customer, candidate and noise. Each thread comes back with a label and a confidence score from 0 to 100, so you can decide how much to trust the low-confidence ones.

Does the draft sound like me?

The draft is built from up to 30 messages of thread context plus your role and credentials, and it is held under 600 characters with no emojis and no exclamation marks. That produces something short and plausible in context. It is not personalised against a stored voice profile, and reply drafts are not voice matched. Read every draft before approving. Editing is the step where it becomes yours.

What stops it replying to the same person twice?

Two things. There is one draft per thread, so a second draft cannot stack on the first. And the stale thread scan excludes any thread that already has a send pending, so a thread waiting on a scheduled reply will not resurface as needing one.

Will clearing a big backlog look automated?

Volume and repetition are what get noticed. Replies inside existing threads are the least risky activity on the platform, and Iridium does not send anything you have not approved. Still, approving fifty identical drafts in one minute is a pattern. Spread them out, edit them, and let the ones that do not need an answer go unanswered. You stay responsible for using any tool inside LinkedIn's terms.

How do I see what was sent?

An activity log, append-only by design, recording what was sent and when. Ask your agent what it did yesterday and it reads the answer out of the log rather than guessing.

What it costs

Iridium is $20 a month for one LinkedIn account. There is a 7-day free trial and it does not ask for a card. If your backlog is the reason you have stopped opening LinkedIn, the trial is long enough to empty it.

Sort the pile, then answer it

7-day free trial. No credit card. Cancel anytime.

Start free → Replies that sound like you