# A second agent should earn the handoff.

Five changes worth reading before you add workers, train memory, or spread an agent across local and cloud machines.

Published: 2026-10-23 | Updated: 2026-10-23
Author: /init editorial
Method: AI-assisted, source-checked
Canonical: https://init.news/notes/agent-systems-brief-2026-10-23/
For: Technical founders, practical AI builders, and owner-operators deciding where another agent, memory layer, or local runtime change is actually justified.
Question: sub agent delegation evaluation benchmark

## The answer

Keep a single-agent baseline and make every handoff justify itself. This week’s strongest evaluation measures whether delegation was needed, whether the right specialist acted, and whether success, steps and cost improved together. New memory work trains search, writing, skipping and stopping as one traceable policy; new deployment research makes model and agent placement explicit. Local runtime releases add concrete parser, template and terminal-error checks. These are author or vendor claims until reproduced in your workload.

## What you will leave with

A ranked 16–23 October research brief with exact sections and artifacts, implementation decisions, evidence limits, and a small delegation contract to try.

- Compare delegation with the same task completed by one agent; worker count is not the control variable that matters most.
- Instrument memory as a sequence of search, add, skip and stop decisions before considering policy training.
- Record runtime contracts and device, edge and cloud placement explicitly; local is a topology, not a quality claim.

## 1. Score the handoff and the outcome separately

16 October 2026 · preprint and code · MS-Eval. Earlier evaluations commonly measured task completion without a controlled single-agent comparison or a direct account of delegation quality. MS-Eval adds MCP-intensive tasks, a shared harness, labels for when delegation is appropriate, sub-agent hit scores, and utilities for performance, critical steps and economic cost. Its combined MSQ index is one proposed summary, not a universal standard. [1] [2]

The authors report that specialist profiles outperformed general or plan-first practical variants. Across their full benchmark, multi-agent execution usually cost more; unnecessary, unverified or redundant delegation became overhead. Read Sections 4.1–4.3 for the kit, Section 6 for variant results, Section 7 and Appendix C for beneficial and adverse cases, and the public repository for task and harness artifacts. The benchmark was not reproduced for this edition. [1] [2]

Decision: preserve a single-agent baseline and measure two questions independently: was a handoff appropriate, and did the complete run improve? Do not turn the paper’s model ordering or costs into a buying rule; they depend on the paper’s tasks, harness and October pricing assumptions.

## 2. Treat the local runtime as a versioned conversation contract

18 and 22 October 2026 · project releases · Ollama 0.40.7 and 0.40.9. Version 0.40.7 fixes misordered or duplicate streamed tool-call events and exposes renderer, parser and template_source through ollama show and the API. Version 0.40.9 makes generation failures visible in streamed OpenAI Responses and Anthropic Messages instead of silently ending after partial output. [3] [4]

Decision: pin the runtime version with the model artifact, parser, renderer and template source. Replay one sanitized multi-turn tool conversation and require a valid terminal state. Preserve partial output, but do not count a closed stream as success without checking for an error. These are shipped project release notes, not a local compatibility test; the same replay is still needed for MLX-LM, LM Studio and exo. [3] [4]

## 3. Train the memory process only after you can inspect it

15 October, revised 16 October 2026 · preprint · All-in-One Memory. Previous reinforcement-learning approaches often optimized retrieval and memory construction separately. AiO-Mem puts search, add, skip and stop actions into one source-linked evidence state, trains a trajectory-conditioned process reward model, and uses an action-balanced policy objective. [5]

The authors report the strongest overall results among their listed baselines on LoCoMo, MemoryAgentBench and PersonaMem. Their LoCoMo ablations assign the largest reported drop to removing working-memory construction. Read Sections 3.2–3.5 for the event bank, transitions, rewards and PA-DAPO; Tables 1–2 for results and ablations; Appendix G for prompts and tool calls. The paper says code will be released, so the implementation was not available here to reproduce. [5]

Decision: for an ordinary product, first log the evidence retrieved, the note written or skipped, the stopping decision and the answer support. Consider policy training only when you have reliable tasks, reward signals and privacy controls. The paper itself warns that source-linked histories may contain sensitive or inaccurate information and calls for consent, access, retention, deletion and correction safeguards in real deployments. [5]

## 4. Learned self-orchestration is a training method, not a default router

15 October, revised 19 October 2026 · preprint · Learning Self-Orchestration in Decentralized Agent Swarms. The method removes a central coordinator: agents bid for the next turn, and the bid also controls how later reward is passed back through prior participation. Ablations on the Iron Pickaxe task attribute gains to both learned action and learned bidding policies. [6]

Decision: this is relevant when you are training a swarm and can supply dependable task rewards plus counterfactual rollouts. It is not a drop-in replacement for a deterministic router. Read Sections 2.1–2.3 for bidding and credit assignment, Section 3.3.4 for ablations, Section 3.4 for reuse and dropout tests, and Appendix D before considering real-world use. The authors have not evaluated subjective outcomes and call irreversible interactions an open problem. [6]

## 5. Place each role before you call the system local

