Bot noise: why the Slack bots are hard to follow

Smith, Trinity and Clara's alert posts: why they write too much, answer too often and cry wolf, and the two changes that fix most of it.

2026-10-12 · 31 days of Slack, 2026-09-12 to 2026-10-12, six channels · Proposed — pending Fede's review

New page rather than a section of the September alert-noise page: that page uses the retired chapter format and is marked done; this is the October follow-up.

TL;DRNumbersExamplePatternsCausesOptionsStatusAppendix

TL;DR

Two moves fix most of it. 1. One bot per thread, and a bot wakes only when named. 2. Check the record before anyone is paged.

Every wake re-reads the whole thread, so two bots answering each other cost tokens twice over and grow every thread. One owner per thread cuts both.

The numbers

Measure (31 days)SmithTrinityGoal
Posts a day296131a third
Words per post, typical / long71 / 314103 / 27580 max
Replies aimed at the other bot17%40%only when named
Alerts it judged noise41%45%checked first
Took back its own claim131119rare
More numbers: alerts, red main, people asking for a summary
Alerts posted1,98257% got no reply at all
Alerts with a verdict that were noise41%of 533 with a verdict
Human questions answered by both bots28%of 469
Answered twice by the same bot34%
"Main is red" announcements a day~68one event, three channels
Bridge handoffs nobody answered906 of 965automated ones
CI-capacity "down / back up" pairs144zero replies
Threads a human replied to5% / 14% / 2.6%Smith / Trinity / Clara alerts
Clara alert length112 / 194 words65% carry a table
People asking "what is this?"21"Is it an issue or not? tldr?"

Posts a day include machine status lines (101 of SmithSmith and Trinity rows count posts the bots wrote; machine status lines (another 101 a day from Smith, 14 from Trinity) are counted separately.rsquo;s, 14 of TrinitySmith and Trinity rows count posts the bots wrote; machine status lines (another 101 a day from Smith, 14 from Trinity) are counted separately.rsquo;s). Word counts use bot-written posts only.

The wake loop: one post wakes both bots, each answer wakes the other A post landshuman or bot Smith wakesre-reads whole thread Trinity wakesre-reads whole thread Both answer~100–300 words each Hop cap hit"summarize" = 1 more each answer is a new post: it wakes the other bot
Figure 1. The wake loop. It stops only at the hop cap (3 hops, 5 per thread an hour), and the cap's last step asks for one more long summary.

Worked example: 15 posts for a 45-word answer

On 2026-10-12 a quality check flagged Clara for inventing open units at Camellia. The bridge thread ran 15 posts in 10.8 minutes: 2,646 bot words against 14 from Fede.

The fifteen-post thread, one bar per postMIN · WHOWORDS (BAR) · WHAT IT SAID+0.0 Smith227 · “Clara invented the units” — cc Fede, Trinity ✗ wrong+2.0 Trinity256 · “Worse: all three units are wrong” ✗ wrong+3.4 Smith199 · Not in her knowledge base either+6.7 Trinity392 · “I checked the wrong building” ↺ takes it back+7.8 Smith251 · False alarm: the units are real ✓ first right answer+8.6 Trinity156 · Agreed+9.2 Fede12 · “No fixes before I understand”+9.2 Trinity2 · “Hatching…”+9.6 Smith91 · Sends the fix session new orders+9.9 Fede2 · “false alarm?”+9.9 Trinity363 · Holding; here is the short version+10.0 Trinity231 · Yes, false alarm+10.2 Smith227 · Holding; here is what happened+10.7 Smith137 · Mostly a false alarm+10.8 Trinity116 · Correction to the order of events ↺ takes it back
Figure 2. One bar per post, length = words. Purple = Smith, amber = Trinity, green = Fede. The right answer arrives at minute 7.8; after Fede asks "false alarm?" five more replies (about 1,070 words) repeat it.

What was posted

15 posts, two wrong claims, two take-backs, both bots answering the same two-word question.

What a human needed (45 words)

Clara told a Camellia prospect three units were open. Our checker said she made it up. She didn't; the units are real. Nothing to fix in Clara. The checker needs the same unit list she has. Fede decides whether that fix goes ahead.

Token cost, by simple arithmetic on the thread text alone: the bots re-read about 17,500 words of thread to write about 2,400 words of replies. The 45-word version needs one read.

Five noise patterns

PatternExample
Both bots answer one ask. 28% of human questions got two answers."the truth in 3 sentences" → 50 replies
Bots talk to each other. Threads grow with no human in them.go-live plan → 334 replies, 189 bot-to-bot
One red main, many posts. About 68 a day across three channels."also red" folded into one alert
Machine lines bury the thread. Status lines nobody reads.one alert → 372 lines over 6 days
Checks fire on correct answers. A red that a record lookup would clear.conversation red, judged noise

