AI Agent Arxiv Digest — 2026-09-01

🌏 中文版

Today's Overview

Today's three papers all answer the same question — how do you keep a multi-agent system under control — from different angles. K-GAT flips the logic of collaboration-topology generation: retrieved evidence, not a guess based on the question's wording, decides how many agents to instantiate and how they connect. DoCtOR argues that when a multi-agent system fails, you should not force every agent to reflect; you should first identify the one agent whose action actually derailed the task, and let only that agent reflect, so agents that behaved normally don't get their memory contaminated by a misguided self-critique. GOD takes a different tack entirely: instead of making agents smarter, it makes the operator able to see and steer what's happening — a control room that supports questions, interventions, and replay is a layer most simulation platforms currently lack. The first two papers come with full cross-dataset experiments and ablations; GOD is upfront that its own validation is demo-scale, so the three papers sit at different points on the evidence-maturity scale.

Terms Worth Knowing Before You Read

Paper 1 | K-GAT: Let Evidence Decide How Agents Divide the Work, Not the Other Way Around

When Evidence Shapes Collaboration: Knowledge-Conditioned Topology Generation for Multi-Agent Systems Yangxiao Jiang, Jiarun Fan, Mingcong Xu et al. (Huazhong University of Science and Technology) · arXiv: 2608.27984

Links: arXiv · alphaXiv

TL;DR

K-GAT generates multi-agent collaboration topology by conditioning on retrieved evidence rather than query semantics alone, beating the LLM-Debate baseline by 15.7 points on GPQA while using under half the compute tokens.

Editorial Judgment

Field Context

Dynamic MAS topology-generation methods have followed a "plan first, retrieve later" pipeline: the collaboration structure is decided from the question's semantics, with retrieval playing only a supporting role. But semantic complexity doesn't track actual evidence needs, producing two failure modes: over-planning and under-planning.

Mid-Level Walkthrough

• The problem: Imagine a knowledge-intensive QA system. A question that sounds semantically complex may retrieve evidence that is already sufficient and consistent, yet the system still spins up an elaborate debate workflow. Conversely, a semantically simple question may retrieve sparse or conflicting evidence, yet the system dispatches only a single agent to handle it.
• The method: K-GAT retrieves evidence first, then feeds that evidence plus its provenance into an autoregressive graph-generation model that decides which agent roles to instantiate and how to connect them. Training uses a curriculum: candidate topologies are drawn from templates, random DAGs, and the current generator's own samples, and the ones that both succeed on execution and stay structurally compact become the supervision signal.
• Why it matters: Collaboration architecture shouldn't be decided by how hard a question "sounds" — it should track how much evidence is actually available. That's a concrete design principle for any agent platform doing dynamic orchestration.

Deep-Dive Points

• On GPQA, K-GAT beats the LLM-Debate baseline by 15.7 percentage points while consuming under half the tokens
• At the 8B scale it reaches 78.68% average accuracy, competitive with much larger models like Qwen-3-32B and Llama-3.1-70B
• Ablation shows the curriculum-trained generator still reaches 72.38% average accuracy even without external knowledge at inference time — evidence that training internalizes collaboration behavior rather than simply parroting retrieval
• The KG-Verifier component pushes GPQA accuracy from 49.26% to 50.75%, showing that filtering hallucinated paths has a measurable effect
• Deployment bar: requires building an external knowledge graph up front (Wikipedia plus the StructSense pipeline here), adding preprocessing and storage cost compared with purely parametric reasoning
• Limitation: topology size is currently capped at 6 nodes, long-horizon reasoning is untested, and the method has not yet been extended to broader tool-use environments or dynamically evolving knowledge sources

Reviewer's One-Liner

Flipping "plan then retrieve" into "retrieve then plan," and using post-execution success as the supervision signal for topology learning, is a clean design with thorough ablations — but it's still confined to Wikipedia-grounded knowledge-intensive QA, and whether it transfers to live tool calls or dynamic knowledge sources remains to be seen.

Take-Aways for You

• If you're building dynamic agent orchestration: first determine whether your task varies by semantic complexity or by evidence density — the post-execution scoring-and-pruning pipeline here is directly reusable
• If you're evaluating MAS frameworks: add a closed-book vs. open-book control so you can tell whether a performance gain comes from evidence use or the model simply remembering more

