Benchmarking System Configurations for Rubric-Constrained Personalized Exercise Planning

1. Introduction

Consumer wearables already feed cloud decision services; the open question is how sensing-derived physiological streams should drive personalized workout planning. Modern fitness wearables—smartwatches, chest straps, and continuous glucose monitors—record physiological signals around the clock. After a typical training week, a single user logs dozens of data points per day: resting heart rate, heart-rate variability (HRV), nightly sleep duration, and manually logged session loads. Turning that record into tomorrow’s workout is hard. The series is non-stationary: the same absolute load that builds fitness in week one may raise load-management risk in week three. Signals also interact, and the prescription has to be issued daily from noisy, incomplete inputs.

Rigid computational schedulers and flexible generative models pull in opposite directions. Rule-based schedulers handle arithmetic exactly but cannot adapt recommendations to unstructured user context, such as subjective soreness notes or training goals written in natural language. Large Language Models (LLMs) handle that language well but fail often on deterministic arithmetic [4,5]. In a health-adjacent setting, an arithmetic error in load calculation feeds straight into the exercise prescription—a dangerous failure mode. Published systems sit at the poles. Fine-tuned models such as PH-LLM produce fluent coaching copy but show weak numerical grounding under rolling-load constraints [1]. Single-agent tool-use systems can ground individual calculations yet often miss the cross-disciplinary synthesis needed to reconcile load history with injury restrictions. Multi-agent pipelines try to close that gap, but they still hand critical load arithmetic to agent roles and remain open to model-induced drift [3].

We report a matched four-way evaluation of system configurations for daily workout generation: a Baseline-LLM control (raw clinician chart, no precompute), a monolithic Single Agent (with Sports Data Scientist / Movement Planner (SDS/MP) summaries), a LangGraph Multi-Agent framework, and a ReAct tool-using agent. All arms share gemini-2.5-pro at temperature 0.2 and a common deterministic post-processing gatekeeper; the experimental contrast is orchestration, tool access, and precompute injection. On $N=50$ matched user-days scored by a four-judge LLM-as-a-Judge panel across eight rubric criteria, we test whether scaffolded designs beat a raw-chart LLM and whether added orchestration raises aggregate rubric scores beyond deterministic preprocessing.

The working hypothesis is that deterministic SDS/MP kernels raise same-model rubric compliance relative to a raw-chart Baseline, while extra orchestration among scaffolded arms may not lift aggregate scores once precompute and post-processing are matched—a “kernels compute, models decide” claim tested in Section 4.

2. Related Work

2.1. LLM-Based Health and Fitness Assistants

Work on AI health and fitness planning includes fine-tuned monolithic systems, retrieval-augmented generation (RAG) chatbots, and multi-agent pipelines [1,2]. PH-LLM [1] is fine-tuned on wearable summaries and produces fluent coaching language, yet numerical reasoning often slips under rolling-load constraints. A ReAct-style agent [6] with tools over daily physiological data improves numerical grounding but can still miss cross-disciplinary synthesis [2]. PHA [3] assigns specialized domain-expert agents to tighten plan coherence. We are not aware of a prior study that benchmarks these architectural families head-to-head on one structured safety checklist with real longitudinal wearable data.

2.2. Tool-Augmented and Multi-Agent Orchestration

Tool use as a way to ground LLM reasoning is well studied in Toolformer [7] and ReAct [6]. Multi-agent orchestration has also been used in software engineering [8] and in other planning tasks. In health settings, multidisciplinary care teams [9] motivate splitting work across specialized agents. Earlier alignment methods use self-refinement [10] or Constitutional AI [11]. Here we ask how well different orchestration strategies follow sport-science priors and field-coherence checks on real wearable traces.

2.3. Exercise Load Monitoring and Checklist Constraints

Generated fitness routines have to be checked against known physiological constraints. Acute Training Load (ATL), Chronic Training Load (CTL), Acute:Chronic Workload Ratio (ACWR), and Training Stress Balance (TSB) are standard proxies for readiness and load progression [12,13]. Heart Rate Variability (HRV) and resting heart rate add recovery signal [13]. This benchmark asks how reliably each architecture tracks and computes those multi-day recovery metrics without model-induced arithmetic drift.

2.4. Automated Evaluation of AI-Generated Plans

