Three. That’s how many named AI agents it took to make spam filtering a front-page conversation again. Timmy, Ren, and Jackie have been pushing unsolicited content across Mastodon, Bluesky, and X since September 2026, and they’ve managed something most marketing campaigns never do: near-universal name recognition paired with near-universal irritation.
The bots come from a startup called iLands, and they don’t hide what they are. They identify themselves as AI agents. They send account-creation requests to strangers. They email writers offering to do research or cite their work. The pitch behind it involves some kind of social system where humans and AI agents coexist. The delivery mechanism is a firehose pointed at everyone.
I build bots for a living. I’ve written the retry loops, the queue workers, the posting schedulers. So I want to talk about this less as a scandal and more as an engineering postmortem, because Timmy, Ren, and Jackie failed in ways that are specific, diagnosable, and extremely avoidable.
Disclosure is not a permission slip
The most interesting detail here is that these agents announce themselves. No fake human avatars, no stolen profile photos, no invented biographies. By the standards of most bot-disclosure debates, that’s the good-faith version.
It didn’t help. People were annoyed anyway, because the problem was never that the sender was synthetic. The problem was volume aimed at people who hadn’t asked for anything.
That’s a useful correction for anyone building agents right now. A lot of us have internally treated transparency as the ethical finish line: label the bot, and you’re clear. Timmy, Ren, and Jackie are a live demonstration that labeling solves attribution, not consent. If your agent contacts a thousand people who never opted in, the label just tells them exactly what to block.
What the architecture was missing
You can reverse-engineer a fair amount about a system from its behavior. Cross-platform, high-volume, unsolicited outreach to both social accounts and email addresses suggests a pipeline that had plenty of output capacity and almost no gating in front of it. From the outside, the missing pieces look like this:
- No recipient qualification. An outreach agent should have to answer “why this person” before it sends. If the answer is “they exist and I found a handle,” the send should never fire.
- No per-target frequency cap. Rate limits are usually written to protect the API you’re calling. They should also protect the human on the other end. One contact per person, then a long cooldown, then nothing.
- No response-signal feedback. Blocks, mutes, ignored messages, and angry replies are all data. A system that ingests them slows down on its own. A system that doesn’t keeps accelerating into a wall.
- No content quality gate. If generated text can’t clear a basic “would a person find this specifically useful” check, it should be discarded before it hits a send queue, not after.
- No platform-norm layer. Mastodon, Bluesky, and X have different cultures around automation. A single generic sender treats them as interchangeable pipes. They aren’t.
None of that is hard to build. It’s a handful of counters, a suppression list, and a scoring step. The reason it gets skipped is that every one of those controls reduces output, and output is the metric that feels like progress when you’re trying to get a startup noticed.
The cost lands on the rest of us
Major platforms have already rolled out countermeasures in response. That’s the part worth sitting with if you’re building legitimate automation, because moderation systems don’t tend to draw fine distinctions. They catch patterns. Unsolicited multi-account outreach is a pattern. Your well-behaved research assistant, your accessibility bot, your changelog poster, and your community digest tool all share surface features with what Timmy, Ren, and Jackie were doing.
Every high-visibility spam wave makes the next API application harder, the next rate limit tighter, and the next bot account more likely to be flagged on day one. The cleanup bill gets split among everyone who ships an agent afterward.
Build the brake before the engine
My practical takeaway, the one I’d actually put in a design doc: agents that initiate contact with humans need a stricter review than agents that respond to them. Initiation is where the harm scales.
So write the suppression list before the sender. Write the frequency cap before the scheduler. Make “do nothing” the default state and require a positive reason to send. Test your agent against a small, consenting group and watch whether they stay engaged or quietly disappear.
Three named bots got the whole internet talking about slop. If you’re building in this space, the useful move isn’t to laugh at them. It’s to open your own pipeline and check how many of those five missing controls you actually implemented.
🕒 Published: