Four dimensions with two settings each is sixteen cells. The paper reports eighteen configurations [1][2][13]. So either one of those dimensions is not binary, or there are cells outside the factorial grid, and the front matter does not say which [13][15]. If you intend to reuse the harness rather than quote the headline, resolve that first, because the shape of the grid is the experiment.
The result I would act on soonest is the negative one. Across models, ReAct prompting inside multi-agent orchestration showed significant weakness, the authors report [5]. Function calling rides the provider's schema-constrained tool interface; ReAct puts the action into prose that your framework has to parse, and in a multi-agent setup that prose crosses a handoff before anything validates it. That explanation is mine, and this data does not test it. The paper's own related-work section points at earlier tool-calling benchmarks that already found weaknesses in tool selection accuracy, tool input accuracy, valid output formatting, latency and unnecessary calls [10]. That is the list I would instrument before blaming the orchestrator.
Then the ceiling. A 35.3% best score on the complex task means 64.7% of attempts did not succeed [3][11], and the simpler task landed at almost exactly double: 70.8 divided by 35.3 is 2.0 [12]. For either figure to describe your workload, you need the same definition of success, a tool inventory of similar size and shape, and tasks that run about as many steps. The supplied text gives none of those and does not name the models evaluated [15]. So read 35.3% as a measurement of two ServiceNow use cases under ServiceNow's own grader [7], and treat the shape of the finding, not the value, as the portable part. It is unusual for a vendor to publish a ceiling this low on the category it sells into.
Adopting the finding costs more than reading it. Eighteen configurations against two use cases is 36 graded runs per model [14], and the graded task set has to exist before any of them mean anything. The payoff is at the cheap end of the model list: larger models were more robust across architectures, but on the simpler task a smaller model under its best configuration matched them [6]. That is architecture search paying for itself in inference cost, on the easier class of task only.
The claim the paper makes against one-size-fits-all is narrower than it sounds, and stronger for it. Models did best under different architectures, and for a single model the best architecture changed between the two use cases [4]. That is not a statement about which framework to buy. It is a statement that your orchestration diagram is a per-model, per-workload result with a short shelf life, which is why the useful artifact here is the grid and the harness [1], run against tasks you graded yourself.