Open-ended generative output in health-adjacent work is hard to score: BLEU and ROUGE do not measure checklist compliance, physiological coherence, or plan reasoning quality [16]. LLM-as-a-Judge is a practical alternative: large models score unstructured outputs against structured rubrics [16]. The method carries known risks—self-consistency bias, verbosity preference, and scoring “personalities” that differ by model family. A multi-family judge panel, rather than one evaluator, can surface that disagreement as a measurable signal [16]. We use this setup for automated fitness-plan evaluation, where lenient judges would inflate checklist compliance and would not establish clinical safety.

Earlier systems mostly summarize retrospective health metrics, wearable traces, or lifestyle insights [1,2]. Fewer hold the generator backbone fixed and separate deterministic preprocessing from orchestration complexity—the comparison we run here.

3. Materials and Methods

3.1. Study Design and Dataset

The evaluation uses a longitudinal set of real-world health metrics and training logs from five users (a small pilot cohort). Each user contributed a 21-day historical window of daily physiological signals—resting heart rate, heart-rate variability (HRV), sleep duration, and strain—together with detailed workout records (sets, repetitions, and loads). For the matched evaluation, each architecture generated one plan per user per day for 10 consecutive target dates, yielding $N=50$ matched plan-days per arm (5 users × 10 days) and 200 total generated plans across four arms.

All user profiles and health metrics were anonymized and de-identified prior to use. Because this study analyzes fully anonymized retrospective data that cannot be linked to individual subjects, formal ethical committee approval for human experimentation was not required. One participant profile (User 303) is conditioning-only with zero resistance volume load; analyses that pool load-based criteria should be interpreted with this heterogeneity in mind.

3.2. AI Architectures Evaluated

Using the anonymized user profiles, we benchmarked four matched system configurations on the same 50 user-days (Figure 1). All generators used gemini-2.5-pro at temperature 0.2, emitted plans in a shared JSON schema, and passed outputs through the same deterministic workout_calculator post-processing gatekeeper before scoring. The gatekeeper is not a passive formatter: after generation it (i) enforces muscle-group rotation constraints, (ii) sanitizes reps/tempo and cardio fields, (iii) applies equipment and push/pull load-ratio checks, (iv) caps historical load swings, (v) applies progressive-overload weight rounding and hypertension isometric replacements where flagged, and (vi) overwrites session duration and training impulse (TRIMP). Judges therefore evaluate post-gatekeeper plans; residual between-arm gaps reflect precompute, prompting, tools, and orchestration that survive these shared rewrites. Configurations differ in orchestration, tool access, retry routing, and whether deterministic SDS/MP summaries are injected before generation—those differences are the experimental contrast. Relative to Multi-Agent and ReAct, Baseline also lacks validator/tool retry loops, so the Baseline↔Multi/ReAct contrast confounds precompute with scaffolding. The cleanest precompute-only contrast is Baseline versus Single Agent.

1.

Baseline-LLM (C0b): A single gemini-2.5-pro completion with no tools and no SDS/MP precompute in the prompt. The model receives the user profile, equipment list, feedback stub, the last 21 workout sessions, the last 21 days of wearable metrics, and target-day vitals—a raw clinician-chart bundle without readiness scores, ACWR/ATL/CTL summaries, or muscle-recovery rankings.

2.

Single Agent: A monolithic approach where profile, equipment, feedback, and deterministic SDS/MP summaries are injected into one comprehensive prompt.

3.

Multi-Agent Framework: A modular, LangGraph-based architecture with specialized nodes (e.g., Health Condition Safety Officer, Biomechanist) that sequentially process precomputed inputs to build the workout plan, with validator-driven replan loops.

4.

ReAct Agent: A tool-using agentic loop that iteratively reasons over user data, retrieving health guidelines and executing physiological calculations before finalizing the prescription.

Multi-Agent node roles are summarized in Table 1.

Figure 3 illustrates the directed execution graph of the Multi-Agent Framework, including the validation-retry loop.

Figure 2, Figure 3, and Figure 4 illustrate the directed execution graphs for the three scaffolded configurations; the Baseline-LLM arm is a single-call path without graph orchestration or tool loops.

Figure 2. Directed execution graph of the Single Agent architecture. Raw chart data are compressed by deterministic SDS/MP precompute, then injected into one monolithic gemini-2.5-pro call ($T=0.2$). The shared workout_calculator gatekeeper rewrites rotation, duration/TRIMP, and load-cap fields before the plan is stored. Unlike Multi-Agent, this arm has no in-loop critique/retry; LLM-as-a-Judge scoring occurs only in the offline evaluation panel.