Paper 2 | DoCtOR: When a Multi-Agent Team Fails, Only the Agent That Actually Caused It Should Reflect

Finding Where the Buck Stops: An Automated Failure Attribution-Based Reflection Framework for Multi-Agent Collaboration Xiaoqing Wang, Keman Huang, Bin Liang et al. (Renmin University of China; Ant Group) · arXiv: 2608.28264

Links: arXiv · alphaXiv

TL;DR

DoCtOR first automatically identifies the "decisive error agent" and lets only that agent reflect, improving initial success rates by 22%, 26%, and 27% on HotPotQA, ChartQAPro, and Mind2Web respectively, outperforming Reflexion, Retroformer, and COPPER.

Editorial Judgment

Field Context

Prior MAS self-reflection methods (e.g., COPPER) assume that when a task fails, every agent should reflect. In reality, failures usually trace back to one "decisive error agent" that derailed the task, while the others were just doing their normal jobs. Forcing normally-behaving agents to reflect stuffs a misguided self-critique into their memory, contaminating future performance.

Mid-Level Walkthrough

• The problem: Imagine a data-analysis task. Agent A correctly pulls the monthly sales figures, Agent B correctly draws the corresponding line chart, but Agent C misreads a minor fluctuation as a downward trend, leading Agent D to build a flawed strategy on top of it. Here C is the decisive error agent, while A and B were behaving normally — yet conventional methods would make A and B reflect too, leading them to second-guess choices that were actually correct.
• The method: DoCtOR works in three steps. First, ProFA — a diagnosis module trained in the spirit of a process reward model — scores each step in the trajectory to find the first failure step and its agent. Second, counterfactual reasoning generates what a corrected version of that step would have looked like. Finally, only the decisive error agent reflects, using both pieces of information, and the reflector model is further fine-tuned with PPO to sharpen quality.
• Why it matters: If the self-reflection mechanism itself is contaminating well-behaving agents, then adding more reflection can make the whole system worse. Separating diagnosis from correction avoids that side effect.

Deep-Dive Points

• On HotPotQA, ChartQAPro, and Mind2Web, DoCtOR improves initial success rates by 22%, 26%, and 27% respectively, outperforming Reflexion, Retroformer, and COPPER
• The ProFA diagnosis module improves agent-level accuracy by 4-35 percentage points and step-level accuracy by 9-28 percentage points over existing attribution methods on the Who & When dataset
• An additional experiment shows the "diagnose-then-correct" paradigm improves an existing prompt-based method (Reflexion) when grafted onto it — it isn't locked to DoCtOR's own architecture
• In low-resource settings, giving the reflector only the reasoning steps after the decisive error step achieves comparable reflection quality to giving it the full failure trajectory — meaning substantial context savings are possible
• Deployment bar: the action module runs on frozen GPT-4o-mini while the reflection module is a fine-tunable Llama-3.1-8B-Instruct — a "large model executes, small model reflects" split that's friendly to teams with limited compute
• ⚠️ Self-reported by the authors, not yet externally replicated: the diagnosis module needs a labeled decisive-error dataset for training, and whether its diagnostic accuracy holds up when transferred to new tasks or new failure modes remains to be tested

Reviewer's One-Liner

Splitting "everyone reflects" into "find the culprit, compute the counterfactual, only punish that one with reflection" is a clean idea backed by solid cross-dataset numbers; what's less explored is whether errors in the diagnosis module itself (misidentifying the decisive agent) could become a new systematic bias — the paper doesn't dig into that.

Take-Aways for You

• If you're doing self-reflection in a multi-agent pipeline: run failure attribution first, and reflect only the agent that actually caused the failure, so normally-behaving agents' memory doesn't get contaminated by a misguided critique
• If your compute is limited: consider the "large model executes, small model diagnoses and reflects" split, keeping fine-tuning cost confined to an 8B-scale reflection model

Paper 3 | GOD: A Real-Time Control Room for Agent Societies — Question, Intervene, and Replay in One Place

GOD: Govern, Observe, and Direct — A Real-Time Control Room for Agent Societies Yige Luo, Ran Guan (Huawei 2012 Laboratories) · arXiv: 2608.27992

Links: arXiv · alphaXiv

TL;DR