20 October 2026 · systematic mapping study · multi-agent LLMs across cloud, edge and IoT. The study maps 45 primary studies into architecture and deployment patterns rather than pooling incomparable benchmark numbers. Twenty-nine studies used physical hardware, while only six released code or data and only two directly measured privacy despite privacy motivating many local designs. [7] [8]

Decision: write down where the planner, specialist models, tools, memory, policy gates and fallback run. Then record hardware, network, workload, latency, quality, cost, privacy and failure behavior for that topology. Read Sections 4–6 for the classifications, Table 9 for constraint-led placement guidance, Section 7 for the reporting checklist, and the replication archive for the coded study records. This is a map of reported practice, not evidence that one architecture wins.

[7] [8]

## A small delegation contract for the next test

Contract field | Write before the run | Inspect afterward
--- | --- | ---
Need | The stage that exceeds one agent’s context, skill, latency or permission boundary. | Whether the handoff addressed that stage rather than creating parallel noise.
Specialist | One narrow role, permitted tools, expected output and stop condition. | Whether the selected worker produced a usable result within scope.
Baseline | The same task, inputs and acceptance rule completed by one agent. | Success, critical steps, total cost, elapsed time and human review for both paths.
Receipt | Sources, tool results, state changes, error classes and the return format. | Whether the main agent could verify, continue or retry without reconstructing hidden work.
Fallback | What happens when a worker fails, disconnects, disagrees or exceeds budget. | Recovery effort, duplicated actions and any unsafe or irreversible side effect.

For an owner wearing several hats, the best outcome may still be a clearer checklist or one reliable assistant. Use another agent when the recorded bottleneck calls for a separate context or capability and the return can be checked. Include setup, review, correction and maintenance in the decision. No workflow test or savings claim was performed for this edition.

## Apple Silicon and local-model applicability

The Ollama changes are directly relevant to Apple Silicon operators using that runtime, but they do not establish behavior in MLX-LM, LM Studio or exo. The cloud-edge map is more useful as a placement checklist than a hardware recommendation: a local model may still call remote tools, use cloud memory or escalate tasks. No Mac, distributed cluster, throughput, memory-capacity or energy test was run here.

## Window, exclusions and evidence limits

Reviewed 16–23 October 2026, following the prior successful systems edition. Four papers are fresh author-reported research; one is a systematic map rather than a performance experiment. Ollama release notes describe shipped project behavior, but no local replay was executed. No new MCP specification change with a stronger implementation consequence was found in the window, so older registry and reference-server material was not recycled as news.

Public search informed the question; owned traffic, customer demand, citation share and business uplift remain unknown.

## Try one thing

Choose one permitted task that sometimes needs delegation. Save a single-agent run, define the specialist’s narrow role, and compare success, critical steps, total cost, review time and failed handoffs across five matched attempts.

## Sources

[1] [MS-Eval: Benchmarking Sub-Agent Delegation and Orchestration in MCP-Intensive Working Scenarios](https://arxiv.org/html/2610.22869v1) — [1] 16 October v1; Sections 4, 6–7 and Appendix C; harness, delegation metrics, single-agent comparison, results, case taxonomy and limits. Author-reported results not reproduced here.; checked 2026-10-23

[2] [LINs-lab/MS-Eval](https://github.com/LINs-lab/MS-Eval) — [2] Public benchmark and harness repository linked by the paper; implementation artifact inspected as a reading target, not executed.; checked 2026-10-23

[3] [Ollama v0.40.7 release notes](https://github.com/ollama/ollama/releases/tag/v0.40.7) — [3] 18 October release: streaming tool-call ordering fixes and renderer, parser and template_source inspection fields.; checked 2026-10-23

[4] [Ollama v0.40.9 release notes](https://github.com/ollama/ollama/releases/tag/v0.40.9) — [4] 22 October release: generation failures surface in streamed OpenAI Responses and Anthropic Messages instead of silent partial completion.; checked 2026-10-23

[5] [All-in-One Memory: Process-Rewarded Reinforcement Learning for Memory Agents](https://arxiv.org/html/2610.21147v2) — [5] 15 October v1, 16 October v2; Sections 3–4, Tables 1–2, reproducibility and impact statements; shared evidence state, process rewards, reported results and deployment cautions.; checked 2026-10-23

[6] [Learning Self-Orchestration in Decentralized Agent Swarms](https://arxiv.org/html/2610.22322v2) — [6] 15 October v1, 19 October v2; Sections 2–3 and Appendix D; bidding, credit assignment, ablations, robustness and limitations. Author-reported results not reproduced here.; checked 2026-10-23

[7] [Multi-agent LLMs on the Cloud-Edge-IoT Continuum](https://arxiv.org/html/2610.28702v1) — [7] 20 October v1; Sections 4–7 and Table 9; mapping of 45 studies, placement guidance, comparability limits and reporting checklist.; checked 2026-10-23

[8] [Cloud-edge-IoT multi-agent mapping replication archive](https://doi.org/10.5281/zenodo.20631424) — [8] Public replication archive linked by the study for its protocol, screening log and coded data.; checked 2026-10-23

## Related guides

- https://init.news/notes/agent-systems-brief-2026-10-16/
- https://init.news/notes/apple-silicon-inference-evaluation/
- https://init.news/notes/memory-provenance-invalidation/
- https://init.news/notes/agent-handoff-receipts/
