How to quieten Pip in Slack

When an AI agent works in Slack, the answer is only half the experience. The other half is the thread it leaves behind.

If every tool call, status update and half-written assistant message lands in the channel, Slack starts to feel like a terminal with emoji reactions. That can be useful while you are debugging. It is rarely the right default for a team trying to get work done.

Hermes lets you tune that experience. You can keep Slack quiet, show progress when it matters, stream the final answer, or expose the raw tool progress when you need to inspect what Pip is doing.

Slack thread preview

What the same Pip task can look like in Slack

Use the buttons to compare the trade-off. More progress messages can help when you are debugging, but they can also turn one useful answer into a noisy thread.

#ops

tool_progress: all or verbose

Lots of useful detail, lots of pings

Best for debugging. Tiring for day-to-day Slack work.

Pip I will check the repo, run the build, and report back.

tool terminal: git status, npm run check

tool browser: opening local preview

tool terminal: npm run build completed

Pip Done. I found one layout issue, fixed it, and the build passes.

The clean default

For most teams, the best Slack setup is quiet by default with long-running task updates left on.

That means:

no raw tool progress in the thread
no interim assistant messages while Pip is still thinking
a short acknowledgement that Pip is working
a heartbeat for genuinely long jobs
the final answer delivered cleanly when the work is done

Copy this into your Hermes config under the Slack platform display settings:

display:
  platforms:
    slack:
      tool_progress: off
      tool_progress_grouping: accumulate
      interim_assistant_messages: false
      long_running_notifications: true
      busy_ack_detail: false
      streaming: true

This is the setup I would start with for a shared team channel. You still know Pip has picked up the task, but the channel does not get filled with internal process.

What each setting changes

`tool_progress`

This controls how much of Pip’s tool use appears in Slack.

off: hide tool progress. This is the cleanest everyday mode.
new: show new tool activity only when it is useful to tell the user something has started.
all: show the tool progress in more detail.
verbose: show the most detail. Best kept for debugging.

If your team is complaining that Pip is noisy, start here. Set tool_progress to off and only turn it back up when you are diagnosing a problem.

`tool_progress_grouping`

This controls how tool progress is grouped when it is shown.

accumulate: keep progress together so the thread has fewer separate messages.
separate: send progress as separate Slack updates.

If you do show tool progress, accumulate is usually easier to read. separate can make sense when you want each step to be independently visible, but it creates more notification noise.

`interim_assistant_messages`

This controls whether Slack gets partial assistant messages before the final answer is ready.

false: only show the final answer.
true: show interim assistant messages as Pip works.

For normal channels, false is calmer. Interim messages can look like answers even when Pip has not finished checking the facts.

`long_running_notifications`

This controls whether Pip sends a heartbeat during long tasks.

true: send occasional updates for long-running work.
false: stay quiet until the final answer.

I would leave this on. A heartbeat is not the same as raw tool spam. It is a simple reassurance that the job is still alive, which matters for crawls, imports, deploy checks, big builds and research runs.

`busy_ack_detail`

This controls how much detail appears in the quick “I’m working on it” acknowledgement.

false: keep the acknowledgement brief.
true: include more detail about what Pip is doing.

For a clean Slack thread, use false. The final answer can carry the useful detail.

`streaming`

This controls whether the final assistant answer appears as it is being written.

true: Slack can show the final answer building progressively.
false: Slack waits, then posts the completed final answer.

Streaming feels more responsive, especially for longer summaries. The trade-off is that people may read before the answer has finished. If your team wants the cleanest record, turn it off. If they want to see progress without tool noise, leave it on.

If you want a streaming experiment

This is a good middle ground when you want Slack to feel alive, without showing every internal tool step.

display:
  platforms:
    slack:
      tool_progress: off
      tool_progress_grouping: accumulate
      interim_assistant_messages: false
      long_running_notifications: true
      busy_ack_detail: false
      streaming: true

Run it for a week in one channel. If people like seeing the answer appear gradually, keep it. If people quote half-finished replies or find it distracting, switch streaming to false.

If you are debugging Pip itself

Turn the lights back on temporarily:

display:
  platforms:
    slack:
      tool_progress: verbose
      tool_progress_grouping: accumulate
      interim_assistant_messages: true
      long_running_notifications: true
      busy_ack_detail: true
      streaming: true

Use this in a private test channel, not in the team’s main operating channel. It gives you more visibility, but it also creates more Slack surface area for people to misunderstand.

The trade-off to choose deliberately

There is no perfect Slack mode. There is only the mode that fits the job.

If the channel is for operators who need the outcome, keep it quiet. If the channel is for developers debugging the agent, show more progress. If the job may take ten minutes, keep heartbeats on. If the answer is long and people are waiting, streaming can help.

My default is simple: final answer first, heartbeat for long work, raw progress only when we are actively debugging.