Figure 2. Directed execution graph of the Single Agent architecture. Raw chart data are compressed by deterministic SDS/MP precompute, then injected into one monolithic gemini-2.5-pro call ($T=0.2$). The shared workout_calculator gatekeeper rewrites rotation, duration/TRIMP, and load-cap fields before the plan is stored. Unlike Multi-Agent, this arm has no in-loop critique/retry; LLM-as-a-Judge scoring occurs only in the offline evaluation panel.

Figure 3. Directed execution graph of the Multi-Agent Framework implemented in LangGraph. Data flows sequentially through eight specialized nodes—from the deterministic Sports Data Scientist (SDS) through the Exercise Physiologist (EP), Movement Planner (MP), Athletic Trainer (AT), Biomechanist (BM), Health Condition Safety (HCS), and Health Coach (HC)—to the deterministic Validator. An HCS safety critique can replan BM once; Validator business-rule failures (e.g., session duration > 75 min) inject a structured critique and replan from EP for up to three pipeline retries before a final plan is emitted.

Figure 3. Directed execution graph of the Multi-Agent Framework implemented in LangGraph. Data flows sequentially through eight specialized nodes—from the deterministic Sports Data Scientist (SDS) through the Exercise Physiologist (EP), Movement Planner (MP), Athletic Trainer (AT), Biomechanist (BM), Health Condition Safety (HCS), and Health Coach (HC)—to the deterministic Validator. An HCS safety critique can replan BM once; Validator business-rule failures (e.g., session duration > 75 min) inject a structured critique and replan from EP for up to three pipeline retries before a final plan is emitted.

Figure 4. Directed execution graph of the ReAct Agent architecture. The agent operates as a multi-turn reasoning loop (gemini-2.5-pro, $T=0.2$) selecting between a Python tool (run_python_code) and a RAG tool (retrieve_health_guidelines). Observations update context before the next step. After a final answer is emitted, the shared workout_calculator gatekeeper applies rotation, duration/TRIMP, and load-cap rewrites. TRIMP is not an LLM tool; it is overwritten deterministically post-generation. LLM-as-a-Judge scoring is offline only.

Figure 4. Directed execution graph of the ReAct Agent architecture. The agent operates as a multi-turn reasoning loop (gemini-2.5-pro, $T=0.2$) selecting between a Python tool (run_python_code) and a RAG tool (retrieve_health_guidelines). Observations update context before the next step. After a final answer is emitted, the shared workout_calculator gatekeeper applies rotation, duration/TRIMP, and load-cap rewrites. TRIMP is not an LLM tool; it is overwritten deterministically post-generation. LLM-as-a-Judge scoring is offline only.

3.3. Evaluation Framework (LLM-as-a-Judge)

Evaluating physiological coherence and checklist compliance of generated workout plans requires deep contextual reasoning. Therefore, we employed an LLM-as-a-Judge methodology [16] (Figure 5). The evaluation panel consisted of four models: claude-opus-4-5, gemini-3.1-pro-preview, GPT-4o, and deepseek-chat (all at temperature $0.0$ with structured outputs). We acknowledge that judge families overlap vendor ecosystems with the generation backbone; to partially mitigate this, all four judges scored each plan independently and their integer criterion scores were averaged into a consensus, with inter-judge disagreement tracked explicitly.

Each generated fitness plan was independently scored by all four evaluators across eight rubric criteria (C1–C8): Readiness Coherence (C1), Medical Load Compliance (C2), Compound Exercise Coverage (C3), multi-day Exercise Rotation Tracking (C4), Volume Load Specificity (C5), Tempo and Rest Structure Compliance (C6), Goal Alignment (C7), and Exercise Duration Compliance (C8). Judges assign integer scores from 0 to 10 per criterion. A plan receives a FAILED verdict if any criterion scores below 8 or if a medical/safety constraint is violated; otherwise it is PASSED. Overall architecture performance is summarized by the mean consensus score across criteria and judges on each matched user-day ($N=50$ per arm). Separately, we report a softer binary pass rate using overall consensus $\ge 7.5$ as an exploratory compliance threshold; this is not identical to the strict all-criteria $\ge 8$ verdict rule above. This rubric measures automated compliance with a structured checklist and should not be interpreted as expert clinical ground truth (see Discussion).

3.4. Evaluation Rubric and Grading Calibration

The judge prompt supplies natural-language definitions for each criterion (C1–C8) and requests an integer score from 0 to 10 with a written justification per criterion—there are no fixed within-band anchors such as “7–9 = acceptable.” This design prioritises reproducible criterion labels over calibrated Likert bands; low inter-rater agreement (Fleiss $\kappa \approx 0.18$ overall) is therefore expected and is reported in the Results.

