Allow agents to observe group messages without always replying

Problem / Motivation

In group chats, there is an important distinction between:

1. receiving/observing a message,
2. deciding whether the message is relevant to the agent,
3. processing it with the main agent,
4. deciding whether a response should actually be sent.

Today, group message handling is mainly based on whether a bot should be triggered by a message at all, for example through mention-based or open group handling.

For multi-agent group chats this is limiting.

Example:

A Telegram group contains several specialized agents:

• a calendar / personal assistant
• a project management agent
• an information/archive agent

A user writes:

I will be on vacation next Thursday.

This information may be useful context for multiple agents, but only one of them may have something useful to say.

Ideally:

• the calendar agent may handle the message and respond
• the project management agent may observe it as useful context but remain silent
• the archive agent may ignore it entirely

Without such a distinction, users either have to explicitly mention every relevant bot or allow multiple bots to respond to messages where they have nothing useful to contribute.

This becomes especially noisy in groups with multiple agents.

Proposed Solution

Introduce an optional contribution policy for incoming group messages that separates message observation from response delivery.

Conceptually, an incoming message could pass through the following stages:

Incoming group message
        |
        v
Contribution decision
        |
        +--> IGNORE
        |
        +--> OBSERVE / CONTEXT_ONLY
        |
        +--> HANDLE
                 |
                 v
             Main agent
                 |
                 v
          Delivery decision
                 |
          +------+------+
          |             |
       SUPPRESS       DELIVER

The exact API/configuration is open for discussion, but an opt-in policy could conceptually look like:

{
  "channels": {
    "telegram": {
      "groupPolicy": "open",
      "contributionPolicy": "relevant"
    }
  }

The important behavior would be:

• IGNORE: do not invoke the main agent
• OBSERVE / CONTEXT_ONLY: retain the message as conversation context without generating a response
• HANDLE: invoke the normal agent
• after agent execution, optionally allow the resulting response to be suppressed instead of requiring every successful agent run to produce a user-visible message The contribution and delivery decisions could use a lightweight configurable evaluator rather than the agent's main model. Explicit mentions should probably bypass the contribution gate and continue to trigger the addressed agent directly. Existing group behavior should remain unchanged unless the new policy is explicitly enabled.

Alternatives Considered

Mention-only group handling

This avoids unwanted responses, but the bot does not get useful context from messages where it was not explicitly mentioned.

It also requires the user to know in advance which agent may need a piece of information.

Open group handling

This gives agents access to the whole conversation, but can cause every agent to react to every message.

In a multi-agent group this quickly becomes noisy and can also cause unnecessary LLM calls.

Prompt the main agent to return something like NO_REPLY

This could suppress some responses, but the expensive main agent has already been invoked.

It also makes "no user-visible response" a special text convention instead of an explicit runtime behavior.

Only add a post-run delivery evaluator

This would solve unwanted responses, but would not avoid unnecessary main-agent invocations for clearly irrelevant messages.

A pre-run contribution decision and a post-run delivery decision solve different problems and could therefore be useful independently.

Related Component

Channel (WeChat, Feishu, Telegram, etc.)

Additional Context

A similar separation already exists conceptually in the heartbeat flow:

• work is performed internally
• the resulting response is evaluated
• only relevant results are delivered to the user

The proposed group-chat behavior could reuse or generalize this idea, while additionally introducing a lightweight pre-run contribution decision to avoid unnecessary main-agent executions.

This would be particularly useful for groups containing multiple specialized bots, where all agents can share conversational context but should only speak when they have something relevant to contribute.

The evaluator implementation should not necessarily depend on a specific model or provider. A configurable model preset, deterministic policy, or another lightweight decision mechanism could be supported by the underlying abstraction.