By Wangchen
We released AgentTeams at this year's 520 Alibaba Cloud Summit, positioning it as an enterprise-grade multi-agent governance and collaboration platform. It enables enterprises to centrally create and orchestrate Agents, with each Agent supporting custom models, and to create group chats on IM platforms like DingTalk, WeChat Work, and Lark for team collaboration.
Anthropic recently released Claude Tag, embedding Claude directly into Slack channels as a team member. In ambient mode, Claude actively listens to the context, follows up on tasks, and reports progress without being explicitly @mentioned, powered by Opus 4.8 to enable asynchronous collaboration spanning hours.
In enterprise office scenarios, the shift from one-on-one private chats to many-to-many group chats naturally raises the question: will this become the new paradigm for using Agents? We're not rushing to draw conclusions—before settling on a paradigm, most people are more interested in understanding the differences between single chats and group chats.
In the Claude Tag blog, Anthropic defined four characteristics of Agent group chats:
Therefore, group chat ≠ the sum of multiple individuals chatting with a bot separately. If everyone in the group has their own session, it is merely parallel single chats.
Alibaba Cloud AgentTeams offers a more engineering-oriented definition. It abstracts group chats into a set of declarative CRDs, giving every Agent and every real human a layer of identity:
| Member | Identity |
|---|---|
| Manager | Human member, platform-level administrator |
| Team Leader | Agent, manager of N Workers |
| Worker | Agent, the smallest execution unit |
| Human | Human member, with three-tier permissions: L1 Admin / L2 Team Leader / L3 Worker |
Each Worker carries several declarative files: SOUL.md, AGENT.md, MEMORY.md, and USER.md. The underlying communication relies on the Matrix protocol, integrating into mainstream IMs like DingTalk, WeChat Work, and Lark via Element Web.
Group chat is not just an upgrade to the chat interface, but the beginning of organizational modeling.
Claude in Slack is Anthropic using Slack as the UI and reusing Slack's threads, channels, and DMs as a natural conversational topology. AgentTeams, on the other hand, treats group chats as an organizational resource that can be declared, scheduled, audited, and replicated.
In summary, Agent Group Chat Mode = Multiple Human Members × Multiple Agents × Shared Context × Asynchronous Tasks × Collaborative Flat Topology with Explicit Identity Weights.
Not all Agent scenarios require group chats. If it's just writing a piece of code, looking up a document, or generating an image, a single chat is a more direct and lower-cost option. The cost of introducing group chats is non-trivial. Whether it's user habits or the agent infrastructure behind it—including technical architecture, context management, permission governance, concurrent scheduling, and cost attribution—the complexity of each dimension escalates rapidly.
So, when is group chat actually needed? We can reason from a scenario without Agents: when do I need to switch from a single chat to a group chat?
Cross-domain collaboration requires multi-agents. The fundamental reason is that an Agent's context and memory are limited. Just like a human, if you cram too many responsibilities into one Agent, its attention scatters, and it won't do anything well.
Cross-domain work disperses attention across space, while long-running tasks dilute attention over time. For example, a software development process from requirement to release might run for hours or even days. As context builds up, the Agent's attention to early information is continuously diluted, and reasoning quality declines steadily.
When long-running workflows overlap with cross-domain work—where requirement analysis, coding, and testing are already tasks in different domains—it presents a dual challenge of both space and time. Breaking it down into multiple Agents to handle sequentially ensures that each context stays clean, attention remains focused, and intermediate states can be persisted. If something fails, it can resume from the checkpoint, making it more robust. Moreover, this must happen in a channel where everyone can see, intervene, and course-correct.
Alibaba Cloud AgentLoop's end-to-end coding pipeline is built on the AgentTeams group chat model. The TeamLeader in AgentTeams is responsible for orchestration and status management, while five Workers each manage a local Agent, covering Requirement Classification, Coding, Test, Review, and Verify. In Requirement Classification, complexity is defined in five levels from T1 to T5. Lint fixes are automatically handled end-to-end by the Agent pipeline, bug fixes are reviewed as PRs by humans, and architecture design is assisted by Agents. (The detailed practice of building AgentLoop with AgentTeams will be shared later by AgentLoop R&D Engineer Ma Yunlei)
The first two scenarios concern the limits of Agent attention; the third is about trust boundaries. When multiple teams of humans and Agents collaborate, there must be clear boundaries regarding whose Agent did what, how much was spent, and what data can be accessed. A single Agent cannot act on behalf of multiple organizational identities; it must be split into multiple independent Agents, each with its own ownership, authorization, and billing. AgentTeams supports hosting all LLM Keys, MCP credentials, GitHub PATs, and internal API Keys in the Higress AI Gateway, so Workers only hold revocable Consumer Tokens. These are all hard requirements for multi-agent governance.
Single-chat context is disposable—once the user closes the window, the memory lives mainly with the user and in the conversation logs. But group chats are different. New employees joining the group can directly @mention the Agent to complete onboarding. This is an organizational memory asset, not something a personal assistant can provide.
For example, AgentTeams provides an independent AI Registry that centrally manages Skills, MCP Servers, Agents, and Team Templates, supporting version management, security reviews, and hot reloading. Knowledge and conversations are kept separate: the former is an organizational asset reused across channels and teams; the latter is ephemeral context bound to a specific channel.
Single chats can hardly support any of the three scenarios above. Anthropic has already run 65% of its product team's PRs through Claude Tag, and Alibaba Cloud's AgentLoop uses AgentTeams to run end-to-end coding pipelines. This means that, at least in R&D scenarios, the marginal benefits of the group chat model have far outweighed the added complexity.
Admittedly, there are some behavioral differences between the multi-Agent group chat model and regular multi-person group chats, and they take some getting used to.
In single chats, the Agent interacts with a single identity. In group chat mode, platform administrators need to configure and manage member permissions.
Claude Tag uses an agent-identity model, treating the channel identity as the permission principal. No matter who @mentions Claude in the channel, the tool invocation permission boundaries are predetermined by the channel rules set by the administrator, rather than the permissions of the person who triggered it. For example, sensitive data in the HR channel can only be accessed by Claude within the HR channel; Claude in the R&D channel cannot access it.
AgentTeams, on the other hand, defines roles for both users and Agents. Users are divided into Admins and regular users. Each regular user can be assigned permissions controlling whether they can use the TeamLeader Agent and which Workers they can access. Agents are divided into TeamLeaders and regular Workers. Each Worker always holds only revocable credentials, with the actual credentials managed by the gateway.
Single-chat context is low-entropy; what you type is what the agent sees. Group-chat context is high-entropy: 30 people sending 80 messages in 5 minutes. If an Agent is told "Help me look at this," how does it determine which "this"?
Claude Tag's approach is not to guess, but to maximize the use of Slack's native thread model. All outputs are tied back to the originating thread, eliminating ambiguity through Slack's data structure rather than the Agent's reasoning.
AgentTeams, by contrast, delegates disambiguation to the TeamLeader. Tasks are first analyzed for intent and decomposed by the Leader within the Team, and then assigned to specific Workers for execution. Internal deliberation before external execution—that's an organizational approach to the problem.
Users therefore need to develop a new habit: start important tasks in threads rather than dropping them into the main channel. Otherwise, the context will be drowned out by group chat noise.
Single chats are turn-based: you ask, it answers, and then you ask again. Group chats are streaming: multiple users @mentioning the Agent simultaneously trigger independent tasks, which the Agent processes in parallel.
The concurrency model of AgentTeams is explicit. Each Worker is an independent container instance managed by the hiclaw-controller, analogous to the elastic scheduling of Pods under the K8s control plane. The "1 TeamLeader + N Workers" structure in the Team CRD itself is a declarative expression of concurrency.
The first three sections discussed the differences of group chat mode from the product and user perspectives. This section covers the infrastructure layer. During the design of AgentTeams, we asked ourselves: what new challenges does group chat mode pose to the infrastructure?
Broadly speaking, for single-chat Agents, the core issue is scheduling—how to decompose and assign tasks. But for group chat mode, the core challenge shifts to governance: who has permission to invoke which Agent? Who bears the cost? Who is accountable when things go wrong? Consequently, group chat mode requires unified identity, RBAC permissions, cost attribution, shared memory, and more. These requirements are hard requirements, and far more complex in enterprise team scenarios.
The permission subject in group chats is no longer the individual user, but a collective entity like a channel or Team. K8s solved this long ago: ServiceAccount is the identity of the Pod, not the person who created the Pod; RoleBinding binds roles, not employee IDs.
AgentTeams applies this model to Agent group chats and explicitly splits it into two orthogonal axes:
Worker Side: Each Worker has its own Consumer Token, its own subset of MCP Servers, and its own subset of Skills. The capability boundaries are declared in AGENT.md and reconciled by the hiclaw-controller at runtime. Workers cannot access undeclared tools or unauthorized channels.
Human Side: Humans are explicitly divided into three levels: L1 Admin is the organization administrator, who can create/dissolve Teams, configure Managers, and hold the master keys. L2 Team is TeamLeader (including the TeamAdmin human role), defining the four declarative files of the Team (SOUL/AGENT/MEMORY/USER) and deciding the Worker headcount and Skills. L3 Worker is the day-to-day requester, initiating tasks, @mentioning Workers, and reviewing outputs. The two axes are orthogonal yet interconnected: the same HR person might be an L1 Admin at the company level, but only an L3 Worker in the R&D Team; similarly, the same Worker might access sensitive fields in the HR channel, but cannot view them in the R&D channel.
In single-chat Agent scenarios, the Agent holds the user's OAuth tokens, API Keys, and MCP authorizations. But in group chat mode, when multiple people @mention the same Agent, whose token is used? When a task spanning hours resumes, the original requester's session has already expired.
AgentTeams addresses this entirely at the infrastructure level to achieve fine-grained permission control:
Step 1: [Agents never touch real credentials] All credentials are centrally managed in the Higress AI Gateway. LLM Keys, MCP credentials, GitHub PATs, and internal business API Keys are never distributed to Workers. A Worker only holds a revocable Consumer Token, and the gateway swaps in the real credentials for each outbound call. This is equivalent to extending the K8s ServiceAccount + RBAC model to the Agent's outbound traffic layer. Even if the Worker container is compromised, the attacker only gets a one-time temporary credential; the real key never leaves the gateway.
Step 2: [Master key derivation] Real credentials are used to derive multiple temporary credentials with restricted permissions. A Team holds a master API Key, and the platform derives N scoped credentials from this master key to distribute to each Worker. Derived credentials naturally carry three levels of tags: Tenant/Team/Worker. If a Worker is compromised or misused, the blast radius is strictly limited to its own derived credentials, leaving the master key and other Workers completely unaffected.
Step 3: [MCP credentials issued on demand and destroyed after use] When a Worker calls an MCP Server, the corresponding MCP credentials are issued at the task level, destroyed immediately after execution, non-forwardable, and non-persistable.
Memory issues in group chats are an order of magnitude more complex than in single chats. It's not just about adding a vector database. We need to answer at least four questions: How to prevent short-term conversations from flooding the token budget? How to accumulate long-term facts? How to explicitly forget outdated information? How to prevent organizational knowledge from polluting personal memories?
AgentTeams provides an open-source implementation , which is part of the AgentScope ecosystem alongside QwenPaw and serves as its "group chat version." Therefore, we adopted the ReMe memory framework.
L1 Short-term Memory: Raw conversational streams are written to session/dialog/. After each reply, the auto_memory hook writes lightly processed fact cards, conversation summaries, and resource reading notes for the day into daily//. This tier only cares about "what happened today," is structured and auditable, and does not directly participate in online recall, preventing short-term fragments from polluting long-term retrieval quality.
L2 Long-term Memory: It is organized into three types of structured directories: digest/{personal, procedure, wiki}/, corresponding to personal facts / operational experience / knowledge nodes. The backend is pluggable. Locally, it defaults to Markdown + BM25/Embedding/wikilink hybrid indexing. In enterprise production environments, it connects to the long-term memory service of AnalyticDB for PostgreSQL, where server-side LLMs extract facts, isolate them by Agent, and expose them via REST APIs.
When a Worker is decommissioned, the control plane has a clear cleanup hook to archive or destroy its workspace directory as a whole, preventing residual vectors from leaking to other Workers.
L3 Dream: Let the Agents "sleep" every night. auto_dream is a cron job that runs periodically, performing four operations on the day's daily/: backs up the current MEMORY.md to ensure rollback capability; scans all short-term memories; uses LLM to distill, correct, deduplicate, and merge short-term facts into long-term digest/; and outputs a "waking report" to memory/dreams/ for the Team Admin's review.
Additionally, Dream concurrently generates daily//interests.yaml for the proactive capability to read the next day, enabling the Agent to proactively surface "yesterday's unresolved issues, newly connected topics, and subjects users have been focused on but haven't asked about yet" in the channel at appropriate times.
Returning to the question raised at the beginning: will group chats become the new paradigm for using Agents?
Our assessment is that group chats will not replace single chats; rather, they will become a proving ground for AI-native organizations to dive deep into team collaboration efficiency. There are three reasons:
First, more than 70% of enterprise collaboration happens in IM group chats. As personal Agent usage becomes habitual, it will inevitably reshape how teams collaborate.
Second, the marginal benefit of individual productivity gains is diminishing. The evolution of single-user Agents has gone through four stages: prompt engineering, context engineering, harness engineering, and loop engineering. Yet efficiency black holes such as waiting, information loss, misalignment, and handoff friction persist in the gaps between people and between roles.
Anthropic chose to embed the model directly into Slack, believing a single powerful model is sufficient to serve as a capable teammate. AgentTeams, however, brings the entire K8s-style control plane into collaboration orchestration, taking a heterogeneous, open approach with multiple Agents, multiple IMs, and multiple models—believing that governance capabilities are just as much a hard requirement as model capabilities.
Third, the infrastructure for multi-agents is already in place, covering development and runtime, identity and credential governance, observability and evolution, context and memory, and more. However, one thing we need to be clear about: group chat is a form of organizational collaboration, not a silver bullet. Its cost is not low, and there may even be a long cold-start period, as context management, permission governance, concurrent scheduling, and cost attribution all become more complex.
In general, for Agents to improve organizational collaboration efficiency, we need both powerful models and new infrastructure that can run them reliably, securely, and cost-effectively.
[1] https://github.com/agentscope-ai/hiclaw
[2] https://github.com/agentscope-ai/QwenPaw
[3] https://github.com/agentscope-ai/ReMe
744 posts | 60 followers
FollowAlibaba Cloud Native Community - May 26, 2026
Alibaba Cloud Native Community - January 15, 2026
Alibaba Cloud Native Community - June 5, 2026
Alibaba Cloud Native Community - June 25, 2026
Alibaba Cloud Native Community - April 16, 2026
Alibaba Cloud Native Community - May 8, 2026
744 posts | 60 followers
Follow
Alibaba Cloud Model Studio
A one-stop generative AI platform to build intelligent applications that understand your business, based on Qwen model series such as Qwen-Max and other popular models
Learn More
Managed Service for Prometheus
Multi-source metrics are aggregated to monitor the status of your business and services in real time.
Learn More
Qwen
Full-range, open-source, multimodal, and multi-functional
Learn More
Alibaba Cloud for Generative AI
Accelerate innovation with generative AI to create new business success
Learn MoreMore Posts by Alibaba Cloud Native Community
