Agensh – A Multi-Agent Collaboration Framework Introduced by Microsoft Research

1. What is Agensh

Agensh is a multi-agent collaboration framework introduced by Microsoft Research. Its core innovation lies in a fully decentralized organizational structure—where all agents follow a unified five-step collaboration cycle. Through shared code repositories, instant messaging, and structured kanban boards, agents achieve self-organized task division, completely eliminating the need for a central supervisor agent. Experimental data shows that, without changing the underlying model, expanding the number of agents from 1 to 1024 increased the software reproduction test pass rate from 33.89% to 55.06%, a 49% improvement. This result demonstrates that the number of agents itself can become a new dimension for scaling AI capabilities, independent of model parameter size, providing empirical support for the large-scale deployment of multi-agent systems.

Technical positioning and domain: Agensh belongs to the field of multi-agent collaboration and swarm intelligence, focusing on addressing organizational and coordination challenges in large-scale agent collaboration. Unlike the current mainstream master-slave orchestration architecture, Agensh explores a fully decentralized self-organizing collaboration model, directly targeting the scalability bottlenecks of traditional centralized coordinators in large-scale scenarios.

Development background: This framework was primarily developed by Microsoft Research. The research team has deep expertise in the intersection of system architecture, distributed computing, and AI agents. The motivation for the research came from a review of existing agent collaboration frameworks—most of which rely on a central orchestrator for task allocation and result aggregation. This design faces challenges such as a sharp increase in coordination costs and single-point failure risks as the number of agents grows.

Core value: Agensh validates the "quantity equals capability" expansion path: without changing the underlying model or framework, task completion quality can be significantly improved simply by increasing the number of collaborating agents. At the same time, its infrastructure remains lightweight, requiring only three open-source components: Gitea, Mattermost, and a kanban board. The collaboration logic is implemented through prompt instructions rather than hardcoding, making it adaptable to different underlying frameworks such as Copilot and Claude Code.

Technical features: The framework employs a decoupled hierarchical architecture, separating the organizational layer from the individual agent layer. It uses an event-driven asynchronous runtime to achieve message routing and task scheduling. A typed shared context kanban board (with five categories: OBSERVED, FACT, FAIL, CLAIM, and PATCH_SUMMARY) enables organizational-level memory, allowing experiences and lessons learned from failures to be accumulated and reused across the group, avoiding redundant work and budget waste.

2. Key Features

• Decentralized Orchestration: The framework completely eliminates the role of a central supervisor agent, placing all agents on an equal footing. Agents autonomously claim tasks, negotiate responsibilities, and merge outcomes. This design removes the performance bottleneck and single point of failure risks associated with traditional architectures' central coordinators, allowing system scalability to no longer be constrained by the limitations of a single agent's coordination capacity.

• Five-Step Collaboration Cycle: Each agent continuously performs an asynchronous cycle of "Collecting Context → Claiming Subtasks → Executing and Sharing → Validating Results → Merging Progress." This cycle is implemented through workflow instructions embedded in prompts rather than hardcoding. All agents receive identical instructions, ensuring consistency and maintainability of the collaboration protocol.

• Shared Workspace: Based on Git (Gitea) for managing code collaboration, it supports concurrent development by multiple agents, branch merging, and conflict exposure. Git's version control mechanism naturally fits distributed collaboration scenarios, with merge conflicts explicitly recorded, making the integration process traceable and auditable.

• Message Negotiation Mechanism: Implemented using Mattermost, it provides team announcement channels and one-on-one private chats. Private chats support interrupting the other party's current task in real time to resolve task collisions. Messages are delivered in two priority levels: public channel messages are delivered at the start of each cycle, while direct messages and new board entries are packaged into the tool calling return results of the current turn and delivered midway, enabling real-time negotiation.

• Shared Context Board: Records five types of structured entries: OBSERVED (observable behavior), FACT (confirmed facts), FAIL (disproven hypotheses), CLAIM (publicly claimed scope), and PATCH_SUMMARY (summary of changes). The board supports two distribution paths: injecting the latest 2000 records at the start of a new turn, and appending new entries during the turn via tool calling. It also provides the board_grep tool for full historical AND/OR keyword searches.

• Scalability to Thousands of Agents: Experimental validation shows that the framework can scale up to 1024 agents under a 16-node × 64 configuration while maintaining self-organized collaboration without system crashes. The framework activates agents in batches using staggered scheduling, and large-scale deployment is automatically distributed across multiple nodes, effectively avoiding resource contention and network congestion.

• Spontaneous Role Emergence: As the organization grows, division of labor such as review conventions, standard procedures, and dedicated integrators naturally emerge without the need for predefined role definitions. This feature validates the emergence capability of self-organizing systems during scaling, offering a new organizational paradigm for collaborative work on complex engineering tasks.