The automated verdict rule is strict: FAILED if any criterion scores below 8 or if a medical/safety violation is identified; PASSED only when all eight scores are $\ge 8$ and no safety issue is noted. Criterion definitions follow the implementation in our evaluator: C1 aligns session intensity with readiness and fatigue signals; C2 enforces medical flags and contraindications; C3 requires appropriate multi-joint compound coverage; C4 checks multi-day muscle-group rotation; C5 demands explicit set/rep/load specificity; C6 requires warm-up/cool-down structure with explicit rest and tempo; C7 aligns exercise selection with stated goals; C8 checks that estimated session duration is realistic and within the 75-minute compliance boundary.

3.5. Health Metrics Preprocessing and Token Compression

For the three scaffolded configurations (Single, Multi-Agent, ReAct), raw wearable data and training logs undergo deterministic preprocessing before any LLM invocation (Figure 6). The Baseline-LLM arm receives the raw chart blocks described in Section 3.2 (profile, equipment, 21-day history and metrics) without SDS/MP summaries, isolating the contribution of precomputed analytics. This layer operates with zero LLM involvement, compressing time-series streams into a structured, high-signal JSON bundle.

The algorithmic preprocessing pipeline executes the following core computations programmatically prior to any LLM invocation:

1.

Daily Load ${\mathrm{Load}}_t$ (input to ATL/CTL): For each calendar day t, a scalar training load combines conditioning and resistance volume:

$${\mathrm{Load}}_t=w_1({\mathrm{Duration}}_t·I_t)+w_2{\displaystyle \frac{{\mathrm{VL}}_t}{S_{\mathrm{user}}}},(w_1,w_2)=(0.5,0.5),$$

(1)

where ${\mathrm{Duration}}_t$ is activity minutes, $I_t\in [0,1]$ is intensity ($I_t=\mathrm{session}\_\mathrm{RPE}/10$ when available, else wearable/diary stress$/10$), ${\mathrm{VL}}_t=\sum (\mathrm{reps}\times \mathrm{load}\_\mathrm{lbs})$ is resistance volume load, and $S_{\mathrm{user}}$ is a per-user resistance scale (median VL / median conditioning over history, clamped to $[5,100]$; default 20) that places resistance and conditioning on comparable scales. Absolute ATL/CTL/TSB are therefore per-user units; ${\mathrm{ACWR}}_t={\mathrm{ATL}}_t/{\mathrm{CTL}}_t$ cancels $S_{\mathrm{user}}$ and is the preferred cross-user load ratio.

2.

Rolling Workload Metrics (ATL, CTL, TSB, ACWR): Daily ${\mathrm{Load}}_t$ values are aggregated using exponentially weighted moving averages (EWMA) in the Banister impulse–response tradition [14]. This generates the Acute Training Load ($\mathrm{ATL}$, 7-day window), Chronic Training Load ($\mathrm{CTL}$, 21-day window), Training Stress Balance ($\mathrm{TSB}$), and the Acute:Chronic Workload Ratio ($\mathrm{ACWR}$). For any given day t, these metrics are computed as:

$$\begin{array}{cc}\hfill {\mathrm{ATL}}_t& ={\mathrm{Load}}_t·\left({\displaystyle \frac{2}{7+1}}\right)+{\mathrm{ATL}}_{t-1}·\left(1-{\displaystyle \frac{2}{7+1}}\right)\hfill \end{array}$$

(2)

$$\begin{array}{cc}\hfill {\mathrm{CTL}}_t& ={\mathrm{Load}}_t·\left({\displaystyle \frac{2}{21+1}}\right)+{\mathrm{CTL}}_{t-1}·\left(1-{\displaystyle \frac{2}{21+1}}\right)\hfill \end{array}$$

(3)

$$\begin{array}{cc}\hfill {\mathrm{TSB}}_t& ={\mathrm{CTL}}_t-{\mathrm{ATL}}_t\hfill \end{array}$$

(4)

$$\begin{array}{cc}\hfill {\mathrm{ACWR}}_t& ={\displaystyle \frac{{\mathrm{ATL}}_t}{{\mathrm{CTL}}_t}}\hfill \end{array}$$

(5)

Providing these pre-calculated metrics gives the downstream architectures a grounded mathematical baseline of the user’s fatigue and fitness. We treat ${\mathrm{ACWR}}_t$ values in the range $[0.8,1.3]$ as an operational monitoring band used in load-management practice [12]; ACWR–injury causality remains debated and is not assumed here [13].

