[Discussion] Is it a cool idea to allow mixed group chat with multiple agents&users?

[DavdGao]

Background

• In the current main branch, we have supported agent teams and the ability to invite existing agents into a team chat.
• Our agent service supports multi-tenancy natively.

Taking this a step further — what if we allowed multiple users to participate simultaneously? That is, multiple agents and multiple users freely engaging in a group chat within our agent service. However, there are some open questions to address:

• Agent reply triggering: In a group chat, when should an agent reply? One approach is to introduce a gating SOP — for example, first checking whether the agent intends to respond before allowing it to reply. Alternatively, the agent could reply only when explicitly mentioned or addressed.
• Invitable user scope: Not everyone would want to be added to a group chat without their knowledge. How should we determine who can be invited? Should we define user relationships similar to how IM apps manage contacts, or should we wrap this logic around resource access control?
• Validity of the idea: It remains unclear whether this is truly a valuable feature or whether there is a genuine demand for it within our agent service.

Ideas, feedback, and suggestions are welcome!

[iluv7]

Hi, @DavdGao , I'm very interested in this idea! I'll be honest — I don't fully grasp the multi-user part (inviting human users into a group chat), but I have a lot of thoughts on agent group chat. So that's what I'll focus on below.

1. Agent Reply Triggering — When Should an Agent Speak?

Both of your ideas (gating SOP / @mention) make sense. I recently looked at AutoGen's group chat implementation, and it gave me some useful perspective.

How AutoGen Does It

AutoGen's group chat has three speaker selection modes:

Mode	Approach	Best For
Round Robin	Rotating turns, one after another	Fixed pipelines (write → review → revise)
Handoff / Swarm	Agent explicitly hands off to the next speaker	When an agent knows who to pass to
LLM Selector	Conversation history + each participant's role card → LLM picks the next speaker	Open-ended discussion

The most interesting one is SelectorGroupChat: the right to speak is decided by a dedicated, lightweight LLM call, separate from any agent's own reasoning. The selector prompt is short (it only does one thing — pick a speaker), so it doesn't need to load the agent's full system prompt or tool list. Very low cost.

My Take: A Hybrid Model

We could build a SpeakerSelector as an independent component that doesn't intrude on the agent's ReAct loop:

Message arrives in the group chat
    │
    ▼
┌─────────────────────────────────┐
│      SpeakerSelector            │
│                                │
│ 1. Has @mention? → strong signal│
│    "@Bob look into this" →      │
│    wakeup Bob directly          │
│                                │
│ 2. No mention? → LLM selector   │
│    Last N messages + each       │
│    participant's role card      │
│    → decide if any agent        │
│    should jump in               │
│                                │
│ 3. No agent needs to respond?  │
│    → leave message in chat log  │
│    don't trigger anyone         │
└─────────────────────────────────┘

Core principles:

• @mention is the top-priority strong signal — no LLM needed
• LLM selector is optional — only invoked when there's no explicit mention, keeping costs predictable
• Agents can be configured: mention-only response vs. proactive participation
• Selector is an independent component — doesn't touch the existing agent ReAct loop

This is smarter than pure @mention, more controlled than pure gating SOP. And the selector itself can start simple (pure rule-based or mention-only) before evolving.

---

2. Agent Sharing — From AgentInvite to Agent Market

AgentInvite currently only works within the same user_id. But once cross-user agent sharing is enabled, something more interesting emerges.

Cross-User Agent Sharing

User A has tuned a SQL expert agent. User B needs that capability in their own project → B invites A's agent into their team → the agent gets to work. This is capability reuse, as natural as code reuse or tool reuse. AgentScope's InviteConfig + ResourceAccessPolicyBase + TeamMember.owner_id schema already has the foundation for this.

Agent Market

Once agents can be shared across users, we could build an Agent Market — a place where users can discover agents shared by others:

┌──────────────────────────────────────────────────┐
│                Agent Market                       │
│                                                   │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐           │
│  │ SQL     │  │ Code    │  │ Design  │  ...      │
│  │ Expert  │  │ Reviewer│  │ Reviewer│           │
│  │ @alice  │  │ @bob    │  │ @carol  │           │
│  │ ⭐4.9   │  │ ⭐4.7   │  │ ⭐4.5   │           │
│  │ 1.2k uses│ │ 890 uses│  │ 2.1k uses│          │
│  └─────────┘  └─────────┘  └─────────┘           │
│                                                   │
│  Each agent has:                                  │
│  - public profile (name, description, tags)       │
│  - usage stats (invite count, ratings)            │
│  - example conversations                          │
│  - invitable scope (public / selected / private)  │
└──────────────────────────────────────────────────┘

Why this is interesting:

• Discoverability: Users can find agents others have built instead of starting from scratch. Good prompt engineering deserves reuse.
• Community-driven: Quality agents naturally gain traction, creating a positive feedback loop.
• Natural synergy with group chat: Need a capability in your group chat? → search the market → one-click invite into the team. The market is the supply side for group chat.
• Existing groundwork: The invite_description field in InviteConfig is practically a market listing already.

And this stands on its own merit — even without group chat, agent sharing and a marketplace are valuable features.

---

Just my two cents. Would love to hear your thoughts and corrections!