Ant Group Open-Sources Avernet to Build “Organizations” for Agents

Ant Group Open-Sources Avernet, Bringing Multi-Agent Systems into the Realm of “Organizational Operations”

Ant Group recently officially open-sourced Avernet, a multi-agent collaboration infrastructure, and the community edition is now available.

This is not another framework that simply “lets multiple Agents send messages to one another.” Avernet’s goal is closer to establishing an organizational system for agent collaboration: who can join, who is responsible for what, which tools each participant can call, how tasks are assigned, how execution is tracked, who conducts a postmortem when something goes wrong, and at which points humans should intervene.

The significance lies in a clear shift currently taking place in the Agent industry: from asking whether an individual model can complete a task to asking whether a group of models, tools, and people can work together reliably over the long term. The former is primarily a question of model capabilities, while the latter is more of a hybrid problem involving software engineering, organizational management, and security governance.

“Multi-Agent Chat” Is Not Collaboration Infrastructure

Over the past period, most multi-agent projects have revolved around several classic patterns: a lead Agent breaks down a task while multiple sub-Agents execute the individual parts; or several Agents take turns discussing an issue, after which a summarizing Agent produces the final output.

These approaches are suitable for demonstrations and can solve some one-off tasks. However, once they enter real business environments, problems quickly emerge:

• Agents do not know what one another are good at, so task assignment depends on hard-coded rules;
• Multiple Agents may perform the same task repeatedly or end up waiting for one another;
• The information and permissions obtained by one Agent may be passed to another in an uncontrolled manner;
• After a task fails, it is difficult to determine which step went wrong;
• Humans can often only issue instructions before a task begins or receive a black-box result at the end;
• When the number of participants grows from a few to dozens or hundreds, what was originally simple prompt orchestration can quickly spiral out of control.

Therefore, a true multi-agent system is not simply a collection of chat windows. It must address foundational issues such as discovery, division of labor, authorization, scheduling, communication, auditing, and feedback.

Avernet is targeting precisely this infrastructure layer. According to Ant Group’s public introduction, it focuses primarily on discovery, consensus, collaborative execution, and feedback-driven evolution among multiple Agents, while also supporting group management, different collaboration modes, and traceable execution processes.

In other words, Avernet is attempting to move Agents from being “programs that can call tools” to being “governable members of an organization.”

From “All-Purpose Agents” to Role-Based Division of Labor

One of Avernet’s most notable aspects is that it does not continue to pursue the path of having a single all-purpose Agent handle everything. Instead, it breaks multi-agent systems into different roles.

In an enterprise operations scenario, one Agent could be responsible for understanding business objectives, another for retrieving data, a third for generating content, and a fourth for conducting risk checks, with execution taking place only after human approval. These Agents do not engage in endless, equal-status conversations. Each assumes clearly defined responsibilities and exchanges the necessary information through collaboration mechanisms.

This design is more like a project team within a company than a group of robots freely discussing matters around a conference table.

From an engineering perspective, role-based design offers at least three advantages.

First, it reduces the context burden. An Agent does not need to understand every business detail; it only needs the tasks and context relevant to its responsibilities. For long-running tasks, this is more controllable than feeding an entire conversation history into a single large model.

Second, it makes replacement and expansion easier. If the Agent responsible for data analysis needs to be replaced with a different model, the entire task flow theoretically does not need to be rewritten. As long as the replacement continues to comply with the role contract, other participants can continue calling it.

Third, it facilitates auditing. What enterprises truly care about is usually not “why did the model think this way,” but rather “which Agent, at what time, with what permissions, performed what actions, and affected which data.” The clearer the roles and processes, the easier it is to establish lines of responsibility.

The V0.1 version previously disclosed by Avernet already provided capabilities including group management, master-slave modes, custom orchestration, and traceable execution. The official release of the community edition means that Ant Group hopes to move this approach from internal exploration into the developer ecosystem.

Four Key Problems: Discovery, Consensus, Execution, and Evolution

1. Discovery: First Know “Who Can Do What”

In a single-Agent application, developers can directly write a tool list into the system prompt. But in an open multi-Agent network, participants may come from different teams and platforms, and their capabilities may change dynamically.

Therefore, the system needs a mechanism similar to an “organizational directory” or “service registry,” allowing Agents to discover other members and understand their capability boundaries, input and output formats, and availability status.

This step may seem basic, but it is a prerequisite for collaboration at scale. Without capability discovery, developers can only hard-code the addresses and invocation rules of all Agents, ultimately producing nothing more than a fragile workflow.