3.

Composite Readiness Scoring: Daily HRV, resting heart rate (RHR), sleep, and 24-hour strain are normalized against each user’s rolling historical means to form z-scores. The composite readiness score is:

$$R=w_{1}z\left(\mathrm{HRV}\right)+w_{2}z(-\mathrm{RHR})+w_{3}z\left(\mathrm{Sleep}\right)+w_{4}z(-\mathrm{Strain})$$

(6)

with default weights $(w_1,w_2,w_3,w_4)=(0.35,0.25,0.25,0.15)$. Missing inputs are excluded and remaining weights are renormalised to sum to one. R is mapped to $R_{100}\in [0,100]$ via linear scaling from $R\in [-3,+3]$.

4.

Muscle Group Recovery Tracking: To manage localized biomechanical fatigue, historical workout logs are processed using an exponential decay model. Each major muscle group m receives a residual stress score based on recent volume loads over a 21-day window, establishing a deterministic recovery ranking that flags under-recovered muscle groups. The residual stress is aggregated as:

$${\mathrm{ResidualStress}}_m=\sum _i{\mathrm{Load}}_{m,i}·e^{-ln\left(2\right){\displaystyle \frac{\Delta t_i}{t_{1/2,m}}}}$$

(7)

where $\Delta t_i$ is the time elapsed since the i-th workout targeting muscle group m, and $t_{1/2,m}$ is the assumed engineering recovery half-life assigned to muscle group m, with values ranging from 48 hours for smaller isolation muscles to 72 hours for large compound movers such as the quadriceps and posterior chain.

This preprocessing step aggregates raw time-series metrics into a structured aggregated_metrics JSON bundle injected into the three scaffolded configurations. Numerical load metrics consumed downstream are anchored to these kernel outputs for scaffolded arms. ReAct may still call Python tools for ad hoc calculations; final duration/TRIMP and several safety fields are overwritten by the shared gatekeeper. Figure 7 illustrates the pre-computation pipeline’s layout.

The Baseline-LLM arm provides the empirical contrast for this preprocessing layer: the same generator model and post-processing gatekeeper, but without injected SDS/MP summaries. Relative to Multi-Agent and ReAct, Baseline also lacks validator/tool retry loops, so the strongest attribution of precompute effects is the Baseline versus Single comparison (Results).

3.6. Statistical Analysis

Unless noted otherwise, the analysis unit is the matched user-day: for each of 5 users and 10 target dates, all four configurations generate one plan, yielding $N=50$ paired observations per arm (200 plans total). User identity induces clustering; day-level tests are therefore interpreted as within-cohort paired comparisons, with user-level cluster bootstrap (1,000 resamples of the five users) reported as a sensitivity check. Primary continuous endpoints are per-criterion and overall consensus means (mean of available judges’ integer scores). Omnibus architecture effects use Friedman tests on the four matched arms. Pairwise contrasts use Wilcoxon signed-rank tests with Holm–Bonferroni correction within the confirmatory family; paired Cohen’s $d_z$ accompanies Wilcoxon contrasts. Binary exploratory analyses use overall consensus $\ge 7.5$ (distinct from the strict all-criteria $\ge 8$ verdict). Inter-rater agreement on binary compliance uses Fleiss’ $\kappa$. Criterion-level and per-judge Friedman tests beyond the Baseline-driven overall contrast are treated as exploratory. With only five user clusters, day-level $N=50$ should not be read as fifty independent subjects; we do not claim population inference beyond this pilot cohort.

3.7. Generative AI Use in Manuscript Preparation

Beyond the generator and judge models evaluated as study interventions (Sections above), generative AI was used during manuscript preparation. Specifically, Gemini 2.5 Pro (Google DeepMind) assisted with (i) drafting and restructuring prose in early manuscript versions, (ii) generating and revising architecture/flow diagram drafts later edited by the authors, and (iii) suggesting formatting fixes. All GenAI outputs were reviewed, fact-checked against evaluation logs and code, and edited by the authors; GenAI tools are not authors and do not meet MDPI authorship criteria. Superficial grammar-only edits are not claimed here. Product details are restated in the Acknowledgments.

4. Results

This section reports matched $N=50$ user-day evaluations (5 users × 10 days) across four system configurations, scored by a four-judge LLM-as-a-Judge panel. Findings are organized by aggregate performance, per-configuration summaries, judge behavior, robustness checks, and computational overhead (Section 4.6; Tables 7 and 8).

4.1. Aggregate Four-Way Performance