3. How to Use

1. Environment Preparation: Ensure the machine has Docker container environment installed and has an available model API key. Agensh's shared infrastructure (Gitea, Mattermost, and Kanban service) is deployed as containers, and Docker is a prerequisite for running the system.

2. Clone the Repository: Pull the microsoft/Agensh repository from GitHub to your local machine. Note that the code is not fully open yet, and you should perform the git clone operation only after the official release by Microsoft Research.

3. Deploy Shared Infrastructure: Launch the three core components required by the framework: Gitea (code repository service), Mattermost (messaging communication service), and the shared context Kanban service. You can start them all at once using the provided docker-compose configuration, or customize the deployment to different nodes as needed.

4. Configure Agent Parameters: Set runtime parameters such as the number of workers, task objectives, and time budget in the configuration file. Also specify the type of underlying single-agent harness (e.g., Copilot, Claude Code) and the corresponding model API key. The configuration uses a declarative format and supports overriding with environment variables.

5. Start the Organization: Run the startup script, and the framework will activate agents in batches according to an off-peak scheduling strategy to avoid resource contention. In large-scale deployments, the system automatically distributes agents across multiple nodes, eliminating the need for manual node allocation.

6. Agent Autonomous Work: Members autonomously follow a five-step cycle to claim tasks, develop code, submit PRs, and merge into the main branch, with no need for human intervention throughout the process. Developers only need to monitor progress in the Mattermost public channel and can privately intervene and coordinate when necessary.

7. Wrap-up and Delivery: As the deadline approaches, the framework will automatically prompt for convergence. Agents will stop claiming new tasks and focus on merging and verification. The final results are delivered in the form of the main branch code and Kanban records. A complete collaboration history can be audited through Git commit records and Kanban entries.

4. Pros and Cons Analysis

5. Comparative Analysis with Similar Tools

Selection Recommendations: For long-term, highly coupled, and continuously integrated complex engineering tasks (such as large software reproduction, cross-domain foundational software porting), Agensh's decentralized self-organizing architecture demonstrates unique advantages, especially under strict hard time budget constraints, where large-scale agent parallel collaboration can significantly reduce task completion time. However, its code is not yet publicly available, and costs are not transparent, making it suitable for research institutions and enterprises with technical reserves to monitor.

For decomposable, loosely coupled, and tool-intensive broad-scope tasks (such as in-depth research, batch data processing), the orchestrator-worker architecture of Kimi Agent Swarm is more mature. Its reinforcement learning-based parallel strategy has been product-level validated in terms of real parallelism and task completion quality, and the model weights are open, making it suitable for rapid integration into existing business systems.

6. Editor's Summary

Agensh's core contribution lies in establishing "agent quantity" as an independently scalable dimension of capability. The significance of this discovery is on par with the expansion of model parameter scale—it reveals a path to enhance system capabilities through architectural optimization rather than relying on upgrades to the underlying model. From a technological innovation perspective, Agensh's decentralized architecture design represents a breakthrough at the methodological level: by integrating three lightweight open-source components—a shared code repository (Gitea), instant messaging (Mattermost), and structured kanban boards—along with collaborative loop instructions at the prompt level, it achieves a complete decoupling between the organizational layer and the individual agent layer. This design ensures that collaboration logic is not tied to a specific underlying framework, offering strong portability and adaptability.

In terms of practical value, Agensh has demonstrated its effectiveness in the five most challenging tasks of ProgramBench: a group of 128 agents can achieve a 30% pass rate within 30 minutes, whereas a single agent fails to meet the target within the first two hours. This data has direct reference value for scenarios such as high-time-sensitive emergency development and large-scale code audits. The typed kanban board design's organizational memory mechanism is particularly noteworthy—FAIL entries prevent peers from repeating costly mistakes, while PATCH_SUMMARY captures modification experiences in a fixed format. This structured experience reuse mechanism is a first in multi-agent systems.

In terms of target users, Agensh is more suitable for research institutions, AI platform teams in large enterprises, and technical teams with in-depth exploration needs in multi-agent collaboration. Its current code is not yet open-sourced, and the cost model is unclear, which implies that there are certain barriers to technical validation and secondary development. Key points to observe in its future development include: community ecosystem building after code open-sourcing, optimization strategies for diminishing returns, and whether it can validate its scalability advantages in more real-world business scenarios. Overall, Agensh provides a new perspective on the organizational architecture design of multi-agent systems, and its empirical conclusion that "quantity equals capability" is worth ongoing attention from the industry.

7. Application Scenarios

• Large-Scale Software Behavior Reproduction: Under offline or time-constrained conditions, hundreds to thousands of agents can reconstruct the behavior of large-scale software such as FFmpeg and pandoc from scratch, through hidden testing. Agents autonomously identify and claim module development tasks by observing the observable behavior of reference programs (OBSERVED entries), merge their results through the PR process, and ultimately achieve functional reproduction of complex software.

