POrchestra lets subagents ask for harness changes mid-run — Mid-run subagent harness requests vs fixed briefs — What does it mean?
The news. On October 9, 2026, researchers at Renmin University of China and collaborators posted Proactive Agentic Orchestration (arXiv 2610.13485), which introduces POrchestra. A subagent gets a structured way to request a harness change at any point in its run, and keeps its local history when the change is applied. On three long-horizon benchmarks — GAIA (deep research), GAIA2 (dynamic digital assistance) and SWE-Bench Verified (software engineering) — the paper reports an average 9.1% relative gain in task success over the strongest baseline. The code is public. Read the paper →
Picture a contractor sent to renovate one room. The foreman wrote the work order in the site office: what to build, a page of notes, which tools to bring, how many hours to spend. Partway through, the contractor opens a wall and finds the wiring is not where the plan says. In most agent systems the contractor has two options: keep working from a work order they now know is wrong, or stop and hand back whatever is half-done. Either way, the foreman learns about the wiring only when the contractor is back at the office.
That is how a typical orchestrator-workers setup treats a subagent. Its harness is fixed when the subagent is created. The orchestrator can change the plan only between subagents — after one submits a result or times out — and the paper notes that this also loses the subagent's ongoing execution state: the replacement starts from an empty context.
POrchestra adds the radio. Next to its normal tools, a subagent gets three communication actions: submit (done, here is the result), stop (abandon this path), and revise (pause and ask for a change). A revise message has three parts — status, request, and evidence — so the orchestrator can judge the request instead of trusting it blindly. The status says what is done and where the subagent is blocked. The request names what should change: the task scope (split or update the subgoal) or a resource (working context, tools, or step budget). The evidence carries the tool outputs that show the problem.
The orchestrator, which keeps the view of the whole task, then either revises the harness or ends the subagent. On a revise, the change is written into the subagent's own history as a new observation, and the same subagent resumes with every earlier step still in its context — the contractor stays in the room.
The paper's own example shows the shape. A GAIA question asks for the 2020 population estimate of Greenland as Wikipedia showed it on January 1, 2021. The subagent was given web search and a page reader. It used 26 steps searching and reading the current page, which lists only newer figures. At step 27 it sent a revise: status — the island is identified, the historical figure is not found; request — access to an older version of the page; evidence — the failed searches and the page reader's answer. The orchestrator kept the goal, added a code-execution tool, a short example of querying the MediaWiki revision API, and a 15-step budget, and the same subagent needed one more step: a code call that retrieved 56,081, which it rounded to 56,000 — graded correct. With a fixed brief, those 26 steps would have ended in a failure report, and a new subagent would have started from zero.
| Approach | When the harness can change | Who notices the mismatch | What happens to the subagent's work |
|---|---|---|---|
| Offline orchestration (e.g. AutoAgents, Skill-MAS) | Never, once the run starts | No one, during the run | Runs to the end on the original plan |
| Re-orchestration (e.g. AOrchestra, MAS2) | After a subagent returns, or when a preset trigger fires | The orchestrator, after the fact | Typically ended; the change goes to a new subagent with a fresh context |
| Proactive orchestration (POrchestra) | At any step the subagent chooses | The subagent, while working | Kept; the same subagent resumes with the change |
Why should the subagent, not the orchestrator, raise the problem? Because the mismatch shows up in local detail — a page that lists the wrong year, an email reply that changes the goal — and that detail lives in the subagent's context, which the orchestrator deliberately does not share. The design keeps context isolation and still lets the problem travel up, because the evidence field carries only the few tool outputs that justify the request. The paper's ablations on GAIA2 — runs that switch off one part at a time — support each part. Turning off any one kind of revision lowered success: task-scope changes mattered most (a 10.2-point drop), then context, tools and budget (7.8, 7.1 and 6.3 points). Removing the evidence field from the message hurt more than removing the status or the request.
The same messages also help train the orchestrator. Usually an orchestrator learns only from the final pass or fail, which arrives after many subagent runs and says little about which delegation was wrong. A revise request is a specific complaint about one earlier decision — "you did not give me a tool that can read old page versions" — so OPOD traces each request back to the decision it criticizes, writes it as a short natural-language correction, and uses the same model, shown that correction, as a teacher for the original decision. The final outcome reward stays in the training signal too. With this, the paper reports small orchestrators (Qwen3.5-9B) gaining 10.0% relative success over existing training methods.
Where the cost goes
Hold the setup fixed as the paper does for its cost table: Gemini-3-Flash as the orchestrator, DeepSeek-V3.2 as the subagent model, GAIA2 tasks, and cost in the paper's API credit unit (1 credit ≈ $0.14). The radio is not free: POrchestra spends 0.065 credits per task on revise messages and the replies to them — a real coordination cost. But routine orchestration falls from 0.208 to 0.097 credits, and subagent execution falls from 1.001 to 0.559. Total: 1.209 credits (about $0.17) for AOrchestra vs 0.721 credits (about $0.10) for POrchestra — roughly 40% lower per task, while average GAIA2 success with the same model rose from 39.8% to 47.7%. In this setup, the extra messages cost less than the subagent work they saved.
The gain is not uniform. It is largest where plans go stale during the run. On GAIA2's Adaptability tasks, where requirements change mid-task, success with DeepSeek-V3.2 went from 25.0% for AOrchestra to 43.8% for POrchestra. On GAIA Level 1, the easiest tier, POrchestra tied single-agent ReAct at 79.2% with the same model. A short task rarely runs long enough for its brief to go wrong, so the radio has little to report.
Goes deeper in: Agent Engineering → Agent Teams → Supervisor / Worker
Related explainers
- Forked vs isolated subagent context — what a subagent should start with; this article covers what it can ask for later.
- Explorer-subagent context offloading — what a subagent should send back when it finishes.
- Programmatic subagent fan-out — how an orchestrator creates many subagents in the first place.