2. Consensus: Resolving Disagreements Among Multiple Agents

A multi-agent system is not necessarily more intelligent. Multiple models may produce conflicting conclusions or even “pass the buck” to one another because they have different objective functions.

Therefore, a collaboration system needs to define task objectives, decision-making rules, and conflict-resolution mechanisms. For example, some tasks may be decided by the lead Agent; others may require multiple specialized Agents to reach consensus above a given threshold. Operations involving payments, publishing, or data deletion must be submitted to a human for approval.

This is also one of the dividing lines between Avernet and ordinary Agent orchestration tools: orchestration tools generally focus on “who should be called next,” while organizational infrastructure must also answer the question, “Who is qualified to make the decision?”

3. Collaborative Execution: Making Tasks Divisible, Delegable, and Traceable

A complex task is often not linear. New information may emerge during execution, requiring additional roles to be added temporarily. If a tool call fails, the system may need to retry or switch executors. Once one task is complete, its result may need to be handed to a review Agent rather than directly to the end user.

The collaborative execution and traceability mechanisms emphasized by Avernet are designed to address precisely these dynamic processes. It is closer to a distributed task system for Agents: tasks can be divided into subtasks, subtasks can be delegated to different Agents, execution status and context can be recorded, and exceptions can be located.

A collaboration can be abstracted into a structure like the following:

organization:
  goal: "Complete a marketing campaign postmortem"
  roles:
    - name: coordinator
      responsibility: "Break down tasks and consolidate results"
      permissions: ["read:reports", "delegate:tasks"]
    - name: analyst
      responsibility: "Analyze campaign and conversion data"
      permissions: ["read:metrics"]
    - name: reviewer
      responsibility: "Review conclusions and sensitive information"
      permissions: ["read:summary", "flag:risk"]
  human_gate:
    - "Publish externally"
    - "Modify business data"

This is not Avernet’s actual configuration format. Rather, it represents the engineering philosophy behind Avernet: define the organization, roles, and permissions first, then allow Agents to collaborate within those boundaries instead of handing all decisions over to an ever-expanding prompt.

4. Feedback-Driven Evolution: Turning Individual Executions into Organizational Experience

If every task starts from scratch, an Agent organization will have difficulty becoming truly more efficient.

The system needs to record task outcomes, reasons for failure, human modifications, and final evaluations, then convert this feedback into subsequent routing rules, role adjustments, or process optimizations. For enterprises, this is particularly important because what can be reused is not a single conversation, but a validated process and accumulated experience.

The fact that Ant Group lists “feedback-driven evolution” as one of the problems Avernet aims to solve indicates that its design focus is not limited to real-time collaboration, but also includes organizational optimization after long-term operation.

Master-Slave and Custom Orchestration Are Not an Either-Or Choice

Based on the information disclosed so far, Avernet supports collaboration methods such as master-slave modes and custom orchestration.

Master-slave mode is relatively well suited to tasks with clear objectives and centralized responsibility: a managerial Agent breaks down and schedules the work, while specialized Agents execute specific tasks. This mode is easy to understand, simple to control, and suitable for early enterprise adoption.

Custom orchestration is better suited to more complex processes. Developers can design steps such as parallel execution, sequential execution, conditional branches, human approval, and exception rollback according to business needs. Compared with relying entirely on autonomous planning by models, this approach sacrifices some flexibility in exchange for greater predictability.

In actual deployments, the two will likely be used together: models can handle uncertain aspects, such as identifying user intent and selecting the appropriate specialist, while fixed processes handle high-risk and highly regulated operations, such as payments, releases, and data writes.

This is a more realistic path for putting Agent systems into production. A completely free-form autonomous system is difficult to audit, while a completely fixed workflow cannot cope with changes in the real world. Placing autonomous decision-making and deterministic processes at different layers is more consistent with enterprise system requirements.

Avernet, AgentOS, and ASL: Ant Group Is Filling in the Same Infrastructure Map

Avernet is not an isolated project within Ant Group’s broader Agent infrastructure strategy.

The overall direction recently proposed by Ant Group includes capabilities such as AgentOS, an Agent immune system, Avernet, and ASL. AgentOS is oriented more toward the runtime foundation for Agents, providing scheduling, execution, and security capabilities for different endpoints and enterprise scenarios. The Agent immune system emphasizes dynamic governance throughout the entire lifecycle. Avernet is responsible for organizational collaboration among multiple Agents. ASL seeks to add trusted identity, trusted intent, and trusted authorization to connections among Agents across devices, platforms, and entities.

