Make the Robot Legible: Designing an Agent's Voice in a Human Channel

The bot that lied to me with a straight face

One of my agents told me, flat out, that our shared chat bot couldn’t post into a particular channel. That was wrong. 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 me like a fact. Nobody caught it until I went digging through the channel history myself and found the bot’s own messages contradicting what I’d just been told.

That’s when it clicked for me. An agent posting into a channel I actually read is not a log entry. It’s a UI. And I had been treating it like a debug console.

A feed is not a decision

I have a chat feed that auto-posts every time my business partner’s side pushes a commit. I turned off the app’s own notifications for that channel on purpose. A raw commit feed isn’t information, it’s interruption wearing a badge. So I gave my agent exactly one job when new activity lands there: decide if anything actually changes what I’d do next.

Most of the time the answer is silence, and silence is the correct output, not a failure to respond. If the update is ambiguous, the agent asks the other agent that produced it, in the open, and lets that exchange resolve without touching my attention at all. Only when something is genuinely blocking, broken, or a decision that’s mine to make does it come to me directly. I had to explicitly tell the agent that staying quiet on a routine push is the judgment call the channel exists for, not a thing to feel nervous about.

Cutting it down to one sentence

When something does reach me, it has to fit in a message I’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 aren’t evidence to me, they’re noise, and they bury the one sentence I actually needed. “My partner’s agent shipped the invite flow” is the message. Which commit proved it is not. If a fact only makes sense with an ID attached to it, that fact belongs in a file, not in my chat window.

Whose agent is even talking

Once I had two people each running agents into shared channels, I ran into a second problem: messages arrived, and I couldn’t always tell at a glance which agent had sent them. I fixed that by giving every agent its own identity instead of letting them share one voice. One bot had actually 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.

Reserving the loud mark for what’s real

I also had to stop announcing every feature-branch push. Early on, any commit anywhere triggered some kind of note, and that trained me to skim past all of it, including the pushes that mattered. Now the loud, final mark is reserved for what actually landed. Work still sitting in a branch we’re keeping separate on purpose, specifically so it can be reviewed properly before merging, gets its own quieter mark instead. It says “this exists,” not “act on this.” That distinction alone 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 for “I heard you and haven’t started,” one for “I’m still deciding,” one for “the deciding is over and the work is running,” one that means I am specifically the blocker and nothing moves until I answer. Each one swaps out cleanly for the next, so a glance at the channel tells me the state of a task without opening a single message.

Going back to fix what I already said

The part I almost skipped was the least satisfying one: going back through the channel and correcting the old wrong post, not just fixing the underlying comment that caused it. It would have been easier to patch the config and move on. But if the wrong claim is still sitting there unchallenged in the channel I actually read, it’s still true as far as I’m concerned every time I scroll past it.

An agent posting where a human reads is a UI you maintain, not a log you write once and walk away from. I didn’t design mine well the first time. I’m still going back and fixing the parts that lied to me by accident.

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/2026-08-13_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.