A helpful AI assistant knows when not to answer

On November 1, 2026, LobeHub released version 2.3.0. Its headline change is proactive bot participation. The feature had been previewed in version 2.2.21; version 2.3.0 turns it on by default. In the channels a bot watches, it judges each message and decides whether to speak up, stay quiet or wait. The owner can switch it off in the channel’s wake policy settings, after which only watch keywords wake the bot. LobeHub v2.3.0 release notes (opens in a new tab)

The release also adds a Wake records tab. It lists each message the bot judged, with the outcome, a model score and a short reason, and lets the owner mark each decision right or wrong. LobeHub v2.3.0 release notes (opens in a new tab)

Two cautions. The release notes do not establish a native Slack integration or what any hosted plan includes. Check whether your own channel platform and account support the feature before planning a pilot. And everything above is how the project describes the feature; we have not tried it.

Two different questions

Most assistant evaluations ask one question: was the answer right? An assistant that decides when to join a conversation raises a second question that matters just as much: should it have said anything at all? A correct reply dropped into a member’s personal story, or into a thread a teammate was already handling, is still the wrong call.

So score the two separately. For every message in a test, record whether the assistant spoke and whether its answer was correct. Then sort each decision into one of four buckets:

• Useful intervention: it spoke, the message was within its duties, and the answer helped.
• Unnecessary interruption: it spoke when a person was already handling the thread, the message was addressed to someone else, or nobody needed help.
• Missed relevant request: an in-scope question went unanswered when the assistant could have helped.
• Appropriate silence: it stayed quiet when the message was outside its duties or a person was already handling it.

A log of each decision and its reason makes this review much faster. The labels, though, have to come from people who know your audience.

Where this matters

Some scenarios worth evaluating. These are proposals, not client results:

• Community leaders: a member channel where the assistant could answer recurring event or access questions, but should stay out of introductions, debates and anything personal.
• Marketing teams: an internal campaign channel where it could point people to the current brief or asset folder, but should not weigh in on creative feedback between colleagues.
• Support teams: an internal triage channel where it could suggest a help article for a common question, but should hand billing, account and complaint issues to a person.

Run a small pilot before any public channel

1. Start offline or in a private test channel with limited access and no live members.
2. Prepare sample conversations and label every message in advance: should speak, should stay quiet, or should hand to a person.
3. Write the assistant’s duties narrowly, including topics it must never answer.
4. Agree thresholds before you look at results, such as how many unnecessary interruptions per hundred messages you would accept. There is no universal number; it is a judgment about your audience.
5. Define escalation: which topics always go to a named person, and how the assistant says so.
6. Run the same set more than once, compare the assistant’s decisions with your labels, and review the misses as carefully as the interruptions.

If the results hold up, widen access gradually. If they do not, keeping the assistant mention-only is a perfectly good outcome. Whatever you decide, keep a person responsible for the channel.

Where to go from here

A good assistant is judged as much by the moments it stays quiet as by the answers it gives. If you would like help scoping a careful pilot for your team or community, take a look at Build With AI.Explore Build With AI