• High-Time-Efficiency Emergency Development: Suitable for urgent development tasks with strict time constraints. Within 30 minutes, 128 agents can achieve a level of completion that a single agent would not be able to reach in two hours. For time-sensitive scenarios such as security vulnerability fixes and emergency feature rollouts, large-scale parallel collaboration can significantly shorten delivery cycles.

• Ultra-Large-Scale Code Auditing: Agents can divide and claim code modules, write test cases in parallel, and review each other's PRs, making this approach naturally compatible with security audits and test coverage expansion in large enterprise codebases. The CLAIM declaration mechanism prevents multiple agents from reviewing the same module repeatedly, while the FAIL entry records disproven security assumptions, avoiding redundant verification.

• Exploratory R&D Without Preset Plans: When tasks cannot be pre-decomposed, agents can autonomously identify task boundaries by observing reference behaviors. This is ideal for situations with vague requirements and boundaries that must be determined through exploration. The self-organizing division mechanism allows agents to dynamically adjust task assignments based on exploration progress, without requiring human-defined work plans.

• Cross-Domain Base Software Porting: In multi-domain system development such as PHP interpreters and molecular simulations, swarm intelligence can cover the knowledge breadth of "no single generalist." Agents with different domain expertise complement each other, and experts in the same domain can serve as backups and take over tasks, ensuring that critical tasks are not interrupted due to single-point failures.

8. FAQ

Q: What is the fundamental difference between Agensh and traditional multi-agent orchestration frameworks (such as AutoGen)?
A: Agensh employs a fully decentralized architecture, without a central agent or orchestrator. Traditional frameworks (such as AutoGen) rely on dialogue scheduling or orchestrators for task assignment and result aggregation, whereas Agensh enables all agents to self-organize, claim tasks, negotiate responsibilities, and merge outcomes through three infrastructure components: a shared code repository, real-time messaging, and a structured board. This design eliminates the performance bottleneck of a central coordinator, allowing the system to scale up to thousands of agents.

Q: How is the collaboration loop specifically implemented in Agensh?
A: Each agent repeatedly performs a five-step asynchronous loop: "collect context → claim subtask → execute and share → verify result → merge progress." The collaboration loop is not hard-coded into the runtime but is instead implemented through workflow instructions in the prompt. All agents receive identical instructions. In the event-driven architecture, the router continuously monitors Gitea repository activity and Mattermost messages, writing new events into a deduplicated persistent queue. The dispatcher then merges and sorts these events before injecting them into the agents during their next turn.

Q: How does Agensh prevent multiple agents from performing the same task?
A: The framework includes a dual anti-collision mechanism. When claiming a subtask, an agent must publish a CLAIM statement on the board specifying its scope. If overlap is detected with another agent, both parties negotiate in private chat to adjust their assignments. Additionally, the board records FAIL entries for disproven hypotheses. Subsequent agents can use the board_grep tool to search historical records and avoid revalidating previously failed approaches, thus saving budget and time.

Q: What hardware and runtime requirements does Agensh have?
A: To run Agensh, a Docker environment is required to deploy the three infrastructure components: Gitea, Mattermost, and the board service. Additionally, an accessible model API (such as Copilot, Claude Code, or other underlying harnesses) is needed. For large-scale deployment (e.g., 1024 agents), a multi-node distributed environment is necessary (the experiment used a 16-node × 64 configuration). Single-machine deployment is limited by computational resources and model inference capabilities.

Q: Are the code and paper for Agensh publicly available?
A: The paper has been publicly released and is available via arXiv (https://arxiv.org/pdf/2609.26781). The code repository microsoft/Agensh has been created on GitHub, but as of the time of this article's publication, it is not yet fully open-sourced. Users must wait for the official release from Microsoft Research before cloning it. The project website (https://agens-harness.github.io/project/) provides an overview of the framework and experimental data.

Q: Does Agensh's performance continue to improve as the number of agents increases?
A: Experimental data shows that performance improvements exhibit diminishing returns: when scaling from 1 to 128 agents, the average test pass rate increases by approximately 49%. However, scaling from 128 to 1024 agents only adds an additional 4.12 percentage points. This indicates that after reaching a certain scale, the marginal gains from increasing the number of agents significantly decrease. Therefore, when deploying in practice, it is essential to balance task complexity and cost budget to determine the optimal scale.

9. Project Links

• Project Website: https://agens-harness.github.io/project/
• GitHub Repository: https://github.com/microsoft/Agensh (Code is not yet fully open-sourced; will be officially released by Microsoft Research. Please refer to the official release for details.)
• arXiv Technical Paper: https://arxiv.org/pdf/2609.26781