Executive reading · ~60 seconds

A study of 354 tasks and 2,124 runs found benefits from dynamic concurrency mainly in long, decomposable work, but also token use 1.41 to 3.31 times higher and longer average time in 14 of 15 combinations. Parallel work needs a state contract, integration, budget, and acceptance.

Delegating to several agents looks like a direct way to finish sooner. In long engineering tasks, however, parallel work also creates queues, dependencies, overlapping context, state conflicts, and new integration work. The technical question is not how many agents fit in the flow, but when the work can be decomposed without losing global coherence.

Status: Evidence Brief approved for publication. Editorial series: Papers we read for you. This text analyzes the preprint *When Sub-Agents Work in Parallel* and its public artifacts. It does not claim that Trustyu Forge reproduced the experiments or that the results universally rank Codex, Claude Code, Kimi Code, or any future version of those products.

What was compared

The authors evaluated three coding agents with native dynamic-concurrency support: Codex, Claude Code, and Kimi Code. For each task, they compared two conditions: the agent could decide when to create sub-agents, or it had to run without parallel delegation. Model, prompt, environment, and time budget were kept equivalent within each pair.

The sample contains 354 tasks: 254 from four long-horizon benchmarks and 100 from SWE-bench Verified, used as a reference for more bounded work. Each task ran with all three agents under both conditions, totaling 2,124 executions. Telemetry recorded 11.2 billion tokens and an author-estimated cost of US$20,780.02 at the API prices used in the study.

More capacity did not produce uniform gains

In the reported aggregate, enabling dynamic concurrency changed resolution from an 11.9-percentage-point decline to a 2.3-point gain, depending on agent and dataset. Token use ranged from 1.41 to 3.31 times the sequential mode. Average time increased in 14 of the 15 agent–benchmark combinations.

The result was sensitive to the type of work. In LoopsBench, the study's longest-task dataset, Codex and Claude Code improved task passes by as much as 14.3 percentage points. On SWE-bench Verified, Claude Code fell from 83% to 59% and Kimi Code from 77% to 59%; Codex remained at 71% in both conditions. Parallelism helped when sufficient complementary work existed and hurt when coordination cost exceeded the opportunity for decomposition.

The bottleneck moves to integration

One trajectory in the paper illustrates the risk. The primary agent created 20 sub-agents to implement tool commands, waited for the entire batch, and failed to integrate and test what was already available before the time limit. The program compiled but passed only 92 of 440 tests because essential parts were not integrated.

Manual trajectory analysis produced four categories, 13 subcategories, and 28 failure patterns. The groups cover task orchestration, execution governance, global-context management, and shared state/merge. Inter-annotator agreement was reported with a Cohen's kappa of 0.77.

When concurrency tends to help

The paper identifies three benefit mechanisms: genuinely independent complementary work, exploration of alternative solutions, and validation separate from the primary work. This suggests a gate before spawning:

  1. Independence: does the subproblem have explicit inputs and output, and can it advance without editing the same state as other agents?
  2. Integration: is there an owner responsible for reconciling interfaces, conflicts, and side effects before acceptance?
  3. Budget: does delegation preserve enough time and tokens for integration, testing, and correction?
  4. Observability: can dependencies, waiting, touched files, and partial results be observed?
  5. Fallback: if a sub-agent is delayed or fails, can the primary agent use partial results or return to the sequential path?

Architecture rule

Concurrency is an execution policy, not a productivity guarantee. The harness should allow delegation only when the task declares state boundaries, a delivery contract, an integration budget, and an owner for global acceptance. Local sub-agent speed does not replace evidence that the integrated artifact satisfies the contract. [R2-C3]

In Forge, a multi-agent flow must record the decomposition plan, dependencies, supplied context, produced changes, conflicts, tests, and acceptance. The primary metric is not the number of busy agents; it is time and cost to an integrated, verifiable, and recoverable delivery.

Limits and conflicts of interest

The study is a v1 preprint dated October 7, 2026. The sample covers three agents, configurations selected in July 2026, and five benchmarks; it does not represent all tools, versions, languages, or orchestration approaches. Tasks were sampled by difficulty and, because of cost, each cell appears once in the main experiment, limiting variance estimates for stochastic systems.

The authors released trajectories and analysis artifacts, but by the editorial cutoff we had not found a complete independent replication. The authors report affiliations with Nanjing University, Central University of Finance and Economics, and the University of Illinois Urbana-Champaign; we found no declared commercial affiliations with the three evaluated providers. No identified conflict is not proof of absolute independence.

Direct sources

  1. When Sub-Agents Work in Parallel — arXiv. Preprint, authors, abstract, version, and date.
  2. When Sub-Agents Work in Parallel — full text. Method, denominators, results, taxonomy, and limitations.
  3. Concurrency Failures Trajectory Artifact — official repository. Trajectories and artifacts released by the authors.

Editorial and responsibility note

This text combines source-attributed facts with the author's analysis and technical proposal. Personal and professional views are not established facts; data, denominators, limitations, affiliations, and the absence of independent replication are stated when available. This content is informational and does not replace technical, legal, financial, or security assessment. Product names belong to their respective owners; there is no sponsorship or endorsement. Tech Human and Trustyu operate commercially in digital-product development and governance. Research, structure, and writing used AI assistance; factual review, author approval, and publication were authorized by Fernando Parreiras on October 8, 2026, without additional independent human review.

Research cutoff: October 8, 2026. Editorial status: special Evidence Brief authorized for October 13, 2026 at 9:00 AM BRT.

Editorial and responsibility note

Research cutoff
Last review
Recorded corrections
No corrections recorded.

The cutoff above applies to the canonical claims. Additional sources and their access dates are identified in the article body.

This article combines cited sources, analysis, and the author's professional experience. Verifiable data and factual statements are linked to their respective sources. Interpretations, hypotheses, projections, recommendations, and opinions represent the author's professional point of view at the time of publication; they do not constitute proven facts, a promise of results, or legal, financial, or technical advice applicable to a specific case. Consult the original sources and qualified professionals before making decisions.

Claims and sources

R2-C3

Least privilege, isolated execution and supply-chain provenance are complementary controls; no substitutes for the others in an agentic system.

Limit: The exact control profile remains environment-specific and must be threat-modeled per product. This is a research-synthesis design input; it does not prove product adoption, operational maturity, independent attestation or outcome.

  • OpenAI — OpenAI, Apache-2.0 repository; analysis-only excerpts
  • OWASP Foundation — OWASP Foundation, CC-BY-SA-4.0 standard; analysis-only excerpts
  • OpenSSF SLSA — OpenSSF SLSA, CC-BY-4.0 specification; analysis-only excerpts