Target: HexAGenT (2605.16637), workflow- & heterogeneity-aware agentic LLM
serving scheduler on P-D disaggregated heterogeneous clusters.
Synthesized against 8 related category: agent entities.
The 8 peers split into three concentric rings around HexAGenT.
*Ring A — direct competitors in agentic serving scheduling*** (same problem, overlapping baselines):
Autellix-ATLAS). Autellix elevates OS Least-Attained-Service to program level (PLAS/ATLAS), scheduling online-revealed DAGs non-clairvoyantly for throughput [2502.13965]. HexAGenT explicitly frames ATLAS as insufficient because attained service ≠ risk of exceeding a workflow-specific horizon [2605.16637].[li2025continuum], a program-aware peer. Continuum keeps KV cache resident across tool calls via cost-benefit TTL + program-level FCFS, targeting per-turn queueing bubbles [2511.02230]. It also uses Autellix (PLAS) as a baseline, making all three a coherent lineage.Ring B — orthogonal serving optimizations that HexAGenT could compose with, not compete against:
Ring C — adjacent framing, different mechanism:
Genuinely new in HexAGenT:
Incremental (well-precedented) elements:
Contradictory / tension with peers:
HexAGenT's implicit premise — that scheduling GPU-side LLM calls is where workflow latency is won — is directly contradicted by CPU-Centric (2511.00739): if CPU tool execution is 82–88% of E2E latency [2511.00739], then even a perfect P-D scheduler caps E2E improvement at the residual GPU fraction.
矛盾根源: different workload composition and instrumentation boundary. HexAGenT models tool calls as opaque DAG edges and measures only the LLM-call portion via a roofline simulator [2605.16637], so tool time never enters its horizon $H_w$. CPU-Centric measures the full E2E wall-clock including tool CPU time [2511.00739]. Both are internally correct: HexAGenT optimizes the LLM-serving sub-problem, but its "workflow-level latency" claim is only workflow-level within the serving cluster, not agent-level end-to-end. They are not comparable head-to-head without normalizing what "E2E" includes.
Attack 1 — "Users experience end-to-end workflow latency" but the horizon $H_w$ excludes tool time.
HexAGenT's foundational claim is that the workflow, not the call, is the unit users feel [2605.16637]. Yet $H_w$ is the standalone completion time of LLM calls on the serving cluster [2605.16637] — tool/CPU latency is not in it. CPU-Centric shows tool execution can be 88% of true E2E [2511.00739]. So HexAGenT optimizes a proxy that may correlate weakly with what users actually experience for tool-heavy workflows (BFCL). The 5.7% Req95 gain on Qwen-BFCL [2605.16637] is consistent with this: the tool-heavy trace is where HexAGenT helps least.
Attack 2 — No formal guarantees for a greedy online scheduler, and a known baseline says the gap to optimal is real.
HexAGenT provides zero competitive-ratio or regret bound for its argmax-$R_s$ greedy [2605.16637]. Autellix's Figure 18 quantifies a visible gap between non-clairvoyant scheduling and clairvoyant SRPT [2502.13965]. HexAGenT never compares against any optimal/clairvoyant oracle, so we cannot tell whether its 13–24% average reduction is near the achievable ceiling or leaving large gains on the table.
Attack 3 — Headline number inconsistency.
The abstract advertises avg 20.1%/33.0% (max 45.0%/80.5%) reductions [2605.16637] but §7.4's four-trace averages are 13.0%/24.5%. The 80.5% max is not locatable in any reported table. This aggregation opacity would not survive the reproducibility standard Continuum sets with a public repo + real testbed [2511.02230].
Attack 4 — Robustness table anomalies undercut the "robust to estimation error" claim.
Qwen Req99 degradation is non-monotonic (9.5% at 10% error > 5.4% at 30%) and several entries are negative [2605.16637]. The authors dismiss these as near-ties, but non-monotonic degradation suggests the greedy ordering is sensitive to estimate structure in ways the paper does not characterize — a fragility Continuum's $\eta$-parameterized cost model would at least expose analytically [2511.02230].
Attack 5 — Closed-world workflow assumption.
HexAGenT assumes tool returns and branch reveals are captured by DAG edges with estimable timings. Speculative Tool Calls shows tool latency is often the dominant, high-variance term and can be hidden rather than scheduled around [2512.15834]. HexAGenT's decode-anchored placement locks the decode instance before prefill completes [2605.16637]; if a speculative-execution layer changed the reveal timing, those pre-commitments could become stale.
HexAGenT sits at the convergence of two established lineages: (a) program/workflow-aware scheduling (Autellix → Continuum → HexAGenT) and (b) P-D-disaggregated heterogeneous serving (DistServe/Splitwise/HexGen, cited as its own predecessors). Its niche is the product of the two — it is the first in this cluster to treat heterogeneous prefill/decode placement as a decision variable inside a workflow-aware scheduler [2605.16637].
This is an incremental-synthesis move, not a paradigm shift. The paradigm shift ("the scheduling unit is the workflow, not the call") was already made by Autellix [2502.13965]; HexAGenT's own characterization concedes this by deriving most of its Insight-1 gains from plain Workflow-FCFS [2605.16637]. HexAGenT's marginal contribution is the heterogeneity axis on top.
Adoption evidence is weak. Implementation is closed ([实现未公开], [2605.16637]), unlike Continuum's public vllm-continuum repo and real Company-A testbed [2511.02230] and RouteLLM's open framework [2406.18665]. HexAGenT's evidence is entirely simulator-driven (~4.6K-LoC Python event simulator with roofline latencies), whereas Autellix, Continuum, and TokenCake all report real GPU measurements. In the cluster's reproducibility ranking, HexAGenT is currently at the bottom.
Where it wins its niche: heterogeneous fleets (mixed A100/H100/H200) that reuse existing accelerators — a real production reality the other four schedulers ignore. That is a defensible, if narrow, ecological position.