3. Agent system architecture and operations
Anthropic used about 950 parallel agents to search for a new biological system
What happened. Anthropic opened a life-sciences research group and lab and described one of its first experiments: Claude agents searched for unusual reverse transcriptase systems in large DNA databases. Given a high-level human prompt, the agents assembled protein families, analyzed genomic neighborhoods, filtered candidates, and wrote human-readable reports. As a result, a previously uncharacterized system, named array-associated reverse transcriptases (ART), with a repeat array resembling CRISPR, was discovered.
Why it matters. This is a rare example where massive multi-agent fan-out leads not to a benchmark score, but to a new scientific hypothesis that can then be tested with a physical experiment. The architecture is well-suited for embarrassingly parallel search: hundreds of agents explore different branches, and expensive human verification remains for the final candidates.
What the data showed. Approximately 950 agents worked for 21 hours and used 210 million tokens. They collected over 200,000 RTs, identified 3,500 new candidate systems, and narrowed them down to 20 reports for human review. Early lab data shows that the ART repeat array is expressed as a set of short RNAs, but ART's function is still unknown. All wet-lab experiments are performed by humans; Anthropic explicitly calls the result preliminary.
What you need to understand now: multi-agent fan-out, genome mining, hypothesis triage, wet-lab validation, human verifier.
What this could change. For R&D workflows, it makes sense to look for tasks where cheap parallel exploration of the hypothesis space can be separated from expensive physical or expert verification. The metric here is not the number of agent outputs, but the cost of one candidate passing independent verification.
Date: September 23.
Primary source: https://www.anthropic.com/news/claude-discovers-novel-enzyme-system
Grow the Harness, Not the Context: repetitive reasoning can be turned into executable control logic
What happened. Researchers proposed Growing Harness: an agent starts with an almost strategy-free scaffold, and failures are localized via execution traces and used for small edits to executable harness code. A new version is accepted only if a held-out regression gate does not break previously successful capabilities.
Why it matters. Most agents repeatedly spend tokens on the same control decisions: how to search, in what order to call tools, when to retry. This work proposes moving stable decisions from the prompt/context into code, leaving task-specific semantic reasoning to the LLM.
What the data showed. On BrowseComp-Plus and WebArena-Verified with deployment models from 4B to 120B, Growing Harness achieved a better mean success rate in 5 out of 6 model/benchmark combinations, and in the sixth one, it was behind by 0.7 percentage points. Compared to a regular Tool-Calling agent, the number of LLM calls decreased by 76.0–91.8%, and inference cost by 74.4–98.6%. On WebArena-Verified, success remained at 44.7–45.3% across different model sizes, whereas the Tool-Calling baseline dropped to 6.7% on the 4B model. This is a preprint, not peer-reviewed.
What you need to understand now: agent harness, execution trace, failure-guided repair, held-out regression gate, WebArena.
What this could change. If an agent repeatedly solves the same control problems, it's worth looking for which decisions can be moved into deterministic/reusable code. This can reduce costs more than switching to a cheaper model.
Date: September 22; a fresh research release of the current window.
Primary source: https://arxiv.org/abs/2609.26760
Agensh: the number of agents becomes a separate scaling axis — up to 1,024 workers
What happened. Agensh removes the central orchestrator. Workers asynchronously read a shared workspace, claim subtasks themselves, exchange findings, verify results, and merge progress. Shared context stores reusable findings and intentions.
Why it matters. The central planner can itself become a bottleneck with large fan-out. Decentralized coordination offers scaling wall-clock intelligence by the number of parallel workers, not just by model or context length.
What the data showed. On the five hardest ProgramBench tasks with GPT-5.6 Sol (high), scaling from 1 to 128 agents increased the mean final test-pass rate from 19.31% to 28.78% — about +49% relative. On the pandoc task, scaling from 1 to 1,024 agents raised the final pass rate from 33.89% to 55.06%. A significant limitation: only five tasks and one model family; paper is a preprint.
What you need to understand now: decentralized orchestration, asynchronous workers, shared workspace, fan-out, ProgramBench.
What this could change. Multi-agent scaling is worth testing only on tasks that can truly be decomposed. Besides quality, you need to count wall-clock time, duplicate work, conflicts, token spend, and merge overhead.
Date: September 22; a fresh research release of the current window.
Primary source: https://arxiv.org/abs/2609.26781
CliffCompaction: context management becomes an algorithm, not just a summary prompt
What happened. CliffCompaction proposes autocompaction for long-horizon coding agents: the system only deletes or truncates old content, does not rephrase it, and never compacts already compacted output. The goal is to reduce the accumulation of context drift between sessions.
Why it matters. Long-running agent work often hits a limit not in the maximum context window, but in the cost of repeatedly recounting history and summary errors. The compaction policy becomes an independent quality/cost layer.
What the data showed. The authors report up to a 50% cost reduction with limited context without degradation on Terminal-Bench; cheaper rollouts allowed achieving over +10 percentage points on Terminal-Bench for less than the cost of two full-context runs. In parallel test-time scaling, Kimi K2.6 with CliffCompaction in the authors' experiments matched Opus 4.7 and outperformed Opus 4.6/GPT-5.3 Codex at lower cost. On KernelBench, kernel speedup increased to 2.23× after 200 steps and 3.58× after 400. This is a preprint; comparisons depend on harness and pricing assumptions.
What you need to understand now: context compaction, context drift, test-time scaling, Terminal-Bench, state persistence.
What this could change. If a coding agent regularly crosses multiple context windows, benchmark compaction strategy separately from the model. Critical state is better stored structurally outside of free-form conversation summaries.
Date: September 22; a fresh research release of the current window.
Primary source: https://arxiv.org/abs/2609.26779
A tool-use benchmark can measure the serving stack, not the model
What happened. The paper Measuring the Serving Stack Instead of the Model shows that the same model/tool schema behaves differently in Ollama, llama.cpp, vLLM, and SGLang. Some stacks return native tool_calls, some return text, and some models in certain configurations are rejected even before inference.
Why it matters. If a harness does not distinguish between "model didn't call a tool," "server rejected the request," "parser broke," and "retry exhausted," a leaderboard may attribute an infrastructure error to the model. For open/local models, serving configuration is part of the evaluated system.
What the data showed. The authors show that constrained decoding can eliminate parse failures but cause non-termination; turn-pooled and per-instance evaluations in their experiments diverged by up to approximately 55 percentage points. In one harness, server rejection and retry exhaustion could erroneously turn into an apparent 0% model fidelity. This is a preprint.
What you need to understand now: tool-call protocol, serving stack, constrained decoding, structured failure metadata, evaluation confound.
What this could change. In internal evals, fix the version/configuration of the serving layer, tool protocol, and failure taxonomy. For self-hosted models, it's useful to run the same model through several serving stacks before concluding about its tool-use quality.
Date: September 22; a fresh research release of the current window.
Primary source: https://arxiv.org/abs/2609.26693