Table 2 summarizes mean consensus scores per criterion. A 4-way Friedman test detected significant overall differences (${\chi }^2=21.93$, $p=6.76\times {10}^{-5}$), driven primarily by the Baseline-LLM arm rather than by differences among the three scaffolded configurations. Pairwise Wilcoxon signed-rank tests with Holm correction showed no significant overall differences among Single (7.20), Multi (7.34), and ReAct (7.18), whereas Baseline-LLM (6.23) was significantly lower than each scaffolded arm (Holm-adj. $p\le 0.0034$). Paired effect sizes for Baseline-minus-scaffolded overall scores were medium ($d_z\approx -0.63$, $-0.72$, $-0.68$ for Single, Multi, and ReAct, respectively).

At the criterion level, 4-way Friedman tests were significant for C1, C2, C4, C5, C6, C7, and C8 ($p<0.05$); C3 was not ($p=0.10$). After Holm correction, confirmatory pairwise survivors were predominantly Baseline vs. {Single, Multi, ReAct} rather than Single↔Multi↔ReAct comparisons. User-level cluster bootstrap confirmed that the Baseline−Single overall mean difference ($-0.98$) had a 95% confidence interval (CI) of $[-1.70,-0.48]$ (excludes zero), whereas the Multi−Single overall CI ($[+0.14]$; $[-0.21,0.46]$) overlapped zero.

Binary exploratory pass rates (overall consensus $\ge 7.5$; not the strict all-criteria $\ge 8$ verdict) were Multi 48% (24/50), Single 38% (19/50), ReAct 34% (17/50), and Baseline 12% (6/50). Fleiss’ $\kappa$ for overall binary compliance was 0.18 (slight agreement), indicating that automated rubric scores should not be treated as clinical ground truth.

4.2. Per-Configuration Summaries

4.2.1. Baseline-LLM (Raw-Chart Control)

Baseline-LLM achieved the lowest overall consensus (6.23) and the lowest pass rate (12%). It underperformed on structure- and load-related criteria, including C5 (5.34), C6 (6.51), and C8 (6.11), consistent with the absence of injected SDS/MP summaries. Baseline won zero of five per-user overall rankings.

4.2.2. Single Agent (Monolithic Architecture)

Single Agent scored 7.20 overall with relative strengths in medical handling (C2: 8.04) and tempo/rest structure (C6: 8.03). Its weakest criterion was goal alignment (C7: 5.86). Among the scaffolded trio, Single was not significantly different from Multi or ReAct on overall score after Holm correction.

4.2.3. Multi-Agent Framework (Modular Architecture)

Multi-Agent achieved the highest overall mean (7.34) but the difference from Single and ReAct was not statistically significant. Relative strengths included readiness coherence (C1: 8.12) and goal alignment (C7: 6.88).

4.2.4. ReAct Agent (Tool-Augmented Architecture)

ReAct scored 7.18 overall—statistically indistinguishable from Single and Multi after Holm correction. Among scaffolded arms it had the lowest C4 mean (7.01) and the highest judge verdict agreement (90%). Tool-augmented reasoning did not yield a significant aggregate advantage over monolithic Single or graph-based Multi on matched user-days.

4.3. Evaluator Behavior and Bias Summary

Across $N=50$ matched evaluations per arm, four judges exhibited distinct scoring personalities (Table 3, Table 4, Table 5, and Table 6):

1.

GPT-4o: Highest average scores across architectures (e.g., Single overall 8.22; Baseline 7.78), consistently lenient on medical compliance (C2).

2.

DeepSeek: Mid-range scores, closest to cross-judge consensus on several criteria.

3.

Claude: Strictest judge overall (e.g., Baseline overall 5.58), frequently penalizing rotation (C4) and volume specificity (C5).

4.

Gemini: Most variable; severe C4/C5 penalties on some arms (e.g., ReAct C4 mean 6.02; Baseline C5 mean 3.16) while scoring structure (C6) more generously on others.

Overall Fleiss’ $\kappa =0.18$ (slight). Per-judge 4-way Friedman tests were significant for all four judges ($p<0.05$), confirming that architectural effects persist within each judge family but with different absolute scales.

4.4. Per-User Ranking Stability

Per-user overall winners were: User 49 Single (7.83), User 127 ReAct (7.33), User 202 ReAct (7.27), User 276 Multi (7.49), and User 303 Multi (7.51). Baseline-LLM won 0/5 users. Agentic configurations (Multi or ReAct) led for 4/5 users; Single led for 1/5—rankings remain user-dependent despite aggregate trio null results.

