---
title: 'Agensh: Decentralized Multi-Agent System'
url: https://www.emergentmind.com/topics/agensh
type: topic
---

# Agensh: Decentralized Multi-Agent System

Agensh is a decentralized multi-agent harness designed to scale organizational intelligence by enabling large populations of AI workers to coordinate without a central orchestrator. Its workers repeatedly gather shared context, claim and self-assign subtasks, act independently, verify results, communicate findings, and merge progress through a shared organizational infrastructure. The system combines a shared workspace, a message interface, and shared context, and was evaluated with GPT-5.6-sol on difficult ProgramBench software-reconstruction tasks at scales reaching 1,024 agents. The name is also discussed in relation to the concept of a social harness: infrastructure governing interactions among agents representing independent principals across trust boundaries [2609.26781] [2609.17527].

## 1. Conceptual foundations

Agensh addresses a limitation of conventional multi-agent systems: the coordination bottleneck created by a central orchestrator. In an orchestrator–worker architecture, a lead agent receives the goal, decomposes it, assigns subtasks, collects results, resolves dependencies and conflicts, and integrates the final product. As the number of workers increases, the orchestrator must track more state, coordinate more interactions, and integrate more outputs.

Agensh distributes these functions across workers and shared infrastructure. It does not eliminate coordination; rather, it replaces a single planning authority with a persistent, self-organized process. Each worker inspects the current organizational state and selects an unfinished, useful contribution. Task discovery, allocation, verification, and integration are therefore continuous activities rather than stages controlled by a central coordinator.

The underlying worker remains a conventional single-agent system. Its local harness maintains conversational state, invokes the model, executes tools, and generates responses. Agensh adds organization-level identity, event routing, state sharing, messaging, workspace access, recovery, and liveness mechanisms. Workers receive essentially the same instructions, differing primarily in worker identifier.

This design makes agent count an additional scaling dimension for multi-agent organizations. Instead of relying exclusively on model size, training data, inference-time compute, or context length, Agensh evaluates whether a fixed model can solve more difficult tasks through larger and better-organized populations of workers.

## 2. Cooperation loop

Agensh workers execute a repeated five-step multi-agent cooperation loop.

1. **Gather context**: The worker reads the shared user goal, the current shared workspace, peer progress, messages, accumulated findings, active claims, and work intentions. It may inspect the environment by running the target binary, examining code, running tests, or identifying missing behavior. The purpose is to determine what has been completed, what remains incomplete, which areas are claimed, which approaches have failed, and what independent contribution is most useful.

2. **Claim and self-assign a subtask**: The worker proposes a subtask and records its scope as a `CLAIM` in shared context. No central scheduler assigns the work. Workers are instructed to avoid duplicating existing claims and to communicate when their intended scope overlaps with another worker’s. Overlapping work may be divided by file, feature, interface, or behavior; transferred to another worker; assigned as implementation and review; or organized around a shared interface.

3. **Take action**: The worker performs the claimed work locally using available tools. In ProgramBench, this involves reverse-engineering a reference executable and constructing an implementation from scratch without Internet access. Workers may inspect reference behavior, edit files, run tests, investigate edge cases, build and compile, implement features, review contributions, or prepare branches and pull requests. Useful findings are published to shared context so that they are not confined to private conversational histories.

4. **Verify results**: Before merging, the worker compares its result with acceptance criteria. Verification may involve tests, comparison with the reference executable, compilation checks, boundary-case analysis, peer review, or compatibility checks against the current main branch. The intended unit of organizational progress is verified work rather than an untested intention or patch.

5. **Merge progress**: The worker makes its contribution available by merging it into the shared workspace and publishes an update describing the change, its underlying idea, and verification evidence. If a merge conflict occurs, the worker incorporates the latest peer changes, resolves the conflict, and retries the merge. It then returns to context gathering, allowing newly integrated work and findings to influence subsequent assignments.

The loop is asynchronous. Workers do not wait for all other workers to complete their current subtasks. New events, findings, claims, and merges alter the state from which later iterations proceed. An idle worker receives a continuation prompt after 10 minutes, and a follow-up asks a worker to publish useful findings if a completed turn produces no shared-context entry. Failed event deliveries are retried, and durable queues support recovery after router restarts where possible.

## 3. Organizational infrastructure

Agensh consists of three principal infrastructure components: a shared workspace, a message interface, and shared context.

### Shared workspace

The shared workspace contains files under development, integrated results, branches, issues, pull requests, and version history. Agensh implements it with Gitea and Git repositories. Workers generally modify private checkouts or branches, commit changes, submit pull requests, and merge successful contributions into the main branch.

The workspace provides concurrent writes, asynchronous reads, independent development, provenance tracking, merge operations, conflict exposure, recovery, and backtracking. Git supplies version history and detects textual conflicts, while Gitea issues and pull requests become part of the coordination process. A branch or pull request represents a concrete contribution; a conflict indicates that workers must reconcile divergent assumptions.

### Message interface

