Imagine a restaurant kitchen with no head chef. Every cook walks in, looks at the tickets on the board, claims one, cooks it, plates it, and pins notes for the next cook about what's already prepped. Nobody assigns stations — the kitchen self-organizes around a shared ticket rail, a whiteboard of prep notes, and shouted updates. That's Agensh. The paper's committed claim: you can remove the central orchestrator from a multi-agent LLM system, replace it with a shared workspace and asynchronous cooperation loop, and scale to 1,024 concurrent agents without hitting a coordination bottleneck. The agents continuously gather context, claim sub-tasks, act, share findings, verify results, and merge progress — no dispatcher required. The architecture is simple and deliberate. Three infrastructure components do the work a central orchestrator used to do: a shared workspace (proposed/ongoing/completed task board), a message interface (inter-agent communication), and shared context (reusable findings and declared intentions). Each worker runs the same cooperation loop independently. This is a decentralized coordination pattern — closer to a Git repo with pull-request semantics than to a traditional manager-worker queue. The key design bet is that LLM agents are smart enough to self-assign non-overlapping work if you give them the right read/write primitives. The evaluation uses the five hardest tasks from ProgramBench, run with GPT-5.6-sol (high). Scaling from 1 to 128 agents on the full benchmark raises mean final test-pass rate from 19.31% to 28.78% — a 49% relative improvement. The standout result is pandoc: 1 agent gets 33.89%, 1,024 agents get 55.06%, a 62% relative gain. Larger organizations also reach comparable pass rates earlier, which matters under time budgets. The paper reports that self-organized cooperation patterns — division of labor, specialization, emergent norms — gradually appear and stabilize as the organization grows. But look at the absolute numbers. The best result on the hardest tasks is still 55% test-pass rate. The 49% relative gain sounds impressive until you note it's a 9.5 percentage-point absolute lift across 128× more agents. The scaling curve is clearly sublinear and appears to plateau. This is useful — you're buying latency reduction and marginal quality improvement — but it's not a phase transition. The paper is honest about this, presenting scaling as a new dimension rather than a solved problem. The integrity picture is mixed. ProgramBench is a recognized benchmark, not a custom evaluation set, which is good. But the entire evaluation uses a single model family (GPT-5.6-sol), a single benchmark suite (5 tasks), and no comparison against other multi-agent orchestration frameworks like AutoGen, CrewAI, or MetaGPT. The paper doesn't compare Agensh's self-organized approach against a well-tuned central orchestrator at the same agent count — which is the comparison that would actually prove the architectural thesis. Without that head-to-head, we can't distinguish 'decentralization is better' from 'more agents help regardless of coordination strategy.' The milestone question is where agent-count scaling gets interesting. If 1,024 agents at 55% on pandoc is the current mark, the natural next target is breaking 80% on ProgramBench-hard with N agents — the point where these systems become genuinely reliable for complex software engineering tasks. The paper doesn't estimate how many agents that would take, and the sublinear scaling curve suggests it may require qualitative improvements (better cooperation protocols, learned role assignment) rather than just more bodies. The obvious experiment the authors didn't run: a controlled comparison of Agensh against a strong centralized orchestrator (say, a well-prompted dispatcher assigning tasks to the same GPT-5.6-sol agents) at 128 and 1,024 agents. This is the experiment that would validate the core architectural claim. My read: they likely ran informal comparisons and found the gap smaller than the self-organization story suggests, or the central orchestrator hits API rate limits at 1,024 agents and the comparison becomes unfair. Either way, it's the missing piece.
