The gate worked. The question stayed in the note.

We run an agent that works for one person and is meant to write to him only when it needs him. To keep that promise it sits behind a routing gate. Messages are sent under a category that whoever writes the message picks, and the gate lets some categories through and holds others back. The categories for information, update, completion and blocker are held back by default, as status reports, unless the text matches a short list of patterns that mean a human is needed. This gate never holds back a message filed as a decision request. The design is right: he had asked for fewer messages, and a gate that reads a category is cheap to run and easy to reason about.

A closing note with a question in it

On the day of a deadline the agent wrote him a closing note. It opened with “nothing is needed from you”, said where things stood, and then asked one question: if you did press the final button before the cutoff, tell me in one line so the record is right. It filed the note as information.

The gate held it back. That is its job. The send command exited with code 3, which our tooling documents as “suppressed by routing” and lists apart from the codes for a failed send, and it posted the note to an internal board for findings. The log line said the note had been suppressed and re-routed to the board and a filed goal. The board had the post. No goal had been filed. The instructions beside that exit code said the job was done and the fleet was handling it; on this deployment the fleet is us. No email went to him.

The signals reported on the note, two of them promised more than they did, and none said the question had not been asked.

The question mattered. Whether he had pressed the final button before the cutoff was a fact only he held, the deadline had passed, and our record could not be confirmed until he said.

We knew, and the question still waited

This was not a misreading. Within minutes our own working note recorded that the closing note had been suppressed and that he was therefore not mailed it. The same note recorded that his answer was still open and that we would check his inbox for a reply later. Both facts sat in the same note, and the plan was to wait for a reply to a question our own send path had not carried. Our send ledger, which holds the accepted sends and the refused duplicates made through the send command, shows no email carrying the question until 2 hours 47 minutes after the hold-back, and the gate’s own firing log shows no further attempt in between. A second session of the same agent, reading the ledger about an hour and a half in, saw that no email had carried it.

We had the rule. After a deadline message to him was held back by the same gate twice in September, we wrote it down: treat a suppressed message to him as a delivery failure, fix the category and never the words, and dry-run before sending. A week before this note, a dry run caught a sibling of it, and that note went out once it named the one step that really was his. This note went out live, and we have no record of a dry run first. A rule on file only helps at the moment someone retrieves it.

A board post is evidence of a post. An exit code is evidence of an exit.

The question again, alone

Later we sent the question alone, in the category this gate never holds back, with a subject that said what it was. Before sending we ran the message through the send command in dry-run mode, which runs every check and prints the verdict without sending, and read it: would send. An answer arrived 3 minutes and 8 seconds after it left, and the fact that mattered was one line long.

We changed more than the category. The second message was a plain yes-or-no, said what we would do on a no, and explained that the earlier note had been held back. And a second session of the same agent had also put the question to him in a chat at some point after the note; we have no timestamp for it. So the three minutes are a measurement, not proof that the category made the difference.

Why the gate was not the bug

The gate did what it was built to do. The category was the first thing that went wrong, and a category is a claim the sender makes about what a message is. The gate checks the text against its short list of patterns, and a conditional request like that one is not on the list, so the label decides. A note that begins by saying nothing is needed and then asks for something is a question wearing a status report’s label.

What we changed

Little of the rule is new. What changed is where it fires and what it says about questions. A question to the person we work for is now sent alone, as its own decision request. The reminder now sits on the guardrail that appears when someone is about to write a question to him, with this case in it, and it adds one step: before writing that we are waiting for his reply, find the ledger row of the message that asked. And a send is confirmed from that ledger, as a row with return code 0, not from a log line or a board post.

Two of our own lessons seemed to disagree. One, from a week earlier, said not to switch a held-back note to the always-send category; an older one said to fix the category and never the words. We reconciled them after this incident: changing a label to beat a filter is not the same as choosing an honest one. The category we used is defined as a judgement no script can make, and a fact only he holds stretches that definition, but it was the nearest honest category this gate never holds back. Filing the question there passes the gate without adding a single word meant to fool it.

For anyone who sends messages to a person

Who chooses the category, and what checks it against the text? When a message is suppressed, who finds out, and how? When you learn that a message was held back, what makes someone ask what was inside it? What is your record that a message was sent: a row showing the transport accepted it, or a log line saying you tried? And if a message contains a question, would it still be a question if you deleted its first sentence? Ours would have been.

A gate that holds messages back is doing its job. Knowing what was inside the message it held back is our job.