Personalisation and scale, in tension

Not everything in a message needs to be unique. The structure, the framing, the ask — these can be consistent without anyone objecting. What must be genuinely specific is the connection: why this person, why this role, why now.

Systems that try to make everything unique produce laboured text that reads oddly. Systems that make nothing unique produce templates. The working design makes one or two things genuinely specific and lets the rest be ordinary.

One accurate specific sentence is enough. A message that is otherwise plainly structured but contains something that could only have been written about this recipient reads as a real person being efficient, which is exactly the impression you want.

• Scales fine — structure, tone, the closing ask
• Must be specific — the reason for contacting this person
• Must be true — every claim about the sender
• Should be omitted — generic praise and company facts

People who receive many messages recognise the patterns: an opening compliment, a paragraph of generically relevant experience, a closing ask for fifteen minutes. The tells are structural more than lexical, which is why rewording does not help.

And once detected, the message is not merely ignored — it is evidence that the sender did nothing, which is a worse outcome than not sending. The presence of a personalised-sounding message that is obviously not personalised is a negative signal.

The specific tell most people name first is a compliment with no content behind it. Admiring someone’s "impressive work in the space" demonstrates that the sender did not look at the work, and it is more damaging than an opening that simply states the reason for writing.

Genuine specificity requires genuine input, and there is only so much a candidate can truthfully say they care about. Beyond a modest number of contacts a week, the system is manufacturing interest that does not exist.

So capping volume is not a limitation on the product — it is the thing that keeps the output honest. The cap should be low enough that every message can survive the test of being read aloud to the recipient.

Reply rate per message is also the wrong thing to optimise if it is measured in isolation. The number that matters is conversations started per week, and a system sending five good messages that produce two conversations is beating one sending two hundred that produce one.

Cold outreach works to the extent that recipients still read cold messages. Every low-quality automated message reduces that slightly, for everyone, including the person who sent it next time.

A platform that enables high-volume outreach is spending a resource its users share. Designing for restraint is self-interested rather than altruistic: the channel’s effectiveness is the product.

The depletion is already visible. Response rates to cold professional messages have fallen steadily as automated sending became easy, and every participant who scaled up contributed to the decline that now makes their own messages less effective.

The specificity has to come from somewhere checkable. A pipeline that gathers something concrete about the recipient first — a public piece of work, a talk, a repository, a role change, a post they wrote — and passes only that to generation is doing the thing properly.

Everything about the sender must trace to their profile. A message claiming experience the candidate does not have is worse in outreach than in an application, because it is the opening line of a relationship rather than one document among hundreds.

And there must be a suppression list. People who asked not to be contacted, anyone already in a live process, anyone contacted in the last quarter, and any employer the candidate excluded all belong in a check that runs before generation rather than after.

• One verifiable, concrete fact about the recipient
• Every sender claim traceable to the structured profile
• A suppression list checked before generating, not after
• A hard weekly cap, enforced in code
• A record of what was sent to whom and when

The important capability is refusal. When there is nothing specific to say, the honest output is no message, and a generative system will never reach that conclusion on its own — it always produces something.

Build the check explicitly: if the generated message contains no concrete, verifiable connection to this recipient, it does not send. That single rule does more for reply rates than any amount of prompt tuning.

Implement it outside the model, as a function over the gathered facts rather than as an instruction. A model asked to judge whether its own output is specific enough will say yes, which is the same reason every other guardrail belongs in code.