4.5. Key Findings

• Precompute matters (rubric + cost): Baseline without SDS/MP scored ∼1 point lower overall and used ∼3× more input tokens / ∼40% higher $/run than Single.
• Orchestration null on aggregate: Single, Multi, and ReAct were not significantly different after Holm correction.
• Judge variance: Fleiss $\kappa \approx 0.18$; criterion-level contrasts remain exploratory.

4.6. Computational Complexity, Latency, and Cost

To quantify operational overhead, we benchmarked execution latency, input/output token usage, and monetary cost for all four configurations on generation logs from the five matched users. Scaffolded arms use the same matched $N=50$ evaluation cohort as the rubric analysis; Baseline-LLM cost/latency uses $n=53$ generation-log runs for those users (three extra logged runs outside the matched 50-day score panel). These operational summaries are therefore not day-locked to the quality tables and should be read as deployment overhead, not paired quality–cost inference. All cost measurements used the same generator backbone as the rubric evaluation—gemini-2.5-pro—via Google’s Gemini API. Pricing is based on list rates as of March 2026: $1.25 per million input tokens and $5.00 per million output tokens.

Table 7 and Table 8 summarize the statistical benchmarks (mean ± standard deviation) for each paradigm.

4.6.1. Architectural Trade-Offs and Computational Profiles

The strongest token-cost result is the matched single-call contrast: SDS/MP precompute. Baseline-LLM (raw 21-day chart, no SDS/MP) averaged $12,504\pm 3,431$ input tokens and $0.025 per run, versus Single Agent (same backbone and gatekeeper, with SDS/MP summaries) at $4,131\pm 85$ input tokens and $0.015 per run—approximately a $3\times$ reduction in input tokens and a ∼40% reduction in API cost, with similar output size (∼2,000 tokens) and slightly lower latency for Single ($37.5$ s vs. $41.6$ s). Omitting precompute therefore does not save money; it enlarges the prompt and raises $/run while also lowering rubric scores (Results).

Among multi-call systems, token profiles diverge further. The Multi-Agent Framework exhibits an input-heavy profile, averaging $15,249\pm 4,642$ input tokens. This figure is the sum of input tokens across all LLM node calls in one plan generation (not a single prompt), driven by per-node system prompts and state payloads replicated across the sequential LangGraph workflow (Exercise Physiologist, Movement Planner, Athletic Trainer, Biomechanist, Health Condition Safety, and Health Coach; Sports Data Scientist and Validator are deterministic and add no LLM tokens). Despite consuming the most input tokens of any architecture, its output-token footprint remains lean ($3,144\pm 1,016$), which translates to a cost per run of $0.035 — roughly half that of the ReAct Agent. This cost advantage arises directly from the API pricing asymmetry: output tokens are priced four times higher than input tokens on the gemini-2.5-pro tier, meaning an input-heavy profile is substantially more economical than an output-heavy one.

The ReAct Agent exhibits the inverse profile: a relatively modest input footprint ($5,096\pm 6,432$ tokens) but a large and highly variable output footprint ($12,379\pm 5,456$ tokens), producing the highest cost per run at $0.068. This output inflation is driven by its multi-turn reasoning loop, in which intermediate Python code blocks, tool call results, and RAG query responses are appended to the growing context window across each iteration. The high standard deviation on both latency ($\pm 68.08$ s) and input tokens ($\pm 6,432$) is direct evidence of its variable tool-use execution paths: some sessions converge after a single pass while others require up to six recursive tool calls before producing a valid plan.

The monolithic Single Agent yields the lowest latency and cost under the matched gemini-2.5-pro backbone ($37.50\pm 4.20$ s; $0.015), illustrating that deterministic precompute improves both rubric compliance and token economy relative to Baseline. The Multi-Agent Framework is the slowest pipeline overall, averaging $159.39\pm 49.83$ seconds, with latency primarily attributable to the network overhead of sequential LLM node API calls, structural state transitions, and deterministic validation-retry iterations (averaging 0.08 retries per run).

5. Discussion

A daily workout plan has to satisfy long-term goals, acute fatigue, biomechanical limits, and medical contraindications at once. The matched four-way evaluation ($N=50$ user-days per arm) treats this as a system-configuration comparison: every generator uses gemini-2.5-pro at temperature 0.2 and the same workout_calculator post-processing layer, and the arms differ in precompute injection, graph orchestration, and tool access.

5.1. System-Configuration Trade-Offs

