Paper deep dive
A Task-Oriented Multi-Agent Framework for Complex Wearable Health Analysis
Kunpeng Yang
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 9/22/2026, 4:27:14 AM
Summary
The paper introduces a Task-Oriented Multi-Agent Framework for analyzing complex wearable health data. It decomposes composite natural language queries into distinct intents and typed tasks (query, analyse, advice) with explicit intra-intent dependencies. Specialized agents (Query, Analyse, Advice) execute these tasks to ensure traceable evidence and reduced token consumption. Evaluation on a synthetic dataset of 10,000 users shows high accuracy in retrieval (98.3%) and multi-intent coverage (100%), with improved trustworthiness and transparency compared to direct LLM baselines.
Entities (8)
Relation Signals (8)
Task-Oriented Multi-Agent Framework → uses → Advice Agent
confidence 95% · Specialized agents execute... advice... Advice Agent... generates health-support advice
Task-Oriented Multi-Agent Framework → uses → Manager Agent
confidence 95% · The Manager Agent identifies distinct user intents and decomposes each into typed tasks with explicit dependencies.
Task-Oriented Multi-Agent Framework → uses → Query Agent
confidence 95% · Specialized agents execute retrieval... The Query Agent resolves temporal constraints...
Task-Oriented Multi-Agent Framework → uses → Analyse Agent
confidence 95% · Specialized agents execute... analysis... Analyse Agent... performs longitudinal comparisons
Task-Oriented Multi-Agent Framework → evaluatedon → Synthetic dataset
confidence 92% · We evaluate the framework on a synthetic dataset of 10,000 virtual users
Query Agent → achievesaccuracy → 98.3%
confidence 90% · the Query Agent achieves 98.3% accuracy
Manager Agent → achievescoverage → 1.000
confidence 90% · the Manager Agent achieves 100.0% Multi-Intent Coverage
Task-Oriented Multi-Agent Framework → comparedwith → Direct LLM
confidence 90% · compared with 97.9% for the Direct LLM baseline
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Wearable health questions often combine data retrieval, longitudinal analysis, and health advice over structured records. Prompting a single large language model with a complete record and a composite query obscures whether every request is executed and which evidence supports the answer. We propose a task-oriented multi-agent framework that represents a composite query as distinct intents and typed tasks with explicit intra-intent dependencies. Specialized agents execute retrieval, analysis, and advice tasks; isolated intent states preserve request boundaries and evidence relationships before aggregation. We evaluate the framework on a synthetic dataset of $10{,}000$ virtual users with one month of longitudinal wearable records, covering structured data retrieval, multi-intent recognition, and overall response quality. Across $1{,}500$ retrieval questions, the Query Agent achieves $98.3\%$ accuracy, compared with $97.9\%$ for the Direct LLM baseline, while reducing average query-stage token consumption from $6{,}869$ to $3{,}136$. On $180$ multi-intent questions, the Manager Agent achieves $100.0\%$ Multi-Intent Coverage and $94.4\%$ Multiset Jaccard Similarity. Under the current synthetic evaluation setting, our method receives higher mean Trustworthiness and Transparency scores on both question categories, whereas Actionability does not improve consistently. These results provide preliminary evidence that explicit task organization can support task-relevant data access and data-grounded longitudinal analysis, while leaving health advice generation and validation on real wearable data as open challenges.
Tags
Links
- Source: https://arxiv.org/abs/2609.24107v1
- Canonical: https://arxiv.org/abs/2609.24107v1
Trouble viewing inline? Open PDF directly →
Full Text
71,926 characters extracted from source content.
Expand or collapse full text
A Task-Oriented Multi-Agent Framework for Complex Wearable Health Analysis Kunpeng Yang Affiliation: Renmin University of China Email: math_co@163.com Abstract Wearable health questions often combine data retrieval, longitudinal analysis, and health advice over structured records. Prompting a single large language model with a complete record and a composite query obscures whether every request is executed and which evidence supports the answer. We propose a task-oriented multi-agent framework that represents a composite query as distinct intents and typed tasks with explicit intra-intent dependencies. Specialized agents execute retrieval, analysis, and advice tasks; isolated intent states preserve request boundaries and evidence relationships before aggregation. We evaluate the framework on a synthetic dataset of 10,00010,000 virtual users with one month of longitudinal wearable records, covering structured data retrieval, multi-intent recognition, and overall response quality. Across 1,5001,500 retrieval questions, the Query Agent achieves 98.3%98.3\% accuracy, compared with 97.9%97.9\% for the Direct LLM baseline, while reducing average query-stage token consumption from 6,8696,869 to 3,1363,136. On 180180 multi-intent questions, the Manager Agent achieves 100.0%100.0\% Multi-Intent Coverage and 94.4%94.4\% Multiset Jaccard Similarity. Under the current synthetic evaluation setting, our method receives higher mean Trustworthiness and Transparency scores on both question categories, whereas Actionability does not improve consistently. These results provide preliminary evidence that explicit task organization can support task-relevant data access and data-grounded longitudinal analysis, while leaving health advice generation and validation on real wearable data as open challenges. 1 Introduction Wearable devices produce longitudinal records spanning exercise, daily activity, sleep, and physiological events. These records can support personalized interpretation of health changes, but their scale and structure make direct inspection impractical. Users instead need natural-language interfaces that can retrieve measurements, compare indicators over time, and provide appropriate health-support information. This paper studies how to answer composite wearable health queries: questions that combine several requests over structured longitudinal records and require each request to remain traceable to the evidence used in its answer. Composite queries create three coupled technical challenges. First, one question may contain several distinct user requests, including repeated instances of the same intent type and shared temporal constraints that must be preserved during separation. Second, an analysis or advice request may require evidence produced by multiple retrieval operations; execution order alone does not specify which predecessor results should be available to each downstream step. Third, natural-language time expressions and health indicators must be mapped to exact dates and fields in the underlying record. Errors in request coverage, temporal resolution, or evidence selection can then propagate into longitudinal analysis and advice generation. Large language models (LLMs) have shown considerable potential for medical question answering and health consultation (Singhal et al., 2025), but factual errors and unreliable outputs remain concerns when tasks involve specialized numerical information and complex health reasoning (Wang et al., 2024; Liu et al., 2024a). Statistical tools, information retrieval, code execution, and agent mechanisms extend what LLM-based health systems can process. Yet directly providing a complete longitudinal record and a composite question to one model still leaves request coverage, structured data access, and evidence flow implicit: the same generation process must identify each request, locate records, organize numerical results, and compose the final answer. The resulting gap is primarily one of execution representation rather than the number of agents. For a composite wearable query, a system needs to preserve distinct user requests, express the operations required by each request, and identify the predecessor evidence consumed by downstream analysis or advice. It must also separate deterministic access to structured records from language-model generation. Existing progress in tool-augmented and multi-agent health systems motivates these capabilities, while the organization of repeated intents, intra-query task dependencies, and structured-record evidence within a single composite query remains less explicitly studied. We address this gap with the Task-Oriented Multi-Agent Health Assistance Framework. The framework represents a composite query through an intent–task hierarchy: a Manager Agent identifies distinct user intents and decomposes each into typed tasks with explicit dependencies. Dependencies are restricted to tasks within the same intent, so downstream Analyse and Advice Tasks receive only their specified predecessor results while each intent maintains an isolated local state. Task types are deterministically mapped to specialized agents. In particular, the Query Agent resolves temporal constraints, accesses target records through structured interfaces, and textualizes only task-relevant evidence for subsequent processing. After all intents finish, the Manager Agent aggregates their terminal results in the order of the original question. Our main contributions are as follows: (1) We formulate composite wearable health analysis through an intent–task hierarchy that preserves distinct requests and represents predecessor-evidence relationships as explicit intra-intent task dependencies. The resulting execution structure ties specialized-agent invocation to task semantics rather than to an open-ended communication protocol. (2) We design a Query Agent that separates natural-language temporal resolution, structured record access, and answer generation. This design supplies downstream language models with task-relevant evidence instead of the complete longitudinal record and is evaluated against the Direct LLM baseline using the same foundation model. (3) We construct a synthetic evaluation dataset containing 10,00010,000 virtual users and one month of longitudinal wearable records, together with evaluations of structured data retrieval, multi-intent recognition, and overall response quality. We release the implementation, data-generation pipeline, and synthetic dataset to support reproducibility and subsequent research.11 1 The source code, data generation pipeline, and synthetic wearable dataset are available at https://github.com/yangkunpeng-coder/WearableDeviceAgents. The synthetic evaluation examines structured retrieval, multi-intent recognition, and final response quality. Because it does not isolate task decomposition or dependency construction through component ablations, we treat these mechanisms as system-design contributions rather than independently verified sources of performance gains. 2 Related Work 2.1 Large Language Models for Wearable Health Analysis LLM-based wearable health systems increasingly connect natural-language interaction with longitudinal personal records. PH-LLM (Khasentino et al., 2025) generates personalized sleep and exercise insights, and PhysioLLM (Fang et al., 2024) combines wearable data, user context, and statistical analysis to explain relationships among personal health indicators. HealthGuru (Wang et al., 2025) further applies a multi-agent mechanism to personalized sleep-health support. Together, these studies demonstrate the value of grounding health-oriented language interaction in personal sensor data and analytical tools. WEQA is particularly related because it uses an LLM controller to construct query-adaptive execution plans, compose sensor-analysis tools and pretrained models, and audit answer evidence against external knowledge (Zhang et al., 2026). Its primary concern is heterogeneous tool and model selection across sensing, analysis, and prediction tasks. Our work addresses a complementary level of organization: retaining multiple distinct requests within one composite question and associating each downstream task with explicit predecessor evidence from structured longitudinal records. Thus, WEQA emphasizes query-adaptive tool composition, whereas our framework emphasizes multi-intent representation and intra-query evidence flow. 2.2 Agent Systems for Personal Health Agentic personal-health systems extend language models with executable tools, specialized roles, and persistent user context. The system of Merrill et al. (2026) combines multi-step reasoning, code execution, and information retrieval for iterative analysis of personal wearable data, while the personal health agent of Heydari et al. (2025) delegates data science, health expertise, and health coaching to specialized sub-agents. These systems establish useful patterns for tool-augmented analysis and role specialization. Other systems focus on longitudinal operation beyond a single interaction. HealthClaw separates shared safety rules and medical knowledge from private longitudinal memory, then determines whether interaction information should update the user profile, reusable workflows, or episodic memory (Li et al., 2026). HiMe instead emphasizes self-hosting, privacy, real-time processing, and database-centric long-term user modeling (Liu et al., 2026). Our framework does not study cross-session memory evolution or local deployment. It focuses on the within-query execution structure that records each intent, its tasks, and the predecessor results supplied to downstream agents. Specialized roles therefore serve an explicit request–task representation rather than constituting the contribution by themselves. 2.3 Task Decomposition and Agent Orchestration General-purpose agent research provides several foundations for organizing complex work. ReAct interleaves language reasoning with external actions (Yao et al., 2023), AutoGen supports interaction among agents, roles, and tools (Wu et al., 2024), and MetaGPT uses role specialization and structured workflows for collaborative task execution (Hong et al., 2024). DyLAN further selects agents dynamically and adapts their interaction structure to the task (Liu et al., 2024b). Collectively, these approaches study reasoning–action interaction, communication, routing, and workflow organization in general settings. Our framework draws on these orchestration principles but does not introduce a general communication protocol or learned router. It uses deterministic task-type routing and an execution representation tailored to structured wearable records. The relevant distinctions are repeated-intent preservation, natural-language temporal mapping, and explicit selection of predecessor evidence for downstream analysis and advice, rather than dynamic agent-team construction. 2.4 Positioning of This Work Across these directions, prior work has established wearable analysis, tool-augmented health agents, persistent health memory, local deployment, and general multi-agent orchestration. We focus more narrowly on organizing a single composite wearable health query. The intent level preserves distinct user requests; the task level represents the operations and intra-intent evidence dependencies needed to fulfill each request; and structured interfaces separate record access from language generation. The primary distinction is therefore an explicit representation that links requests, tasks, and evidence in multi-intent longitudinal queries, not a claim of more agents or a new general-purpose agent architecture. 3 Method We propose a task-oriented multi-agent framework that represents a composite wearable health query as distinct intents and typed tasks with explicit predecessor dependencies. 3.1 Problem Formulation Let u index a user, q denote a natural-language health query, and uD_u denote the user’s complete structured record, comprising a profile and date-indexed wearable records. The framework produces a response y from q and uD_u. The profile is extracted rather than supplied independently: ℬu=ExtractProfile(u),B_u=ExtractProfile(D_u), (1) As formalized in Eq. (1), ℬuB_u contains demographic, lifestyle, and health-history information. Intent recognition returns a sequence ordered by occurrence in q: ℐ=RecognizeIntents(q)=(i1,i2,…,iN),I=RecognizeIntents(q)= (i_1,i_2,…,i_N ), (2) Each ij=(textj,κj)i_j=(text_j, _j) contains a self-contained request description and type κj _j from the shared space =,,,C= \ query, analyse, advice \, where N is the number of intents in Eq. (2). Shared constraints are retained in every affected textjtext_j, and repeated types remain distinct sequence elements. We use Analyse Agent and Analyse Task for analyse throughout. Each intent iji_j is decomposed into the ordered task sequence (j)=(t1(j),…,tMj(j)),T^(j)=(t_1^(j),…,t_M_j^(j)), where MjM_j is the number of tasks. Each task is tm(j)=(idm(j),descm(j),cm(j),Dm(j)),t_m^(j)= (id_m^(j),desc_m^(j),c_m^(j),D_m^(j) ), (3) where idm(j)id_m^(j) and descm(j)desc_m^(j) denote the within-intent task identifier and description, respectively, cm(j)∈c_m^(j) is the task type, and Dm(j)D_m^(j) is the predecessor-ID set. Thus, Eq. (3) separates task identity, content, operation type, and dependencies. Intent types describe requested outcomes; task types describe operations. Hence, an analyse or advice intent may contain preceding retrieval or analysis tasks, while its terminal task satisfies cMj(j)=κjc_M_j^(j)= _j. Task dependencies may reference only preceding tasks within the same intent: Dm(j)⊆idp(j)∣1≤p<m.D_m^(j) \id_p^(j) 1≤ p<m \. (4) Eq. (4) permits only completed same-intent predecessors; tasks requiring no predecessor use Dm(j)=∅D_m^(j)= . A Query Task accesses uD_u directly and therefore has no predecessor, as required by Eq. (5): cm(j)=⟹Dm(j)=∅.c_m^(j)= query D_m^(j)= . (5) Analyse and Advice Tasks instead receive the completed same-intent predecessors named by Dm(j)D_m^(j). Table 1 summarizes the notation used throughout this section. Table 1: Summary of the principal notation used in the method. Symbol Definition u User index. q Natural-language health query issued by user u. u,ℬuD_u,B_u Complete structured record and extracted profile of user u. ℐ,ijI,i_j Ordered intent sequence and its j-th intent. (j),tm(j)T^(j),t_m^(j) Ordered task sequence for intent j and its m-th task. ,cm(j)C,c_m^(j) Shared type space and the type of task tm(j)t_m^(j). Dm(j),m(j)D_m^(j),P_m^(j) Predecessor identifiers and the corresponding ordered task descriptions and results. ℛ(j),rm(j),r(j)R^(j),r_m^(j),r^(j) Intent-local result store, task result, and terminal intent result. Km,LmK_m,L_m Numbers of findings and recommendations produced by a task. ℛℐ,Γ,yR_I, ,y Ordered intent-result sequence, final response renderer, and final response. 3.2 Framework Overview Figure 1 summarizes recognition, decomposition, dependency-conditioned execution, and aggregation. Figure 1: Overview of the task-oriented multi-agent framework. A composite query is decomposed into isolated intents and typed tasks with explicit dependencies. Specialized agents execute the tasks, and the terminal intent results are aggregated into the final response. The Manager Agent recognizes ordered intents, constructs typed tasks and same-intent dependencies, routes tasks by type, maintains intent-local results, and aggregates terminal results in query order. Query, Analyse, and Advice Agents execute tasks within these boundaries, preventing unrelated intermediate results from entering their context. 3.3 Multi-Intent Recognition and Explicit Task Decomposition Intent recognition separates distinct user requests into isolated intent-local workflows while preserving each request’s temporal range, indicators, and other constraints. For example, a question about three-week changes in atrial fibrillation, exercise, and sleep followed by joint analysis and advice yields three Query Intents, one Analyse Intent, and one Advice Intent; the shared time range is copied into every affected description. Decomposition receives only (κj,textj)( _j,text_j) and generates the current intent’s retrieval, analysis, or advice operations. Even when intents require the same data, their task structures and dependencies remain separate. An Advice Intent does not reuse intermediate results from a separate Query Intent. When record evidence is required, its task sequence contains a new intent-local Query Task, and the terminal Advice Task explicitly depends on that task’s result. This preserves intent isolation while allowing advice generation to use evidence retrieved for the advice request itself. Explicit dependencies represent data relationships among tasks within an intent. For the current task tm(j)t_m^(j), the framework collects the predecessor results specified by Dm(j)D_m^(j): m(j)=((,,,,,))1≤p<midp(j)∈Dm(j),P_m^(j)= ( (id_p^(j),desc_p^(j),r_p^(j) ) )_ subarrayc1≤ p<m\\ id_p^(j)∈ D_m^(j) subarray, (6) The ordered triples in Eq. (6) retain source identifiers and task descriptions with their results; Dm(j)=∅D_m^(j)= implies m(j)=∅P_m^(j)= . In the preceding example, three Query Tasks can feed one Analyse Task whose dependency set names all three identifiers. Tasks execute in generated order, but Dm(j)D_m^(j) determines which completed results the current task receives. 3.4 Agent Interface Contracts and Routing Table 2 defines the three execution agents and their input boundaries. Routing is deterministic by task type; ℬuB_u denotes the profile extracted from uD_u. Table 2: Deterministic mapping from task types to specialized agents and their input boundaries. Task Type Agent Primary Inputs and Responsibilities query Query Agent Complete task, user profile, and complete structured record; resolves temporal constraints from the task description, accesses records on target dates, and produces retrieval results. analyse Analyse Agent Complete task, user profile, and explicitly dependent predecessor results; performs longitudinal comparisons and organizes multi-indicator results. advice Advice Agent Complete task, user profile, and explicitly dependent retrieval evidence and analysis results; generates health-support advice consistent with the available information. The corresponding task-execution contracts are rm(j) r_m^(j) =QueryAgent(tm(j),ℬu,u), =QueryAgent (t_m^(j),B_u,D_u ), cm(j)=, c_m^(j)= query, (7) rm(j) r_m^(j) =AnalyseAgent(tm(j),ℬu,m(j)), =AnalyseAgent (t_m^(j),B_u,P_m^(j) ), cm(j)=, c_m^(j)= analyse, rm(j) r_m^(j) =AdviceAgent(tm(j),ℬu,m(j)), =AdviceAgent (t_m^(j),B_u,P_m^(j) ), cm(j)=. c_m^(j)= advice. Eq. (7) restricts uD_u to the Query Agent; the other agents receive only selected predecessors. After execution, y=Γ(q,ℛℐ),y= (q,R_I ), (8) where ℛℐR_I is the ordered terminal-result sequence defined in Section 3.9, and Γ is the final LLM-based response renderer. It organizes terminal results in the context of q without re-accessing uD_u and is instructed to use only the supplied terminal results without introducing unsupported record evidence. 3.5 End-to-End Dependency-Aware Execution Algorithm 1 instantiates the preceding representation and interfaces with an intent-local result store for each intent. ℛ(j)R^(j) denotes this intent-local result store. ValidateTaskGraphValidateTaskGraph checks task types, unique identifiers, valid same-intent predecessor references, empty Query-Task dependencies, and terminal-type consistency before execution. Thus, only listed same-intent predecessors reach downstream tasks, and only terminal intent results reach global aggregation. Algorithm 1 End-to-end dependency-aware execution. Input: Natural-language health query q and complete structured record uD_u Output: Final response y 1 ℬu←ExtractProfile(u)B_u (D_u); ℐ←RecognizeIntents(q)I (q); 2 Initialize intent-level result sequence ℛℐR_I; 3 for j=1,…,Nj=1,…,N do 4 (j)←DecomposeTasks(κj,textj)T^(j) ( _j,text_j); 5 ValidateTaskGraph((j))ValidateTaskGraph(T^(j)); 6 Initialize local result store ℛ(j)R^(j) for the current intent; 7 for m=1,…,Mjm=1,…,M_j do 8 if cm(j)=c_m^(j)= query then 9 rm(j)←QueryAgent(tm(j),ℬu,u)r_m^(j) (t_m^(j),B_u,D_u); 10 else 11 m(j)←CollectResults(Dm(j),ℛ(j))P_m^(j) (D_m^(j),R^(j)); 12 if cm(j)=c_m^(j)= analyse then 13 rm(j)←AnalyseAgent(tm(j),ℬu,m(j))r_m^(j) (t_m^(j),B_u,P_m^(j)); 14 else if cm(j)=c_m^(j)= advice then 15 rm(j)←AdviceAgent(tm(j),ℬu,m(j))r_m^(j) (t_m^(j),B_u,P_m^(j)); 16 else 17 raise invalid task type; 18 ℛ(j)[idm(j)]←rm(j)R^(j)[id_m^(j)]← r_m^(j); 19 r(j)←rMj(j)r^(j)← r_M_j^(j); append (ij,r(j))(i_j,r^(j)) to ℛℐR_I; 20 y←Γ(q,ℛℐ)y← (q,R_I); 21 return y; 3.6 Query Agent Figure 2 shows the Query Agent data flow from temporal resolution to structured retrieval, textual evidence, and an answer. Figure 2: Data flow of the Query Agent. A natural-language temporal constraint is resolved into a date sequence; the corresponding structured records are retrieved and textualized to produce a traceable result. Rather than prompting a single model to search the full textualized record, the Query Agent separates temporal resolution, indexed access, evidence textualization, and answer generation. For a complete Query Task, the pipeline is (dref,m(j)) (d_ref,d_m^(j) ) =DateResolve(tm(j)), =DateResolve (t_m^(j) ), (9) m(j) _m^(j) =QueryEngine(u,m(j)), =QueryEngine (D_u,d_m^(j) ), m(j) _m^(j) =Textualize(m(j)), =Textualize (X_m^(j) ), yQ,m(j) y_Q,m^(j) =QueryAnswer(tm(j),ℬu,m(j)), =QueryAnswer (t_m^(j),B_u,S_m^(j) ), rm(j) r_m^(j) =(m(j),yQ,m(j)). = (S_m^(j),y_Q,m^(j) ). Here, DateResolve infers reference date drefd_ref and target dates m(j)d_m^(j) from explicit, interval, or relative expressions in the task. QueryEngine retrieves ordered records m(j)X_m^(j), and Textualize preserves their dates, field semantics, and raw values in m(j)S_m^(j). QueryAnswer then produces yQ,m(j)y_Q,m^(j) from the task, profile, and evidence. Storing both m(j)S_m^(j) and the answer in rm(j)r_m^(j) exposes traceable evidence to explicitly dependent tasks without passing the complete record downstream. 3.7 Analyse Agent Under the contract in Eq. (7), the Analyse Agent receives the complete Analyse Task tm(j)t_m^(j), the extracted profile ℬuB_u, and only the predecessor results in m(j)P_m^(j). Each predecessor result retains its task identifier, task description, and returned evidence or answer, which allows the agent to associate each finding with the retrieval operation that supports it. The agent neither re-accesses uD_u nor introduces values outside the supplied results. The agent supports two complementary analysis modes. For a single indicator, it orders the supplied evidence by time and compares values or event frequencies across the requested periods to characterize increases, decreases, stability, or fluctuations. For a multi-indicator task, it organizes indicator-specific results under a shared temporal scope and synthesizes their observed patterns without interpreting co-occurrence as causal evidence. The processing flow is dependent results→evidence organization→temporal or multi-indicator comparison→findings.dependent results organization or multi-indicator comparison . The output is an ordered sequence of evidence-grounded findings, rm(j)=(fm,1(j),…,fm,Km(j)),r_m^(j)= (f_m,1^(j),…,f_m,K_m^(j) ), where KmK_m is the number of findings produced for task tm(j)t_m^(j). Each finding identifies the relevant indicators and temporal scope, states the observed comparison, and separates the supported conclusion from its interpretation limits. If the supplied evidence is incomplete, the agent reports the limitation rather than asserting a definitive trend. The result may become an explicit dependency of an Advice Task. 3.8 Advice Agent Under Eq. (7), the Advice Agent receives the complete Advice Task tm(j)t_m^(j), ℬuB_u, and selected Query or Analyse results in m(j)P_m^(j). The profile supplies demographic, lifestyle, and health-history context, whereas the dependency results constrain the recommendation to evidence relevant to the current intent; results from unrelated intents are excluded. The agent first identifies the observed evidence and the modifiable aspect addressed by the task. It then connects the observation to a rationale and a practical action. When supported by the evidence, the response also specifies an indicator to monitor or a time horizon for reviewing the observed pattern. This process is summarized as profile and dependent evidence→evidence interpretation and dependent evidence interpretation →personalized recommendation→action and monitoring guidance. recommendation and monitoring guidance. The output is an ordered recommendation sequence, rm(j)=(am,1(j),…,am,Lm(j)),r_m^(j)= (a_m,1^(j),…,a_m,L_m^(j) ), where LmL_m is the number of recommendations produced for task tm(j)t_m^(j). Each item communicates a recommendation and its evidence-based rationale, together with practical or monitoring guidance when supported. The Advice Agent provides general health support rather than clinical diagnosis or medical decision-making. It does not recommend changes to prescribed treatment, treats wearable measurements as supportive rather than clinical evidence, and uses conservative language when the available results are insufficient. Persistent or concerning patterns may be accompanied by a suggestion to seek professional assessment; the output does not replace professional judgment. 3.9 Result Aggregation For each intent iji_j, the terminal task is constructed to produce an intent-level result after consuming any explicitly required predecessors. A Query Intent terminates in a Query result, whereas an Analyse or Advice Intent terminates in the corresponding synthesized result. Intermediate task outputs remain in the intent-local store and are exposed only through the dependency sets defined in Eq. (6). Since cMj(j)=κjc_M_j^(j)= _j, the Manager Agent selects only the terminal result r(j)=rMj(j)r^(j)=r_M_j^(j) from each intent and preserves the recognized intent order: ℛℐ=((i1,r(1)),(i2,r(2)),…,(iN,r(N))).R_I= ((i_1,r^(1)),(i_2,r^(2)),…,(i_N,r^(N)) ). This order-preserving operation forms exactly one pair for each recognized intent; it does not vote over agents, merge intermediate evidence across intents, or alter the content of an agent result. Finally, Γ in Eq. (8) renders ℛℐR_I in the context of the original query q, maintaining the correspondence between each request and its response while preventing unrelated intent-local evidence from entering the final context. 4 Synthetic Wearable Dataset Construction Large-scale real-world wearable datasets with consistent longitudinal structure and annotations are difficult to obtain and raise substantial privacy concerns. We therefore construct a synthetic evaluation dataset through the two-stage pipeline in Figure 3: diverse virtual profiles are generated first and then condition longitudinal records. The dataset is not intended to reproduce disease prevalence, physiological distributions, or clinical progression, and supports no clinical or epidemiological inference. 4.1 Profile-Conditioned Data Generation Figure 3: Generation pipeline for the synthetic wearable health dataset. Virtual user profiles condition the generation of longitudinal wearable records, which are then organized into the evaluation dataset. The first stage generates 10,00010,000 profiles containing demographic, lifestyle, and health-history information. Each profile conditions the subsequent record generation. The second stage generates records for March 1–30, 2026. Dates for the same user share one profile context, whereas different users retain their respective conditions. At runtime, stable profile information and time-varying date-indexed records form uD_u, the Query Agent’s data source. The role field of uD_u corresponds to the extracted profile ℬuB_u, and data_s stores the daily records. 4.2 Longitudinal Wearable Data Structure The hierarchical record uD_u combines user-level demographics, lifestyle, and health history with daily entries indexed by datetime. Each entry contains sport_s, health_s, and activity_s; Table 3 summarizes their evaluation uses. Table 3: Primary components of the synthetic wearable dataset and their evaluation uses. Category Content Supported Tasks User profile Demographics, lifestyle, and health history Personalized query construction and user-context conditioning Exercise records Exercise time, type, duration, and calories burned Exercise retrieval and longitudinal change analysis Health monitoring Atrial fibrillation, premature heartbeat events, blood oxygen, and sleep apnea Health-event retrieval and temporal trend analysis Sleep information Sleep timing, duration, and quality score Sleep-duration and sleep-quality change analysis Daily activity Daily step count, sedentary episodes, and total calorie expenditure Daily activity retrieval and longitudinal trend analysis The sleep_stage field contains sleep onset, end time, duration, and quality score, but not fine-grained REM, deep, or light stages; evaluation therefore uses only sleep duration and quality. Records follow the Query Agent’s structured JSON format. Appendix D.3 shows a simplified structure, and the code provides the complete schema. 4.3 Scale, Quality Control, and Evaluation Use The monthly records cover exercise, health monitoring, sleep, and daily activity, supporting questions with varied temporal ranges, indicator combinations, and complexity. Pydantic models constrain generation; the pipeline then requires data_s and at least 20 daily records, otherwise regenerating records from the original profile. These checks cover only basic structure and count, not date continuity, field ranges, or physiological consistency (Section 6.4). As a synthetic evaluation dataset, it supports structured retrieval, multi-intent recognition, and multidimensional longitudinal analysis. Section 5 specifies sampling and metrics; Appendix D provides generation prompts and quality-control details. 5 Experiments 5.1 Experimental Setup All experiments use the 10,00010,000-user synthetic dataset in Section 4; each subsection specifies its sample and questions. All evaluated methods use deepseek-v4-pro at temperature 1.01.0. The Direct LLM baseline generates an answer from the query and the textualized complete record; our method performs intent recognition, decomposition, and specialized execution with the same model and inference configuration. For overall response quality, an independent invocation of deepseek-v4-pro at temperature 1.01.0 scores Trustworthiness, Transparency, and Actionability as specified in Section 5.4. Each answer is scored once and independently; the evaluator receives no method identity, and category means are computed over all instances in each question category. Figure 4 summarizes the three evaluation dimensions before the detailed protocols and metrics are introduced. Panel (a) compares structured-retrieval accuracy and query-stage token consumption; Panel (b) reports the Manager Agent’s absolute intent-recognition performance; and Panels (c)–(d) compare automatic response-quality scores on multi-intent and longitudinal questions. The figure provides a cross-experiment overview, while the following subsections and tables report the corresponding benchmark construction, metric definitions, and exact results. Figure 4: Overview of the main experimental results. Panel (a) shows that the Query Agent achieves comparable exact-value accuracy to Direct LLM while using fewer query-stage tokens; its accuracy axis is explicitly zoomed to 97.597.5–98.5%98.5\%. Panel (b) reports absolute Multi-Intent Coverage and Multiset Jaccard scores without an external structured-output baseline. Panels (c)–(d) report mean automatic Trustworthiness, Transparency, and Actionability scores on a 11–55 scale. The figure presents observed averages and does not imply statistical significance. 5.2 Query Agent Evaluation 5.2.1 Experimental Design The retrieval benchmark covers exercise count, atrial fibrillation, premature heartbeat events, sleep apnea, daily steps, calorie expenditure, and sedentary episodes. It uses single-day, continuous-window, and multi-period retrieval. For each of 300300 randomly sampled users, we select five topics, assign a temporal form, and personalize the wording with the user profile, yielding 1,5001,500 instances. References are derived from the structured records and manually reviewed. Both methods receive the same question and record. Direct LLM receives the textualized complete record, whereas the Query Agent retrieves target records through DateResolve and QueryEngine before QueryAnswer; the comparison therefore isolates data-access and context-construction strategies. 5.2.2 Metrics We evaluate retrieval correctness and token use. Query Accuracy For NQN_Q instances, let y^n y_n and yn∗y_n^* be the system and reference answers, and let ν(⋅)ν(·) extract the ordered target value sequence. Exact value equality defines Judge(y^n,yn∗)=[ν(y^n)=ν(yn∗)],Judge ( y_n,y_n^* )=I\! [ν\! ( y_n )=ν\! (y_n^* ) ], (10) where ν:→∗ν:Y ^* extracts an ordered sequence of target values from an answer in the answer space Y, and [⋅]I[·] is the indicator function. Thus, Eq. (10) ignores wording differences but requires the extracted numerical values and their order to match exactly. The overall metric is QueryAccuracy=1NQ∑n=1NQJudge(y^n,yn∗).Query\ Accuracy= 1N_Q _n=1^N_QJudge ( y_n,y_n^* ). (11) Eq. (11) averages the exact-value judgment over all retrieval instances. Token Consumption Average recorded token consumption characterizes model context under each access strategy. Because the pipelines invoke the model differently, it is a query-stage measure rather than end-to-end efficiency. 5.2.3 Results Table 4: Structured wearable-data retrieval results on N=1,500N=1,500 instances. Both methods use the same foundation model and underlying records. Token statistics cover only the current retrieval pipeline and do not represent end-to-end system cost. Method Query Accuracy Average Token Consumption Direct LLM 97.9% 6,869 Query Agent 98.3% 3,136 Across 1,5001,500 instances, Table 4 reports 97.9%97.9\% accuracy for Direct LLM and 98.3%98.3\% for the Query Agent; the 0.40.4-point difference is not tested for significance. Average token use is 6,8696,869 versus 3,1363,136, indicating less query-stage context for the Query Agent, not lower end-to-end system cost. 5.3 Manager Agent Multi-Intent Recognition Evaluation 5.3.1 Experimental Design The benchmark tests whether the Manager Agent recovers distinct intents, including repeated types, from C in Section 3.1. We define six representative intent-type combinations: query&query, query&analyse, query&advice, query&query&query, query&query&advice, and query&analyse&advice. For each of 3030 sampled users, an LLM generates all six combinations conditioned on the profile, yielding 180180 manually reviewed questions with annotated intent references. Only the predicted and reference intent-type lists are compared; decomposition, dependency construction, and specialized execution are outside this experiment. 5.3.2 Metrics We use Multi-Intent Coverage (MIC) for type coverage and Multiset Jaccard Similarity for repeated-type counts. Let the benchmark contain M≥1M≥ 1 instances. For instance n, let the predicted intent-type list and manually annotated reference list be Pn=(pn,1,…,pn,N^n),Gn=(gn,1,…,gn,Nn),P_n=(p_n,1,…,p_n, N_n), G_n=(g_n,1,…,g_n,N_n), where N^n N_n and Nn≥1N_n≥ 1 are the predicted and reference lengths. Multi-Intent Coverage (MIC) Following Godbole and Sarawagi (2004), let P¯n=set(Pn) P_n=set(P_n) and G¯n=set(Gn) G_n=set(G_n). Instance and macro MIC are MICn=|P¯n∩G¯n||G¯n|, _n= | P_n∩ G_n | | G_n |, (12) MIC=1M∑n=1MMICn. = 1M _n=1^MMIC_n. (13) Eq. (12) measures per-instance type coverage, and Eq. (13) reports its macro average. Because set conversion removes duplicates, MIC does not assess multiplicity. Multiset Jaccard Similarity Let cn,kpredc_n,k^pred and cn,kgoldc_n,k^gold count type k∈k in PnP_n and GnG_n. Multiset intersection and union use minimum and maximum counts (Ngo et al., 2021): Jn=∑k∈min(cn,kpred,cn,kgold)∑k∈max(cn,kpred,cn,kgold), J_n= _k (c_n,k^pred,c_n,k^gold ) _k (c_n,k^pred,c_n,k^gold ), (14) J=1M∑n=1MJn. J= 1M _n=1^MJ_n. (15) Eq. (14) preserves per-instance type multiplicity, and Eq. (15) reports its macro average. Both metrics range from 00 to 11. For reference [query, query, advice] and prediction [query, advice], MIC is 11 but Multiset Jaccard is 2/32/3; neither metric assesses intent order. 5.3.3 Results Table 5: Multi-intent recognition results for the Manager Agent on N=180N=180 questions. MIC measures intent-type coverage, while Multiset Jaccard Similarity preserves repeated-intent counts. Method MIC Multiset Jaccard Similarity Manager Agent 100.0% 94.4% Table 5 reports 100.0%100.0\% MIC and 94.4%94.4\% Multiset Jaccard across 180180 questions. Without an external baseline producing the same structure, these scores characterize absolute benchmark performance. 5.4 Overall Response-Quality Evaluation 5.4.1 Experimental Design We evaluate final responses on multi-intent questions, which require coverage of distinct requests, and multidimensional longitudinal-trend questions, which require comparison of several indicators over time. For 1010 sampled users, all six intent combinations yield 6060 multi-intent instances; the same 1010 manually designed trend questions are instantiated for each user, spanning exercise, daily activity, sleep, and health monitoring and yielding 100100 more instances. All 160160 question instances are manually checked to ensure that their temporal ranges and target indicators are supported by the corresponding records. Both methods use the same query, record, model, and automatic protocol. The evaluator sees only the query and final response, not method identity or intermediate state. Appendix A provides the rubric and protocol. 5.4.2 Metrics An LLM assigns separate 1–5 scores for Trustworthiness (evidence and its link to conclusions), Transparency (clarity from data to conclusion), and Actionability (specific and useful advice); we report category means without combining dimensions. Because the evaluator lacks the structured record, Trustworthiness measures evidence presentation and evidence–conclusion linkage, not independent factual consistency; Query Accuracy evaluates numerical retrieval separately. Actionability on non-advice questions is interpreted relative to the task objective. 5.4.3 Results Table 6: Automatic overall response-quality evaluation on N=60N=60 multi-intent questions (1–5; higher is better). Method Trustworthiness Transparency Actionability Direct LLM 3.5 3.1 3.2 Our method 3.8 3.9 3.0 Table 7: Automatic overall response-quality evaluation on N=100N=100 multidimensional longitudinal-trend questions (1–5; higher is better). Method Trustworthiness Transparency Actionability Direct LLM 4.3 3.9 1.6 Our method 4.5 4.1 1.7 On multi-intent questions, Table 6 reports respective Trustworthiness, Transparency, and Actionability scores of 3.83.8, 3.93.9, and 3.03.0 for our method, versus 3.53.5, 3.13.1, and 3.23.2 for Direct LLM. On longitudinal trends, Table 7 reports 4.54.5, 4.14.1, and 1.71.7 versus 4.34.3, 3.93.9, and 1.61.6. Trustworthiness and Transparency are higher for our method in both categories, whereas Actionability does not improve consistently. 6 Discussion We interpret the results through structured data access, multi-intent organization, and final response quality. Because the evaluation lacks complete component-level ablations, the observed patterns characterize the framework rather than the effects of individual modules. 6.1 Structured Data Access and Context Construction Both methods achieve high retrieval accuracy but construct the model context differently. Direct LLM jointly resolves time, locates data, and generates an answer from the complete record, whereas the Query Agent resolves dates before accessing target records through temporal indices and structured fields. Its lower token use in Table 4 therefore reflects task-relevant query-stage context construction, not stronger language-model reasoning or lower end-to-end cost. Because the accuracy difference is small and has not been tested for statistical significance, the evidence supports only comparable accuracy with less retrieval context. 6.2 Multi-Intent Recognition and Task Organization The gap between Multi-Intent Coverage and Multiset Jaccard Similarity in Table 5 indicates reliable type coverage but remaining errors in the multiplicity of repeated intent types. Neither metric evaluates intent boundaries, textual spans, or relative order; intent-level Exact Match, order consistency, and content matching would provide a finer-grained assessment. After recognition, explicit same-intent dependencies make the execution structure inspectable and restrict downstream contexts to selected predecessor results. However, the recognition experiment ends before task decomposition, and no ablation isolates dependency construction. Its contribution therefore remains a design property rather than an independently verified source of performance gain. 6.3 Final Response Quality and Health Advice The higher mean Trustworthiness and Transparency scores in Tables 6 and 7 are consistent with the framework’s explicit organization of requests, evidence, and analytical outputs. In particular, the larger Transparency difference on multi-intent questions suggests that intent-level organization can help connect indicator-specific evidence to the corresponding explanations. This interpretation is not causal because the current evaluation does not isolate decomposition, specialized execution, or aggregation. The evaluator sees only the user query and final response. Trustworthiness thus measures evidence presentation and evidence–conclusion linkage rather than independent factual consistency with the structured record; underlying-value access is assessed separately by Query Accuracy. Actionability does not improve consistently. Potential factors include the Advice Agent’s lack of explicit modeling for user preferences, practical constraints, and longitudinal feedback, as well as the inclusion of trend questions that do not request an action. Future evaluation should report Actionability separately for questions with an advice intent and assess advice for evidence consistency, specificity, personalization, and executability. 6.4 Limitations The synthetic monthly records provide controlled structured inputs but may not reflect real user distributions, long-term variation, or physiological relationships. Current quality control verifies the top-level structure and a minimum record count, not complete date continuity, field ranges, or cross-indicator consistency. The experiments therefore evaluate task organization and data processing rather than clinical effectiveness or performance over quarterly and annual records. The comparison scope is also limited. Multi-intent recognition lacks an external structured-output baseline, the framework has not undergone component-level ablation, and all methods use one foundation model. Consequently, the results do not separately quantify the contributions of recognition, dependency construction, or individual agents, nor establish cross-model generalization. Finally, overall response quality relies on LLM-based evaluation, whose preferences and scoring variability may affect the results. The evaluator cannot independently verify the underlying health values, and human expert assessment remains necessary. Efficiency is likewise limited to query-stage token use rather than model invocations, end-to-end latency, or cost. Future work should address these limitations with real or de-identified long-term data, component ablations, cross-model experiments, expert evaluation, and complete system-level efficiency measurements. 7 Conclusion We presented a task-oriented multi-agent framework for complex longitudinal health queries over wearable data. The framework organizes execution around user intents and executable tasks. A Manager Agent performs multi-intent recognition, fine-grained task decomposition, and explicit dependency construction, then invokes the Query, Analyse, or Advice Agent according to task type for structured retrieval, longitudinal multi-indicator analysis, or health advice generation. Intents maintain isolated task structures and local execution states before the Manager Agent aggregates their results. On the synthetic wearable health dataset, the framework supports structured retrieval, multi-intent recognition, and evidence-organized final responses. The results indicate that task-relevant record access can reduce query-stage context while maintaining high retrieval accuracy, and that explicit intent organization can preserve repeated request types. The response-quality results favor our method in mean Trustworthiness and Transparency but not consistently in Actionability. The current evidence is limited to monthly synthetic data and automatic evaluation and lacks a structured multi-intent baseline and component ablations. Future work will use real long-term data, cross-model experiments, human expert evaluation, and end-to-end efficiency analysis to examine generalization and isolate the contribution of each component. References Fang et al. (2024) C. M. Fang, V. Danry, N. Whitmore, A. Bao, A. Hutchison, C. Pierce, and P. Maes PhysioLLM: supporting personalized health insights with wearables and large language models. In 2024 IEEE EMBS International Conference on Biomedical and Health Informatics (BHI), p. 1–8. Cited by: §2.1. Godbole and Sarawagi (2004) S. Godbole and S. Sarawagi Discriminative methods for multi-labeled classification. In Pacific-Asia conference on knowledge discovery and data mining, p. 22–30. Cited by: §5.3.2. Heydari et al. (2025) A. A. Heydari, K. Gu, V. Srinivas, H. Yu, Z. Zhang, Y. Zhang, A. Paruchuri, Q. He, H. Palangi, N. Hammerquist, et al. The anatomy of a personal health agent. arXiv preprint arXiv:2508.20148. Cited by: §2.2. Hong et al. (2024) S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, J. Wang, C. Zhang, Z. Wang, S. K. S. Yau, Z. Lin, L. Zhou, C. Ran, L. Xiao, C. Wu, and J. Schmidhuber MetaGPT: meta programming for a multi-agent collaborative framework. In International Conference on Learning Representations, Cited by: §2.3. Khasentino et al. (2025) J. Khasentino, A. Belyaeva, X. Liu, Z. Yang, N. A. Furlotte, C. Lee, E. Schenck, Y. Patel, J. Cui, L. D. Schneider, R. Bryant, R. G. Gomes, A. Jiang, R. Lee, Y. Liu, J. Perez, J. K. Rogers, C. Speed, S. Tailor, M. Walker, J. Yu, T. Althoff, C. Heneghan, J. Hernandez, M. Malhotra, L. Stern, Y. Matias, G. S. Corrado, S. Patel, S. Shetty, J. Zhan, S. Prabhakara, D. McDuff, and C. Y. McLean A personal health large language model for sleep and fitness coaching. Nature Medicine 31 (10), p. 3394–3403. External Links: Document Cited by: §2.1. Li et al. (2026) H. Li, J. Deng, T. Jin, J. Han, Y. Wang, Z. Wang, Q. Si, W. Gong, X. Zhuang, J. You, W. Cheng, J. Feng, and H. Guo A self-evolving agent for longitudinal personal health management. arXiv preprint arXiv:2607.13940. External Links: Document Cited by: §2.2. Liu et al. (2024a) F. Liu, Z. Li, H. Zhou, Q. Yin, J. Yang, X. Tang, C. Luo, M. Zeng, H. Jiang, Y. Gao, et al. Large language models in the clinic: a comprehensive benchmark. arXiv preprint arXiv:2405.00716. Cited by: §1. Liu et al. (2026) W. Liu, S. Qi, L. Zhang, L. T. Car, and Y. He HiMe: real-time self-hosted personal agent platform for health insights with wearable devices. arXiv preprint arXiv:2607.21019. External Links: Document Cited by: §2.2. Liu et al. (2024b) Z. Liu, Y. Zhang, P. Li, Y. Liu, and D. Yang A dynamic LLM-powered agent network for task-oriented agent collaboration. In First Conference on Language Modeling, Cited by: §2.3. Merrill et al. (2026) M. A. Merrill, A. Paruchuri, N. Rezaei, G. Kovacs, J. Perez, Y. Liu, E. Schenck, N. Hammerquist, J. Sunshine, S. Tailor, et al. Transforming wearable data into personal health insights using LLM agents. Nature Communications 17 (1), p. 1143. Cited by: §2.2. Ngo et al. (2021) V. M. Ngo, S. Helmer, N. Le-Khac, and M. Kechadi Structural textile pattern recognition and processing based on hypergraphs. Information Retrieval Journal 24 (2), p. 137–173. Cited by: §5.3.2. Singhal et al. (2025) K. Singhal, T. Tu, J. Gottweis, R. Sayres, E. Wulczyn, M. Amin, L. Hou, K. Clark, S. R. Pfohl, H. Cole-Lewis, et al. Toward expert-level medical question answering with large language models. Nature Medicine 31 (3), p. 943–950. Cited by: §1. Wang et al. (2024) L. Wang, Z. Wan, C. Ni, Q. Song, Y. Li, E. Clayton, B. Malin, and Z. Yin Applications and concerns of ChatGPT and other conversational large language models in health care: systematic review. Journal of Medical Internet Research 26, p. e22769. Cited by: §1. Wang et al. (2025) X. Wang, J. Griffith, D. A. Adler, J. Castillo, T. Choudhury, and F. Wang Exploring personalized health support through data-driven, theory-guided LLMs: a case study in sleep health. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems, p. 1–15. External Links: Document Cited by: §2.1. Wu et al. (2024) Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu, A. H. Awadallah, R. W. White, D. Burger, and C. Wang AutoGen: enabling next-gen LLM applications via multi-agent conversations. In First Conference on Language Modeling, Cited by: §2.3. Yao et al. (2023) S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao ReAct: synergizing reasoning and acting in language models. In International Conference on Learning Representations, Cited by: §2.3. Zhang et al. (2026) Y. Zhang, T. Xia, B. Emmerich, Y. Y. Wu, D. Spathis, X. Liu, D. McDuff, and C. Mascolo WEQA: wearable health question answering with query-adaptive agentic reasoning. arXiv preprint arXiv:2606.18147. External Links: Document Cited by: §2.1. Appendix A Automatic Overall Response-Quality Evaluation A.1 Scoring Rubric Automatic evaluation scores Trustworthiness, Transparency, and Actionability on the following 1–5 rubric. Table 8: Rubric for automatic evaluation of overall response quality. Dimension Score Evaluation Criterion Trustworthiness 1 No supporting health evidence is provided. 2 The supporting evidence is vague. 3 One supporting health indicator is provided. 4 Multiple supporting health indicators are provided. 5 Multiple supporting health indicators are provided with explicit reasoning linkage. Transparency 1 Only the conclusion is provided without explanation. 2 A simple explanation is provided. 3 A partial evidence-to-conclusion rationale is presented. 4 A complete evidence-to-conclusion rationale is presented. 5 A complete evidence-to-conclusion rationale is presented with explicit evidence sources. Actionability 1 No recommendation is provided. 2 A vague recommendation is provided. 3 A general recommendation is provided. 4 A specific recommendation is provided. 5 A personalized and executable recommendation is provided. A.2 Evaluation Protocol For each instance, the evaluator receives the user question and one final answer, applies the rubric in Table 8, and returns the three integer scores together with a brief rationale in JSON. The evaluator is not given the method identity, intermediate task results, or the underlying structured record. The exact executable prompt is released with the code at https://github.com/yangkunpeng-coder/WearableDeviceAgents. Appendix B Multi-Agent System Prompts This appendix summarizes the prompt interfaces used by the main LLM components. The exact executable prompts and Pydantic schemas are released with the open-source code. The implementation and the paper consistently use analyse as the machine-readable type value and Analyse Agent in prose. The base_info field is deterministically parsed from the role field in uD_u and corresponds to ℬuB_u. Manager Agent. The recognition prompt maps a question to an ordered list of intent types and self-contained descriptions while preserving shared constraints. The decomposition prompt maps each intent to an ordered task list containing identifiers, types, descriptions, and same-intent predecessor dependencies. Query Agent. The date-resolution prompt infers the reference date and target dates from the complete Query Task. After deterministic record access and textualization, the answer prompt maps the complete task, user profile, and retrieved evidence to a natural-language task result. Analyse and Advice Agents. Both prompts receive the complete task, user profile, and explicitly selected predecessor results. The Analyse Agent organizes longitudinal or multi-indicator evidence; the Advice Agent produces general health-support recommendations grounded in that evidence. Result aggregation. The aggregation prompt receives the original question and ordered intent-level results, then produces one response that covers every recognized request without accessing the underlying record again. Appendix C System Implementation Details This section delineates the implementation boundaries among large language models, deterministic procedures, and structured data access. LLMs perform semantic interpretation and text generation; program logic handles agent selection, dependency resolution, and state management; and structured interfaces directly retrieve the underlying records. C.1 System Components and Implementation Boundaries Table 9 summarizes the inputs, outputs, and implementation of the principal components. The system deterministically selects a specialized agent according to task_type. Table 9: Principal components of the multi-agent system and their implementations. Component Implementation Input Output ExtractProfile Deterministic Complete structured user record uD_u User profile ℬuB_u RecognizeIntents LLM Original user question Intent types and self-contained descriptions ordered as in the original question DecomposeTasks LLM Current intent type and description Ordered tasks with identifiers, types, descriptions, and explicit dependencies Agent Selection Deterministic Current task’s task_type Query Agent, Analyse Agent, or Advice Agent CollectResults Deterministic Current task’s dependencies and local results for the current intent Predecessor results on which the current task actually depends DateResolve LLM Complete Query Task Inferred reference date and target date sequence QueryEngine Structured Data Access Target date sequence and structured wearable record Raw structured records for the target dates Textualize Deterministic Structured records returned by the Query Engine Textual evidence retaining dates, field semantics, and raw values QueryAnswer LLM Query Task, user profile, and textualized evidence Natural-language answer to the current Query Task AnalyseAgent LLM Analyse Task, user profile, and explicit dependency results Longitudinal comparison or multi-indicator analysis AdviceAgent LLM Advice Task, user profile, and explicit dependency results Health-support recommendations based on available health information Aggregate LLM Original user question and intent-level results in the original intent order Complete user-facing answer Table 9: Principal components of the multi-agent system and their implementations (continued). Components marked as LLM perform natural-language understanding or generation. The remaining components use deterministic procedures or structured data access; the LLM does not generate the underlying health measurements. C.2 Runtime Data Flow Each intent maintains an intent-local task sequence and result store. A Query Task has no predecessors. Analyse and Advice Tasks receive only same-intent predecessor results explicitly listed in dependencies through CollectResults; unspecified results and state from other intents are excluded from their context. The Query Agent follows Eq. (9): DateResolve and QueryAnswer are LLM-based, whereas QueryEngine and Textualize are deterministic. Each task result is stored under its task_id, and the result of a terminal task becomes the intent-level result. Once all intents have been processed, the Manager Agent aggregates these results in the order of the original question without accessing the underlying records again. Appendix D Synthetic Wearable Data Generation Details This appendix describes profile generation, longitudinal record generation, the data structure, and quality checks for the synthetic dataset. The complete JSON Schema is defined in code using Pydantic. D.1 Synthetic User Profile Generation Synthetic user profiles are first generated by an LLM and then used to condition longitudinal wearable-record generation. The implementation uses deepseek-chat at temperature 1.51.5; this data-generation model is distinct from the deepseek-v4-pro model used in the experiments. Each profile contains demographic information, lifestyle information, and medical history. The generation instructions request a relatively balanced distribution across age groups and require approximately 50% of users to have at least one of atrial fibrillation, premature heartbeats, sleep apnea, or insufficient sleep duration. The exact executable profile-generation prompt is provided in the open-source code. Each synthetic user profile contains the following fields: • name_id: unique identifier of the synthetic user; • demographic_information: demographic information; • lifestyle: lifestyle information; and • medical_history: medical history. The generation script targets 10,000 users and creates profiles in batches. After all batches have completed, their outputs are merged and name_id values are reassigned sequentially. D.2 Longitudinal Wearable-Record Generation After profile generation, the system generates longitudinal wearable records conditioned on the user’s demographic, lifestyle, and medical-history fields. The implementation uses deepseek-chat at temperature 1.51.5. The experimental code sets the record-generation interval to 2026-03-01 through 2026-03-30. The exact executable wearable-record generation prompt is provided in the open-source code. Here, day_num is calculated from the interval between the start and end dates; start_datetime and end_datetime denote the start and end dates of record generation, respectively. Demographic information, lifestyle, and medical history from the user profile are supplied directly as prompt conditions so that the generated longitudinal records reflect the background of each synthetic user. The generated output is constrained by the Pydantic-defined DataListForm; each date is associated with exercise, health-monitoring, and daily-activity records. D.3 Data Structure and JSON Schema The synthetic data use the date as the basic record unit, and each record contains sport_s, health_s, and activity_s. A simplified JSON structure is shown below; the complete object definitions are available in the open-source code. Listing 1: Simplified JSON structure of the synthetic wearable data. ⬇ "role": "name_id": "<integer>", "demographic_information": "<string>", "lifestyle": "<string>", "medical_history": "<string>" , "data_s": [ "datetime": "Y-M-D", "sport_s": ["<exercise records>"], "health_s": ["<health and sleep records>"], "activity_s": ["<daily activity records>"] ] The complete JSON object corresponds to the structured user record uD_u. The role field represents the user profile, whereas data_s contains the longitudinal wearable records organized by date. Their relationship to the notation in the main text is u↔role,data_s,ℬu↔role.D_u \ role, data\_s\, _u role. Exercise records contain start and end times, exercise type, duration, and calories. Health records contain fields for atrial fibrillation, premature heartbeat events, blood oxygen, sleep apnea, and sleep. Activity records contain step count, sedentary-event count, and total calories. The open-source schema provides the complete field types and constraints. D.4 Data Quality Checks During generation, Pydantic data models first constrain the LLM’s structured output. A longitudinal record is saved only if the generated object contains a data_s field, preventing outputs that do not conform to the target top-level structure from being written directly to the final data file. After generation, the code performs a record-completeness check. It first verifies the presence of data_s; users without this field are marked as having a format error. It then counts the dated records in data_s; users with fewer than 20 records are marked as having an abnormal record count. For users with too few dated records, the code repeats the generation process using the original user profile and the same longitudinal data-generation procedure. The current post-processing checks cover only the top-level JSON structure and the number of dated records. Section 6.4 discusses the resulting data-quality limitations. Appendix E Evaluation Dataset Examples This appendix provides representative questions from the evaluation tasks to illustrate their formats and complexity. E.1 Structured-Data Query Examples Table 10 presents representative questions from the structured-data query evaluation set. Each question is associated with the structured wearable records of one synthetic user and requires access to data for the specified time range and health indicators. The set includes single-date queries, continuous-range queries, joint queries over noncontiguous dates, multiple-range queries, and queries requiring aggregation of multiple results. Table 10: Examples of structured wearable data queries. Query Type Role ID Example Question Single date 5 Total steps on March 16th, 2026. Continuous range 14 How many times was atrial fibrillation detected between March 13th, 2026 and March 21st, 2026? Noncontiguous dates 2 The total number of times I sat for long periods on March 8th, 9th, 10th, 12th, 17th, 19th, 27th, and 29th, 2026. Multiple ranges 13 Total calories for the 28 days: March 1–18 and March 21–30, 2026. Multiple-result aggregation 3 On these 19 days: March 2, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 21, 23, 25, 26, and 29, 2026 — how many times and how long did you exercise in total? These examples span daily activities and health events, as well as several temporal and output structures: single dates, continuous intervals, noncontiguous dates, multiple intervals, and aggregation of multiple results. E.2 Multi-Intent Question Examples Table 11 presents six representative question types for the same synthetic user from the multi-intent recognition evaluation set. Each role_id is associated with six predefined intent-type combinations: query, query, query, advice, query, analyse, query, query, query, query, query, advice and query, analyse, advice. These combinations evaluate whether the Manager Agent can identify multiple distinct user intents in a single complex health question and recover their types and multiplicities. Table 11: Examples of multi-intent recognition questions. Role ID Intent Types Example Question 1 query, query Can you tell me what exercise sessions I did on 2026-03-09, including duration and calories burned for each, and also report my sleep duration and sleep score on 2026-03-08? 1 query, advice Could you tell me which days in March I had detected premature heartbeats, and based on my stress-related headaches and caffeine intake, what advice can you give me to lower my premature heartbeat risk? 1 query, analyse Can you give me my total steps and sleep score for 2026-03-01, and then analyze how my weekly exercise volume relates to my sleep quality across the whole month? 1 query, query, query Can you tell me my running exercise duration and calories burned on 2026-03-01, my total sleep duration and sleep score on 2026-03-08, and my total steps and sedentary periods on 2026-03-15? 1 query, query, advice Hey assistant, on 2026-03-15, how many total steps did I take? Also, what were my sleep onset time, total sleep duration, and sleep score that day? Based on my overall monthly activity and sleep patterns, what advice can you give me to improve my sleep quality? 1 query, analyse, advice Can you tell me my total exercise time and average sleep score for March 1–7, analyze how the days with exercise compared to the no-exercise day affected my sleep, and advise whether I should schedule rest days differently to improve my sleep quality? Table 11: Examples of multi-intent recognition questions (continued). Each example contains two or three distinct intent instances. Here, query denotes a data-retrieval request, analyse denotes a request to analyze available health data, and advice denotes a request for health-support recommendations. The Intent Types column contains manually annotated reference intent types rather than the Task types generated during task decomposition. Accordingly, this evaluation measures the Manager Agent’s multi-intent recognition, including coverage of the reference types and consistency of repeated-intent counts; subsequent task decomposition and dependency construction are outside its evaluation scope. E.3 Multidimensional Longitudinal Trend Examples Table 12 presents the 10 representative questions used in the multidimensional longitudinal trend evaluation. They span one-, two-, and three-week intervals as well as a full month, and cover exercise, daily activity, sleep, and health-monitoring indicators. Table 12: Examples of multidimensional longitudinal trend analysis questions. ID Time Range Example Question Q1 1 week What changes occurred in my daily step count over the past week? How did my daily exercise frequency change? How did my daily atrial fibrillation events change? Q2 1 month What changes occurred in my weekly total step count over the past month? How did my weekly exercise frequency change? How did my weekly premature heartbeat events change? Q3 2 weeks Over the past two weeks, how did my daily sleep apnea events change? How did my weekly total step count change? How did my daily sleep duration change? Q4 1 month Over the past month, how did my weekly exercise duration change? How did my weekly sleep quality score change? How did my weekly atrial fibrillation event frequency change? Q5 3 weeks Over the past three weeks, how did my daily premature heartbeat events change? How did my daily calories burned through exercise change? How did my daily sleep duration change? Q6 1 month Over the past month, what was the trend of my weekly step count? How did my weekly sedentary time change? Do these changes indicate a change in my activity level? Q7 2 weeks Over the past two weeks, how did my daily sleep duration and sleep quality change? At the same time, did my premature heartbeat events change? Q8 1 month Over the past month, how did my weekly exercise frequency, sleep quality, and cardiac health indicators change respectively? Considering these indicators together, do they suggest any changes in my overall health status? Q9 3 weeks Over the past three weeks, how did my daily atrial fibrillation events, premature heartbeat events, and sleep apnea events change? Do these abnormal events show an increasing trend? Q10 1 month Over the past month, what long-term trends can be observed in my exercise patterns, sleep patterns, and daily activity levels? Do these changes indicate any health risks that require attention? Table 12: Examples of multidimensional longitudinal trend analysis questions (continued).