Agensh uses Mattermost for communication. It provides a shared task channel for organization-wide announcements and direct messages for urgent or targeted interactions. Lower-priority shared-channel messages are delivered at the beginning of a worker’s next loop iteration, while higher-priority direct messages are delivered at the end of each infrastructure tool call. Message history is retained, and messages may arrive while workers proceed independently.

Direct messages support overlap resolution, dependency negotiation, review requests, integration transfers, and cancellation of redundant work. An event-driven router listens for Gitea and Mattermost activity, writes events into durable worker queues, and wakes the dispatcher. Events have unique identifiers for deduplication. Failed deliveries are retried with progressively longer delays, and unfinished events are restored after router restarts where possible.

### Shared context

Shared context stores reusable findings and work intentions. Inspired by DeLM, it is implemented as an append-only database with recent-memory access and search over the full history. Entries have explicit types:

- `OBSERVED`: a noticeable behavior;
- `FACT`: a confirmed fact;
- `FAIL`: an unsuccessful or falsified approach;
- `CLAIM`: active work being undertaken;
- `PATCH_SUMMARY`: a completed change, including files, idea, and evidence.

The distinction between `FACT` and `FAIL` allows confirmed discoveries to guide subsequent work and failed approaches to prevent repetition. Recent entries are automatically made available to workers, while a `context grep` tool searches older entries beyond the recent-memory window. In the reported implementation, entries are capped at roughly 100 characters, or 300 characters for patch summaries, with longer descriptions available separately.

Shared context is not the final codebase. It records behavioral discoveries, failed hypotheses, active ownership, completed changes, reusable procedures, and integration status. The workspace contains the implementation; the message interface supports interpersonal coordination; and shared context maintains organizational memory.

## 4. Coordination, verification, and emergent roles

Agensh distributes task decomposition, conflict avoidance, dependency handling, validation, and integration across workers.

Workers decompose the global task locally by inspecting organizational state and selecting useful unfinished subproblems. In software reconstruction, these may involve command-line behavior, parsing, file formats, error handling, boundary cases, compilation, testing, or integration. Decomposition is continuously revised as new requirements are discovered.

Conflict avoidance depends on `CLAIM` entries, direct messages, and Git branches and merges. Claims disclose intended scope, messages settle overlaps, and repository operations expose implementation conflicts. This mechanism is weaker than a formal lock manager because it relies substantially on workers noticing relevant claims and following the coordination protocol.

Dependencies are negotiated through messages and repository state. Workers can announce required contributions, request assistance, wait for or build on another branch, transfer integration responsibility, and synchronize with the latest main branch. Validation is decentralized: the implementing worker tests its contribution, while peers may review, challenge, or reject it.

The reported trajectories indicate progressively more structured cooperation as the organization grows:

- **Eight agents**: Workers exhibit peer coordination around implementation, including agreement on technical interfaces, independent module development, detection of overlapping claims, and scope changes after communication.
- **Thirty-two agents**: Cooperation extends to distributed quality control. In a PHP-src example, workers approved a contribution, another worker found a counterexample, approval was withdrawn, the author corrected the issue, peers reviewed it again, and a peer merged the corrected contribution.
- **128 agents**: Workers select reviewers based on experience, transfer integration responsibility, resolve conflicts, validate combined work, and reuse standardized procedures. In pandoc, workers developed an update–test–check–merge protocol in which a peer could perform the entire cycle.
- **1,024 agents**: The organization exhibits more explicit specialization and redundancy. Several workers act as integrators, workers contact candidate integrators, select the first valid responder, cancel redundant requests, and transfer code only after selection. Workers with related expertise can recover and take over when another worker fails.

The reported progression is from peer coordination to multi-worker integration, standardized workflows, and specialized and redundant roles. It is a qualitative interpretation of worker trajectories rather than a formally measured emergence curve. The paper does not report counts of messages, claims, conflicts, merges, role assignments, or workflow-reuse rates.

## 5. Evaluation and scaling results

Agensh was evaluated on ProgramBench, which asks agents to reproduce the behavior of reference software from scratch. Internet access was disabled, the time budget was six hours, the reference implementation was available only as a precompiled executable, and success was measured by the canonical-kept test-pass rate.

The evaluation selected the five hardest tasks among 200 ProgramBench instances according to the average pass rate of state-of-the-art models:

- FFmpeg;
- GROMACS;
- pandoc;
- PHP-src;
- universal ctags.

These tasks span multimedia processing, molecular simulation, document conversion, language interpretation, and code indexing. All reported configurations used GPT-5.6-sol with high reasoning effort, Copilot as the underlying single-agent harness, the same worker protocol and evaluation configuration, a maximum input limit of 272,000 tokens, and a maximum output limit of 128,000 tokens.

The principal five-task experiment compared $N \in \{1,8,32,128\}$ agents. Mean final test-pass rates were:

| Agents | Mean final test-pass rate |
|---:|---:|
| 1 | 19.31% |
| 8 | 20.68% |
| 32 | 26.52% |
| 128 | 28.78% |

