Quieting #agent-smith — the plan

What stays in the channel, what moves to #alerts or Gera's DM, how we stop it refilling, and how Smith's own replies stay short.

2026-10-15 · written by Agent Smith · status: Gera decided 2026-10-15 — in motion

Where we are

Yesterday's cleanup moved alerts one family at a time. Nothing stops a new one. Today a brand-new GitHub job dumped a 40,000-character error into the channel as 10 posts, hours after the cleanup finished. The channel had 54 top-level posts in the last 48 hours; 5 were from people.

What is fixed and what is not

The rule we're enforcing (Gera, 2026-10-15)

#agent-smith carries two things: the morning and nightly queue roll-ups, and big updates about Smith's own work. Smith is an agent for the Mac mini, like Trinity — not an in-between for alerts. Anything broken (red main, something down) is a company issue and goes to #alerts. Everything else automated goes to Gera's DM. Everything else already in the channel gets deleted, replied-to posts included.

The plan — 5 parts, each its own PR, in this order

The five parts, in order

Part 1 — One door, with a bouncer the real fix

Every Smith post already flows through one Python function (slack.py). Put the rule there: a top-level post addressed to #agent-smith is allowed only if its source is on the keep-list (the roll-ups, big Smith updates, human-addressed replies). Anything else is sent to the DM instead, with one log line saying so. Then any new job, lane, or script that targets the channel gets rerouted automatically — nobody has to find and move it later. Test: a fake "new alert" posted at the channel lands in the DM.

Part 2 — The GitHub side goes through the same door

The 4 GitHub workflows post with a raw curl and skip Smith's code entirely. Change them to use the shared channel registry key (gera-dm), cap any error text at ~600 characters with a link to the run for the rest, and add a CI check that fails any workflow file containing the channel id literally. Starts with the census job that flooded today (next run is 00:23Z, still aimed at the channel).

Part 3 — A fence on the hardcoded ids

Ratchet the 10 + 7 + fleet-script hardcodes down to zero: each must name a registry key, and a test fails the build on any new literal id. Same shape as the fence that already keeps customer names out of code.

Part 4 — Sweep the backlog and keep it swept

One-time: delete every remaining channel post not on the keep-list (I keep the ones a person replied to unless told otherwise). Ongoing: a nightly pass deletes any off-list post that slipped in and reports the count in the morning roll-up — so a leak shows up as a number, not a wall.

Part 5 — Smith's replies stay short and plain

Decided

What done looks like

The four checks

Order matters: Part 1 first, because it makes Parts 2–4 safe to do slowly. Parts 1–3 are a day of work in three PRs; Part 5 is a second day.

PropFlow Docs