These layers correspond to different questions:

• AgentOS: Where do Agents run, and how are resources scheduled?
• Avernet: How do multiple Agents divide work, collaborate, and conduct postmortems?
• ASL: How do Agents belonging to different entities verify identities, establish connections, and control authorization?
• Governance and security mechanisms: How can Agents be constrained, held accountable, and restored when something goes wrong?

Ant Group’s previous descriptions of trusted Agent security included capabilities such as TEE trusted execution environments, DID decentralized identities, and PKI public key infrastructure, while emphasizing least privilege, intent tamper resistance, and process auditability. If these capabilities are to truly be applied to multi-agent collaboration networks, they cannot exist merely as peripheral security components. They need to be integrated with task delegation, tool invocation, and identity transfer.

This will also be key to whether Avernet can establish differentiation in the future. The market already has numerous open-source frameworks for task orchestration alone. If Avernet can combine organizational management, identity and permissions, and collaborative execution, it may have the opportunity to become infrastructure for enterprises and open ecosystems.

Is Avernet Worth Developers’ Attention Right Now?

Here is the short answer: Avernet is worth watching, but it should not be treated as an out-of-the-box “universal solution for multi-Agent systems.”

Its main value lies in proposing an abstraction closer to production environments: an Agent is not an isolated chatbot, but a service node within an organization. For teams building enterprise-grade Agent platforms, operations automation systems, AI research and development pipelines, or collective decision-making systems, this abstraction offers more useful guidance than simply adding a few more model calls.

Avernet’s approach is particularly suitable for the following scenarios:

1. Operational efficiency: Customer service, content, data, and review Agents collaborate by role while retaining approval checkpoints;
2. AI research and development: Different Agents handle requirements analysis, code generation, testing, deployment, and security checks;
3. Complex decision-making: Multiple specialized Agents provide independent opinions, after which a decision Agent or human forms the final conclusion;
4. Open ecosystems: Agents developed by different teams join the same collaboration network through capability descriptions and permission mechanisms.

However, it also faces three practical challenges.

First, are its protocols and abstractions open enough? A multi-agent ecosystem cannot remain centered on a single platform indefinitely. Avernet needs to be compatible with existing tool invocation protocols, Agent communication protocols, and enterprise identity systems rather than creating another closed layer.

Second, governance costs will rise with scale. The more roles there are and the longer the delegation chains become, the more complex permission configuration, state synchronization, and exception handling will be. An “organization” is more powerful than a workflow, but also more difficult to maintain.

Third, model capabilities remain a bottleneck. No collaboration mechanism, however well designed, can replace the underlying model’s ability to reason, plan, and use tools. If Agents cannot reliably understand tasks and execution constraints, organizational structures will only make errors spread faster.

Therefore, Avernet’s short-term value is more likely to lie in standardized collaboration and engineering governance than in suddenly making models more intelligent.

After Open-Sourcing, the Real Test Will Be the Ecosystem

After Avernet’s official open-source release, what developers should pay attention to is not the number of scenarios mentioned in promotional materials, but several verifiable metrics: whether the community edition’s interfaces are stable, whether it supports independent deployment, whether it can connect to different models and tools, whether task status is observable, whether permission controls reach down to the tool and data layers, and whether cross-organizational collaboration has clear security boundaries.

If these issues can be resolved, Avernet may become an important variable in the competition surrounding multi-agent infrastructure in China. It may not replace existing workflow engines, Agent frameworks, or communication protocols, but it could fill in the missing “organizational layer” above them.

For developers, the most valuable takeaway is not any particular fixed Agent orchestration method, but the layered approach: models handle reasoning, tools handle execution, the organizational layer handles division of labor and collaboration, the security layer handles identity and authorization, and humans handle critical decisions and ultimate responsibility.

The truly difficult part of the Agent era is no longer simply getting one model to complete a task. It is enabling a group of not-completely-reliable software entities to remain controllable, explainable, and accountable over long-term operation. By open-sourcing Avernet, Ant Group is effectively answering this question: when the number of Agents grows from a few to hundreds or thousands, how exactly should we manage them?

If this answer proves viable, Agents will no longer be merely a feature within applications, but will gradually become a new form of organizational infrastructure.

References

• GitHub Avernet project search page: Used to review the community edition code, related repositories, and developer activity.
• Public introductions by Ant Group and related teams: Public information about the Avernet community edition, AgentOS, ASL, and Agent security infrastructure, compiled and organized here as the basis for this article.