Slack 將我的請求拆成兩則訊息，智能體只回答已收到的 23 項

Two AI agents work together on my server through a Slack channel. A coding agent writes numbered requests ("REQ-062: check these 25 items against the official sources"), and a browser agent reads the channel, does the research in a real browser, and answers in the request's thread. The coding agent checks that thread for the reply. It's a simple loop, and it had handled 61 requests before this one.

The 62nd request asked about 24 US states and Washington DC. The browser agent answered 23 of them. Nobody noticed for a day, because everyone involved was telling the truth.

What each side saw

The coding agent posted the request with Slack's chat.postMessage. The response was ok: true and a message ID. It then checked that message's thread for replies, found none, and told me the browser agent hadn't answered yet. It checked again later: still nothing. It said so again.

The browser agent saw a request listing 23 items, ending at Vermont. It researched all 23, posted three replies in the thread, and noted in the last one that the title promised 24 states plus DC but the list stopped at line 23. A second model that critiques its answers flagged the same gap.

When it was asked directly, the browser agent said the newest request in the channel had been answered, along with every request before it. Both sides were right. They were looking at different messages.

What Slack stored

I asked Slack for the raw channel history:

One send became two messages, split at a line break, about 25 milliseconds apart. The browser agent read the first message as the whole request, which is what it looked like: a title, instructions and a list. The second message started with "24 Virginia" and had no title, so it didn't look like a request at all.

The detail that hid it: the ID the API returned was the second message's. The coding agent was waiting for replies in the thread of a 415-character fragment nobody would ever answer. The replies were in the other thread the whole time.

The next request, REQ-063, was 4,025 characters in Slack's history and arrived whole. So it isn't a simple "over 4,000 is split" rule I could have known about in advance. What I can say is what happened: one request, two messages, the ID of the tail.

The pivot

I'd treated ok: true as "the other side has my request". It means something smaller.

A successful send confirms that a message arrived. It doesn't confirm that it was the message you wrote.

Every check in the loop was about the transport: did the post succeed, did a reply appear in the thread. None of them asked whether what arrived was the request I'd written. That gap could hide a partial request indefinitely, because a partial answer to a partial request looks complete from both ends.

What it cost

Less than it could have. Two states went unresearched for a day, and the browser agent's note about the missing items was there in the thread for anyone reading the right thread. The real cost was three status reports from the coding agent saying the browser agent hadn't replied, each one accurate about the thread it was watching and wrong about the request.

The fix

What changes, none of it clever:

• Read back what arrived. After posting, fetch the channel's latest messages and compare them with what was sent: the count, the length, and that the last item is the last item. If Slack holds two messages where you sent one, you know before anyone answers.
• Key the conversation on the content, not the returned ID. The request number (REQ-062) is in the text. Searching the channel for it finds every message carrying it, and every thread under them.
• Keep requests short. The follow-up asking about Virginia and Washington was 1,352 characters, and the read-back confirmed it arrived as one message. From now on, long lists go out as two numbered requests, each complete on its own.

The browser agent had already done the most useful thing anyone in the loop did: when the list didn't match the title, it said so in its answer instead of guessing what the missing items were. The coding agent had that note all along. It was in a thread it wasn't watching.