GOD is a local-first control room for agent societies that lets an operator question, intervene, and inspect replay state from a single browser workflow; across 14 intervention runs, 78 of 84 target-move checks recorded the commanded destination and 169 of 182 state-answer checks matched the replay record.

Editorial Judgment

Field Context

Generative-agent systems (like the Generative Agents virtual town) are typically "easy to start, hard to inspect" — an operator usually gets either a finished replay video or a raw log, making it hard to ask why an agent moved or run a small intervention experiment, and hard to package a single run's setup for someone else to reproduce.

Mid-Level Walkthrough

• The problem: You're running a 22-resident virtual-town simulation and one resident suddenly walks toward the library. You want to know why, and you'd like to try telling it "a volcano just erupted nearby" to see how it reacts — but current tools give you either a replay video or a raw log, not both in a way you can act on.
• The method: GOD puts operator commands and replay evidence into the same record schema. Ask (a read-only question that doesn't change world state) and Intervene (an injected instruction that affects the next step) are both stored with a timestamp inside the replay log, and the operator can pause, scrub, issue commands, and export a shareable pack from one browser view.
• Why it matters: GOD isn't proposing a new agent policy or memory architecture — it's tying "what the operator did" and "what the evidence shows" into the same record, so someone else can reproduce, inspect, or even rewrite the scenario you ran. That's a layer most agent-simulation tools currently lack.

Deep-Dive Points

• 78 of 84 target-move checks correctly recorded the commanded destination; all 6 misses came from the gymnasium scenario, where the pathfinder reported the destination as unreachable
• 169 of 182 state-answer checks matched a saved location or action string in the replay; of the event-boundary checks, all 70 "should not know yet" pre-event checks passed, and 74 of 112 "should mention it" post-event checks passed
• The authors candidly document a debugging episode: the Chinese-language command parser initially misrouted the trigger word for "arrive" into unrelated compounds meaning "receive" or "visit"; after the fix, the six affected runs were rerun to get the reported 14/14 routing result — the paper explicitly labels this a post-fix regression check, not a general claim about routing capability
• The mean pairwise Jensen-Shannon divergence of final agent-location distributions across four repeated scenario pairs is only 0.011, suggesting fairly consistent outcomes on rerun — but the authors themselves note that four repeats "do not establish deterministic behavior"
• Deployment bar: requires connecting your own language-model endpoint (DashScope's Qwen-Plus in the example); the platform is local-first, and API keys, logs, and replay databases are never bundled into a shared pack
• ⚠️ Conditional pass, self-reported: only one model configuration was tested, and the denominators come from the same 22 fictional profiles reused across scenarios rather than independent samples; no operator-usability study was conducted

Reviewer's One-Liner

What's most admirable here is the honesty — even the bug-fix episode and the statistical limits of reusing the same profile set across scenarios are written into the body, rather than dressing up a demo as a rigorous benchmark; but the current validation scale is really only enough to prove "the interface records things and they match the replay," far short of proving "this control room improves research productivity."

Take-Aways for You

• If you're building a multi-agent simulation platform: binding operator commands (questions/interventions) to replay evidence in a single record schema is a step most tools lack today, and it's not expensive to implement
• If you want to use a tool like this for research: understand the scale of the demo's validation first, and treat it as an interface-design reference rather than evidence that the agents' behavior has been validated as sound

Today's Takeaway

Today's three papers together make one point: multi-agent system quality isn't just about how capable the model is — it's about how collaboration is designed and how it's made visible. Topology should be decided by evidence, not a semantic guess. Reflection should target the actual culprit, not implicate the whole team. And operators should have a tool to intervene and replay in real time, rather than waiting for a run to finish and being handed a log they can't parse.

References

• Jiang et al., When Evidence Shapes Collaboration: Knowledge-Conditioned Topology Generation for Multi-Agent Systems: arXiv 2608.27984
• Wang et al., Finding Where the Buck Stops: An Automated Failure Attribution-Based Reflection Framework for Multi-Agent Collaboration: arXiv 2608.28264
• Luo & Guan, GOD: Govern, Observe, and Direct — A Real-Time Control Room for Agent Societies: arXiv 2608.27992, GitHub repository, hosted replay
• arXiv official announcement schedule: Submission Schedule and Cutoff Time