The clearest finding is the Baseline-LLM floor. Removing deterministic SDS/MP summaries while holding the model and gatekeeper fixed lowered overall consensus from ∼7.2 to 6.23 ($d_z\approx -0.63$ to $-0.72$ vs. scaffolded arms) and increased generation cost: Baseline used ∼3× more input tokens and ∼40% higher $/run than Single (Section 4.6). Precompute therefore pays twice— better rubric compliance and a smaller paid prompt—supporting “kernels compute, models decide”: deterministic preprocessing supplies load, readiness, and recovery structure that a raw-chart single call reconstructs poorly and expensively.

Among the three scaffolded configurations, aggregate differences were not significant after Holm correction (Single 7.20, Multi 7.34, ReAct 7.18). Multi-Agent led on mean overall score and pass rate (48% vs. 38% Single, 34% ReAct) but cluster-bootstrap CIs for Multi−Single overall overlapped zero. ReAct incurred the highest per-run cost and latency variability (Section 4.6) without a statistically significant aggregate rubric-score advantage. The practical implication is that added orchestration complexity should be justified by deployment constraints (modularity, auditability, tool policies) rather than by expected mean rubric lifts on this matched cohort.

Per-user rankings were unstable: agentic configurations led for 4/5 users, Single for 1/5, and Baseline for 0/5. Criterion-level effects were judge-dependent (Fleiss $\kappa =0.18$ overall), so exploratory criterion comparisons should be interpreted cautiously.

5.2. Muscle Rotation and Preprocessing

C4 (muscle group rotation) was not a universal failure in this run: scaffolded means were 7.72–7.78 with Baseline lowest at 6.17. Residual C6/C8 gaps favoring scaffolded arms over Baseline persist despite shared duration/TRIMP gatekeeper overwrites, indicating that precompute and prompt structure still matter upstream of post-processing. Persistent cross-session state tracking remains an engineering priority for future deployments.

5.3. Limitations

Sample size and diversity. Five users over 10 matched days ($N=50$ per arm) supports paired nonparametric testing but limits generalization across medical conditions, training ages, and equipment contexts. User 303 is conditioning-only (zero resistance volume load), so load-based criteria pool heterogeneous constructs; primary conclusions should be read with this caveat, and future analyses may report sensitivity excluding User 303.

Evaluation instrument. Scores reflect automated rubric compliance by four LLM judges, not expert clinical validation. Fleiss’ $\kappa =0.18$ overall (slight agreement) indicates that judges use different absolute scales; GPT-4o was systematically lenient while Claude was strict. We report $\kappa$ and per-judge Friedman tests rather than treating consensus as ground truth.

Missing absolute floor. Baseline-LLM isolates the contribution of precompute relative to the same model, but a deterministic rules-only planner (C0) was not implemented; mid-7s scaffolded scores therefore lack a non-LLM reference anchor.

Pipeline disclosures. (i) Stored plans may expose pre-fix TRIMP telemetry fields visible to judges but outside the scored rubric; (ii) one matched user-day lacked complete four-judge coverage in the archived log tree; (iii) soreness-based modifier $F_m$ is defined in code but never executed because no soreness survey is collected.

Reproducibility. Generator and judge model IDs and temperatures are documented, but runs do not fix random seeds; exact replication may vary across hardware and API versions.

Deployment costs. Latency ranged from ∼38 s (Single Agent) to ∼159 s (Multi-Agent), with Baseline at ∼42 s / $0.025 and ReAct up to $0.068 per run (Table 8), limiting real-time consumer use without caching or distillation.

Outcome validity. We do not measure adherence, injury rates, or longitudinal physiological outcomes—only structural compliance on an automated checklist.

6. Conclusions

We benchmarked four matched system configurations for personalized workout generation with one generator backbone and one post-processing gatekeeper. Deterministic SDS/MP precompute raises rubric compliance and cuts token cost: Baseline-LLM without those summaries scored ∼1 point lower overall than scaffolded arms (all Holm-significant) and used ∼3× more input tokens and ∼40% more $/run than Single. Among Single, Multi-Agent, and ReAct, aggregate rubric scores were statistically indistinguishable after multiple-comparison correction, even though latency, token profile, and engineering complexity differed.

Practitioners should build deterministic preprocessing and calculation kernels first, then pick orchestration for modularity and audit needs rather than for mean rubric lifts on small matched cohorts. Next steps are a rules-only baseline, human expert validation, preference-based pairwise evaluation, and longitudinal outcome studies before consumer deployment or clinical-safety claims.