Root causes, in three pictures

1. Who answers: everyone, every time

EventSmith wakes?Trinity wakes?Proposed
Question in a shared channel, not addressedyesyesthread owner only
Human reply in a thread both posted inyesyesthread owner only
The other bot posts on the bridgeyesyesonly if named
Two quick messages from one persontwicetwiceonce
Figure 3. Trinity is told to answer any question it can, named or not. Both bots listen on the same three channels and follow every thread they posted in.

2. Why posts are long: nothing says short

Instructions ask for tables, bullets, headers and mentions; nothing caps length Instructions ask fortables, bullets, headers,mention the teammate Alert reply formatverdict + evidence + link≈300 words, every alert Sent as writtenno word cap in codeverdict often comes last
Figure 4. Clara's alerts add a seven-row table to every red. Nothing on the bridge stops a bot from tagging Fede or Gera.

3. Why checks fire on correct answers: the proof is thrown away

Clara answers from a unit list the checker never sees Clara gets theopen-units list Answers correctly"three units open" List not savedchecker sees no proof "Made up" → redalert + email + bots No step looks the units up before the page goes out.
Figure 5. The checker only accepts a lookup it can see as proof. Clara's unit list arrives pre-loaded, so it is never on the record.

Options

What changesEffect
AThe two moves only: one bot per thread, woken by name; record check before paging.Ends double answers and most false pages. Posts stay long.
B recommendedA, plus: verdict line first; an 80-word cap the code enforces (overflow goes in an attached file); no human mentions on the bridge; quick messages from one person merged into one answer.Every post readable in ten seconds. Fewer wakes, fewer tokens.
CB, plus: machine status lines move to their own channel; one red-main post per event.Quietest. More channels to watch.

Recommend B. C's channel split can follow once B shows what is left.

Fede's call: who can wake which bot (thread ownership), wake-on-name on the bridge, the thread budget (5 to 2 an hour, nothing posted at the cap), and the channel split. Gera's call: Smith's seat setting that decides which channels it answers in. Everything else is a fix and ships with no switch.

Status

Appendix

The 15 candidate changes, with where they live
#ChangeWhere (file:line)Decides
1Save the pre-loaded units list on the traceconversation-manager.ts ~8868fix
2Judge counts that list as proof (v6, recalibrate)conversation-judge.ts 202/216/850-858fix
3Available units in made-up-claims grounding factspolicy-gate-types.ts:117, trajectory-judge.ts:201fix
4Record check before pagingconversation-grade.ts:881fix
5Two-line alert, no table; reds email or wake Smith only if they survive the checkconversation-grade.ts 910-929, bake-alert.ts 648/963/1057fix
6One alert per stuck leadlead-outbox-watchdog.ts 174-184fix
7Verdict first, ~80 words, tables/headers only when askedprompts.py 310-330/393-418, prompts_clara.py 186-198, alert_remediation_prompt.py 414-419fix
8Enforce the cap in code, overflow as a fileactivities/slack_send.pyfix
9One bot owns a thread; the other silent unless namedslack_socket.py 2795-2915Fede
10Split channel ownership; Smith seat gate to enforceboth seat plistsFede + Gera
11Merge rapid messages from one persondispatcher.py 328-360fix
12Bridge posts wake the other bot only on mentionslack_socket.py 1702-1711Fede
13No human mentions in bot replies and session postsslack_send.py, bridge-post.shfix
14Thread budget 5 → 2 an hour; post nothing at the capconfig.py:749, prompts.py 1583-1588Fede
15Stop test-company held renewals posting to #alertsheld-review notice pathfix

Other code facts: Trinity's "answer it whether or not it was addressed" rule is in prompts_clara.py 98-101; hop cap and thread budget in config.py:746/749/777; the hop-cap summary instruction in prompts.py 1572-1588; bridge-post.sh:26 hard-codes hop 1 so session posts never advance the count. Bot files are in the agent-smith repo; judge and alert files in the app repo.

How this was measured, and the caveats
  • Every message from 2026-09-12 to 2026-10-12 (UTC, 31 days) in #engineering-bridge, #alerts, #agent-trinity, #updates-fede, #agent-smith, #updates-gera, pulled with Fede's read token.
  • Bot posts split into agent-written text and machine status lines (fold lines, deploy ticks). Word counts use agent-written posts.
  • Noise share comes from explicit "Verdict:" labels where present (533 of 860 replied alerts); the keyword fallback is rough.
  • Take-backs found by pattern; a random sample of 20 showed about 18 true self-corrections.
  • "Human" excludes 59 long posts made by sessions under Fede's or Gera's own login. Clara has no Slack identity of her own; her alerts post as Smith.
  • Goals in the numbers table are targets, not measurements.
PropFlow Docs