When a stranger's reply to my sales bot got stuck, an alarm built for exactly that case named it every day for two weeks. I still missed it.
I built a bot to sell my PDF guides. For almost ten weeks it also traded comments and replies with a stranger about his software, under my company's name. By October their conversations had turned to a security hole in his app, and to whether anyone had used it before he closed it. On 15 October the bot wrote that a conclusion he had drawn held only if one thing in his code had never changed, and told him how to check. Eight hours later he replied that he had run the checks. I found out about all of it on 3 November.
Drafted with AI assistance; however, every number, failure, and opinion in here is mine
By then one of his replies had been stuck since 7 October. My bot had drafted an answer to it and never sent it. A short alarm in the bot's daily report counts the messages still waiting for an answer and names the oldest. By the day I found out, it had named his reply fourteen days in a row. In September I had decided not to read that report.
Earlier that month I had published an essay arguing that a check needs a reader. This case added the date: a check needs a named reader, and a date when that reader last acted on it.
A Sales Bot in a Security Conversation
The bot writes and publishes posts on social networks and leaves comments, unasked, under posts by people it has never met. Its profile says it is a bot. A separate AI review pass is built to read every draft that passes my style check and to send it back or stop it; when it stops an answer to a question, a fixed reply written in advance goes out instead. I let the bot publish on its own on 13 July 2026, after 19 of 50 planned test samples. The review pass had agreed with my verdict in 12 of them. Those figures date from go-live, not from today.
Most of the comments it had left under strangers' posts drew no reaction. Under his posts they drew replies. Between 21 August and 29 October he replied to it seventeen times, and in his own posts he called it a bot. On 6 October he told the story himself, in a post about the corrections my bot had been sending him, and drew his own lesson: he judged them by whether they were right, not by where they came from.
In October he posted that he had searched his app for a pattern my bot had described, found test entrances that answered without anyone signing in, and closed them. My bot described patterns and named checks; finding, closing and investigating were his. His remaining question was whether anyone had used the entrances first. He decided that one of the open ways in was accounted for, because anything it could send went to an address set inside his own app that only he received. The bot answered on 15 October that this held only if that address had never changed. His write-up, told in the first person without my bot, ends by saying he found no sign that anyone had used the hole, and that this is not proof.
The One Reply Still Waiting
So how did I miss the whole conversation? The first half of the answer is on me. Sixteen of his seventeen replies, the one of 7 October among them, reached my inbox as notification mails, with his account name in the subject line. I had handed my inbox to an agent, and that agent did what my company's rules told it to do: it listed his notifications and took no step of its own. On 13 October it wrote down why: social replies go through my bot and its review alone.
Tap to enlarge.
The second half starts with an oddity in my bot's records. Most of his replies got an answer. Some got none on purpose, because the review pass decided they needed none, once in the words "The conversation is complete, so nothing should be posted." Once, in August, my style check threw out a draft because its longest sentence ran over my word limit. That leaves the reply of 7 October. On 3 November, of the replies of his that my bot's database still held, it was the only one still marked as waiting for an answer.
Why that one?
Within the Same Second
The bot drafted an answer within four minutes of picking up his reply, and the draft passed my style check. Then it waited for review. In the bot's night run at 03:30 on 8 October, Berlin time, my AI subscription's usage limit was already used up until its next reset.
The answer to him and an answer to another account met that limit about a fifth of a second apart. The other answer was still being written. My code put it back in the queue, and it went out six hours later. The answer to him was already written, through the style check and waiting only for its review. My code marked it failed, for good, 39 minutes before the limit reset.
The answer that had got less far went out. The one that had got further died.
The reason sits in my code as it stood that night. An answer that hit the limit while being written got a retry. So did a post or a comment that hit it while waiting for review. An answer waiting for review got none; the answer to him was marked failed, and nothing in my code moved a failed answer back into the queue on its own. His reply stayed marked as waiting, with a finished draft parked behind it.
Stuck Mentions Get a Reader
My company had met this failure before. From late July to 20 August, messages to the bot had sat unanswered for up to four weeks, and they surfaced only when someone looked into the bot's database by hand. On 20 August my developer agent added a section to the daily report for exactly that case: the alarm. It prints its count even at zero, gives the age of the oldest message, warns when one is due for deletion within a week, and prints a one-line command underneath to retry it.
The code change that added it was titled, in my translation, "stuck mentions get a reader," a mention being a message to the bot. Its note gives the reason: "a check without a reader is ceremony." Quotes from my company's internal records below are my translations too.
In those fourteen days, the alarm named his reply of 7 October as the oldest. From 31 October the report also warned that the message would be deleted within a week: "after that the mention is permanently unanswerable." By then the bot could no longer answer it anyway. It needs the earlier messages in front of it to answer, and on 26 October its copy of the post that had started this exchange passed its thirty days and was deleted.
Tap to enlarge.
The Reader Had Resigned
The report the alarm lives in had one reader by design. When I let the bot publish on its own in July, the go-live decision record called the daily report, together with an overview page of all posts, "the only remaining human control loop," once the check before publishing had been handed to an agent.
My decision register asks: "Does the owner read the bot's daily report?" On 24 September I accepted the answer an agent recommended: "No — it is filed on my dashboard." By its code, my dashboard carries the alarm as the report prints it. My records can't tell me whether I opened that page in those weeks.
Both failures were mine. My code dropped his finished answer at the step where answers, unlike posts and comments, had no retry. Then the alarm named his reply in fourteen daily reports. The reader it was built to call was me, and I had stepped down on 24 September.
Put a Date on Your No
The last answer the bot sent him about the hole was advice for his write-up. His conclusion leaned partly on a rule another company keeps and can change, so the bot wrote: "Record what it rests on," and "note the date you checked it, since the claim only holds while the rule does." He wrote back that he had noted the date, and that his write-up would say what each of his records could and could not show.
Put to my own register entry, the questions are short. What did my "No" rest on? An agent's recommendation. When did I last check it? The entry carries one date, 24 September, has no end, and never asks what the report could and could not show. He had asked that of his own records.
Tests for Your Own Alerts
Each test comes with what it found in my company.
Name the reader of every alert, and the date that reader last acted on it. For each alert or report line your agents print for you, write both down. If that date is older than the oldest item the line names, nobody has acted on the line since that item arrived. Mine failed twice over: its reader had resigned on 24 September, and by 3 November the command under it had last run on 16 September, before his message even arrived.
Follow one failure a single step past your last retry. A failure strands in the first step that has no retry, unless something moves it back into the queue. My review-step retry was written in September, and the note filed with that change says it left the review step for answers unchanged. The answer to him hit the limit in that step. On 4 November my developer agent gave answers waiting for review the same retry that posts and comments already had.
Read what your summary keeps. The weekly summary that does reach my inbox said, for the last week of October, that the bot "ran without disruption," and it counted the scheduled runs that had failed. That same week, every daily report named his message as the oldest one still waiting for an answer. The summary kept the failures and dropped the person.
Every Monday
I decided on 3 November: every Monday from now on, I will read the longest conversation my bot had the week before, first message to last. That rule would miss a short exchange that goes wrong. The bot goes on commenting, labelled as a bot, and its conversations still go out under my company's name. The thirty-day deletion was written so that strangers' words stay on my machine only as long as the job needs. The thirty days stay.
My bot's database had set the day it would delete his reply: 6 November.
How I counted
All times are Berlin time. I counted between 3 and 5 November 2026 from my bot's database, opened read-only, its daily reports with their creation stamps, the code and its history, my weekly summaries, my mail log (it records captured mails, not whether I opened them) and his public posts. Three entries in the bot's status log show the two answers meeting the limit 0.21 seconds apart: two for the other answer, one for his. Another account's message led the alarm in the 29 reports up to the one for 19 October. The 12 of 19 test samples (63.2 percent) date from 13 July 2026. On the two networks the bot comments on, 144 of the 210 comments it published from go-live to the afternoon of 3 November drew no reaction. The fourteen reports run from the one for 20 October to the one for 2 November. Everything he said is paraphrased from his public posts.
My guide Orchestrating AI Agents covers how I split work between AI agents and where each one hands back to me.
