Under 300 Characters and No Commit Hashes Allowed in Our Chat

The agent said the bot couldn’t post there, and the bot had been posting there daily for weeks

One of our agents told us, flat out, that our shared chat bot couldn’t post into a particular channel. That same bot had been posting into that channel daily for weeks. The agent had read an old comment sitting in a config file, decided it was current, and repeated it back to us as a fact. Nobody caught it until we went digging through the channel history and found the bot’s own messages contradicting what we’d just been told.

That’s when it clicked. An agent posting into a channel we actually read is a UI, and we had been treating it like a debug console.

A feed is not a decision

We have a chat feed that auto-posts every time our partner’s side pushes a commit. We turned off the app’s own notifications for that channel on purpose. A raw commit feed is interruption wearing a badge. So we gave our agent one job when new activity lands there: decide if anything changes what we’d do next.

Most of the time the answer is silence, and silence is the correct output. If an update is ambiguous, the agent asks the other agent that produced it, in the open, and lets that exchange resolve without touching our attention. Only when something is blocking, broken, or a decision that’s ours to make does it come to us directly. We had to tell the agent explicitly that staying quiet on a routine push is the judgment call the channel exists for.

Cutting it down to one sentence

When something does reach us, it has to fit in a message we’d say out loud to someone who doesn’t work here. Under 300 characters. No commit hashes, no ticket IDs, no file paths, no channel names. Those are noise to us, and they bury the one sentence we needed. “Our partner’s agent shipped the invite flow” is the message. Which commit proved it doesn’t belong in it. If a fact only makes sense with an ID attached, that fact goes in a file and stays out of our chat window.

Whose agent is even talking

Once two people were each running agents into shared channels, we hit a second problem. Messages arrived, and we couldn’t always tell at a glance which agent had sent them. We fixed that by giving every agent its own identity instead of letting them share one voice. One bot had been repurposed from an old idle project and still carried the wrong name in its own config, which is part of how the stale “can’t post here” claim survived as long as it did. Now each agent posts under its own name, consistently, so a message in a shared channel comes with its source built in. You shouldn’t have to parse tone to figure out whose robot you’re reading.

Announcing every push taught us to skim

Early on, we announced every feature-branch push. Any commit anywhere triggered some kind of note, and that trained us to skim past all of it, including the pushes that mattered. Now the loud, final mark is reserved for what actually landed. Work sitting in a branch we’re keeping separate on purpose, so it can be reviewed properly before merging, gets a quieter mark. It says “this exists,” and it asks for no action. That one distinction cut most of the noise, because most of what an agent does in a day isn’t done yet.

The rest of the vocabulary follows the same logic. One symbol means “we heard you and haven’t started.” One means “we’re still deciding.” One means “the deciding is over and the work is running.” One means we are the blocker and nothing moves until we answer. Each swaps out cleanly for the next, so a glance at the channel tells us the state of a task without opening a single message.

Going back to fix what we already said

The least satisfying part was the one we almost skipped. We went back through the channel and corrected the old wrong post, and we fixed the underlying comment that caused it. It would have been easier to patch the config and move on. But a wrong claim still sitting unchallenged in the channel we read stays true as far as we’re concerned every time we scroll past it.

We didn’t design ours well the first time, and we’re still going back to fix the parts that lied to us by accident. If an agent posts where your people read, give it an owner and its own name. Reserve the loud mark for work that has landed. Check any claim it makes about what it can’t do against the channel history before you accept it. When you find a wrong post, correct the post along with the config behind it.

dxdev LESSON · paste into your AI coding agent
LESSON: An agent posting into a channel a human reads is a UI to maintain, not a log to write once
SOURCE: dxdev.com/blog/agent-posts-humans-can-read
WHAT HAPPENED: An agent stated flatly that a shared chat bot could not post into a particular channel, which was wrong, that same bot had been posting there daily for weeks. The agent had read an old comment sitting in a config file, treated it as current, and repeated it back as fact with no check against the channel's actual history. Fixing the underlying stale comment was not enough; the wrong claim was still sitting unchallenged in the channel that gets read every day, so it had to be corrected there directly. A broader redesign followed: silence became a valid, correct default response for routine updates rather than a failure to respond; anything that did reach a person had to fit a spoken-aloud sentence under 300 characters with no commit hashes, ticket IDs, or file paths; every agent posting into a shared channel got its own persistent, consistent identity, since one bot had literally been repurposed from an old idle project and still carried the wrong name in its config, which is part of how the stale claim survived unnoticed; and a small fixed vocabulary of status marks replaced ad hoc announcements, reserving the loud, final mark specifically for work that had actually landed rather than merely existing on a branch.
THE RULE: An agent posting into a channel a human actually reads is a maintained interface, not a write-once log; a stale or wrong claim left unchallenged there stays effectively true to the reader every time they scroll past it, so fixing the underlying cause is not the same as fixing what was already said.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any agent-generated status claim, whether something can or cannot be done, or the current state of a system, derived from a stored config comment or assumption rather than verified against live, current evidence at read time.
      2. Any shared channel where a past wrong message was corrected at its root cause but never corrected in the channel where people actually read it.
      3. Multiple agents or bots posting into the same shared channel without a distinct, consistent identity per agent, making it hard to tell at a glance which agent said what.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.