Scaling from one to 128 agents produced an absolute improvement of 9.47 percentage points, from 19.31% to 28.78%, corresponding to an approximately 49% relative improvement. The paper reports a generally increasing trend across the five tasks as organization size grows.

The evaluation also examined time to intermediate performance. On pandoc, a test-pass rate above 30% was reached after 30 minutes with 128 agents, 60 minutes with 32 agents, and 90 minutes with eight agents. The single-agent configuration did not exceed 30% during the first two hours. The paper presents these results as evidence that larger organizations can reduce latency under a hard deadline.

A larger pandoc experiment compared one, 128, and 1,024 agents:

| Agents | Final test-pass rate |
|---:|---:|
| 1 | 33.89% |
| 128 | 50.94% |
| 1,024 | 55.06% |

Scaling from one to 1,024 agents increased the final test-pass rate by 21.17 percentage points, from 33.89% to 55.06%. The 1,024-agent organization exceeded the 128-agent result by 4.12 percentage points. These values suggest continuing but diminishing marginal returns: the increase from one to 128 agents was 17.05 percentage points, whereas the increase from 128 to 1,024 agents was 4.12 points. The paper does not fit a scaling law or formally quantify this effect.

The 1,024-agent deployment used 16 nodes with 64 agents per node. Agents were staggered, with one activation every 30 seconds during the first hour and one every three seconds thereafter. At 45 minutes before termination, workers were instructed to stop dispatching new features and focus on merging and ensuring that the build worked; at five minutes before termination, they received a final merge-and-build reminder.

## 6. Relation to social harnesses and system limitations

Agensh’s organizational infrastructure addresses decentralized task execution, but a separate line of analysis concerns the governance of interactions among independently owned agents. An agentic society consists of autonomous AI agents coordinating on behalf of different principals whose objectives may only partially align. In such settings, a personal harness manages private context, tools, memories, policies, and communication with a principal, whereas a social harness governs interactions with untrusted or partially trusted agents [2609.17527].

The social-harness analysis identifies five relevant layers:

1. **Unforgeable, verifiable identities**: Messages are signed, and agent identities are bound to principal identities. Authentication does not establish authorization, honesty, competence, or truthfulness.
2. **Reliable, ordered communication**: Collective operations such as `MULTICAST`, `GATHER`, `ALL-REDUCE`, and `ALL-TO-ALL` provide stronger communication semantics. Ordered delivery alone does not solve concurrent generation, turn-taking, or side effects.
3. **Personal firewalls**: Messages are checked structurally against schemas and protocols and semantically in quarantined contexts against policies, authority, trust relationships, and collaboration norms.
4. **Shared collaboration norms**: Typed contracts, distributed protocols, and potentially multiparty session types specify permitted messages, protocol states, quorum rules, deadlines, cancellation, rollback, and termination.
5. **Social institutions**: Immutable records, signed histories, monitoring, investigation, adjudication, revocable access, sanctions, and governance support accountability for harms that cannot be detected locally.

This framework is relevant to Agensh because the latter’s claims, messages, shared context, repository changes, and merge operations are all socially consequential coordination events. A plausible implication is that large-scale self-organization requires not only shared state and decentralized integration but also explicit identity, authority, provenance, protocol-state validation, privacy controls, and evidence trails when workers or principals are only partially trusted.

The empirical evaluation of Agensh has substantial limitations. It focuses on five difficult software-reconstruction tasks that are highly parallelizable and naturally support behavioral probing, modular implementation, source-code modification, branch-based integration, and automated testing. The supplied results do not establish whether the same gains transfer to research, planning, legal or medical reasoning, tightly coupled mathematical proofs, or tasks requiring a single globally coherent argument.

The study does not provide a conventional ablation table isolating the effects of shared context, direct messaging, decentralized control, prompt variants, models, activation schedules, workspace implementations, communication-disabled workers, node counts, or cost normalization. It also does not report messages per worker, coordination tokens, Git operations, conflict frequency, failed merges, duplicated work, infrastructure resource use, or monetary inference cost. Consequently, the results demonstrate performance under a fixed time budget rather than cost efficiency.

The supplied paper does not report a controlled comparison against a centralized orchestrator using the same model, worker count, time budget, infrastructure, tasks, and evaluation setup. It also does not specify independent-trial counts, random seeds, confidence intervals, variance, significance tests, or per-task distributions. The reliability of fine-grained differences, including the 4.12-point difference between 128 and 1,024 agents, therefore cannot be assessed from the reported information.

Agensh further relies on workers reading claims, communicating promptly, publishing useful findings, synchronizing before merges, and verifying their changes. Git detects textual conflicts, but semantic conflicts may remain undetected. Shared context can become noisy or stale, and workers may miss relevant entries or repeat failed approaches. These limitations leave open questions concerning convergence, coordination overhead, cost-optimal scale, cross-model robustness, domain transfer, and the formal properties of decentralized organizational protocols.

Source: https://www.emergentmind.com/topics/agensh