Paper deep dive

Latent Preference Modeling for Cross-Session Personalized Tool Calling

Yejin Yoon, Minseo Kim, Taeuk Kim

Year: 2026Venue: arXiv preprintArea: cs.CLType: PreprintEmbeddings: 92

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 98%

Last extracted: 6/21/2026, 9:54:07 AM

Summary

The paper introduces MPT (Multi-Session Personalized Tool Calling), a benchmark designed to evaluate an LLM-based agent's ability to infer latent user preferences from multi-session interaction histories to complete under-specified API arguments. The authors identify three core challenges: Preference Recall, Preference Induction, and Preference Transfer. To address these, they propose PREFINE, a memory-augmented method that treats user preferences as evolving hypotheses. PREFINE utilizes a generate-verify-refine loop to extract reusable, abstract constraints from interaction history, allowing for more efficient and accurate tool calling compared to full-history prompting.

Entities (6)

Hanyang University · organization · 100%Latent Preference · concept · 100%MPT · benchmark · 100%PREFINE · method · 100%Schema-Guided Dialogue (SGD) · dataset · 100%Yejin Yoon · author · 100%

Relation Signals (4)

Yejin Yoon → affiliatedwith → Hanyang University

confidence 100% · Yejin Yoon ∗ ... Hanyang University, Seoul, Republic of Korea

MPT → builton → Schema-Guided Dialogue (SGD)

confidence 100% · We build MPT on top of Schema-Guided Dialogue (SGD; Rastogi et al. (2020))

MPT → evaluates → Latent Preference Modeling

confidence 100% · To evaluate latent preference modeling (§3), we introduce Multi-Session Personalized Tool-Calling (MPT)

PREFINE → uses → generate-verify-refine loop

confidence 100% · PREFINE 4 embodies this philosophy... through a generate–verify–refine loop

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Users often omit essential details in their requests to LLM-based agents, resulting in under-specified inputs for tool use. This poses a fundamental challenge for tool-augmented agents, as API execution typically requires complete arguments, highlighting the need for personalized tool calling. To study this problem, we introduce MPT, a benchmark comprising 265 multi-session dialogues that cover three challenges: Preference Recall, Preference Induction, and Preference Transfer. We also propose PRefine, a test-time memory-augmented method that represents user preferences as evolving hypotheses. Through a generate--verify--refine loop, it extracts reusable constraints from history and improves tool-calling accuracy while using only 1.24% of the tokens required by full-history prompting. These results indicate that robust personalization in agentic systems depends on memory that captures the reasons behind user choices, not just the choices themselves.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

91,671 characters extracted from source content.

Expand or collapse full text

Preprint. Under review. Latent Preference Modeling for Cross-Session Personalized Tool Calling Yejin Yoon ∗ Minseo Kim ∗ Taeuk Kim † Hanyang University, Seoul, Republic of Korea stillwithyou, er1123090, kimtaeuk@hanyang.ac.kr Abstract Users often omit essential details in their requests to LLM-based agents, resulting in under-specified inputs for tool use. This poses a fundamental challenge for tool-augmented agents, as API execution typically requires complete arguments, highlighting the need for personalized tool calling. To study this problem, we introduce MPT, a benchmark comprising 265 multi-session dialogues that cover three challenges: Preference Recall, Preference Induction, and Preference Transfer. We also propose PREFINE, a test-time memory-augmented method that represents user preferences as evolving hypotheses. Through a generate–verify–refine loop, it extracts reusable constraints from history and improves tool-calling accuracy while using only 1.24% of the tokens required by full-history prompting. These results indicate that robust personalization in agentic systems depends on memory that captures the reasons behind user choices, not just the choices themselves. 1 Introduction LLM-based agents increasingly rely on external tools to execute complex tasks, such as deep research (Xu & Peng, 2025) and computer use (Sager et al., 2026). In practice, users often omit essential details in their requests, making it challenging for agents to interact with tools that require fully specified arguments. To address this, a natural approach is to infer missing information from past user behavior, a central focus of personalized tool calling (Moghe et al., 2024; Xu et al., 2025). Figure 1 illustrates an intuitive example: consider a user who consistently chooses low-cost restaurants, free-entry attractions, and compact rental cars over prior sessions. When she later states, “Book a flight for my trip”, the agent should default toflight_class=Economyin the absence of explicit instructions. This goes beyond retrieving similar past actions, requiring modeling a latent preference: an implicit, persistent constraint on decision-making derived from recurring behavioral patterns. Interaction History + Current Query  USER: Restaurant for two tonight.→AGENT: Any cuisine preference?→USER: Korean, and make it cheap.  GetRestaurants(category="Korean", price_range="cheap", number_of_seats="2") ...  USER: Can you suggest places to visit this weekend?→AGENT: Prefer budget-friendly spots or popular spots? →USER: Cost first. Free-entry parks or tourist attractions in Seattle are best.  GetTravel(location="Seattle", category="Tourist Attraction", free_entry="True")  USER: Need a compact rental car in Seattle.→AGENT: What pickup date works for you?→USER: March 8.  GetRentalCars(pickup_city="Seattle", pickup_date="03-08", car_type="Compact") Current Session  USER: Book a flight for my trip.→AGENT: Where will you be flying from and to?→USER: London to Paris.  Explicit Args. origin="London"destination="Paris" Under-specified Args. flight_class = ? Predicted Tool Call  Preference Reasoning Needed The current session alone is incomplete for tool arguments. So, as induced by our prompt, the agent proactively fills missing args. by performing preference reasoning over the interaction history. User prefers budget-friendly options  Ground Truth Tool Call GetFlights( origin="London", destination="Paris", flight_class="Economy") ↑ Preference-inferred Args. Figure 1: Example of latent preference modeling for personalized tool calling. The agent predicts flight_class=“Economy”not from the current session, but from prior interactions, where the user consistently selects budget-friendly options in different contexts. ∗ Equal contribution. † Corresponding author. 1 arXiv:2604.17886v1 [cs.CL] 20 Apr 2026 Preprint. Under review. We argue that personalized tool calling is not merely a memory retrieval problem, but a reasoning problem centered on latent user-level constraints shaped by interactions over multiple sessions. Prior work (Schick et al., 2023; Huang et al., 2025) assumes that user preferences are directly available as user profiles, predefined instructions, or repeated actions within restricted cases. This setting is unrealistic: current agents are rarely provided with profiles and should operate across diverse tasks rather than within limited domains. A key capability of personalized tool-calling agents should thus be to reason over interaction history to capture implicit preferences distributed across noisy, unordered sessions. However, no existing benchmark focuses on this aspect, motivating a dedicated evaluation. To this end, we propose Multi-Session Personalized Tool Calling (MPT), a benchmark for evaluating personalized tool calling under multi-session interaction histories with intentionally under-specified API arguments. MPT introduces three challenges: (1) Preference Recall (direct reuse), (2) Preference Induction (aggregating cross-session evidence), and (3) Preference Transfer (generalizing to new domains). This taxonomy reveals a performance gap in predicting missing API arguments: models strong on Preference Recall via naïve reuse of prior decisions struggle on Induction and Transfer. We also present PREFINE, a lightweight test-time memory-augmented method that incrementally refines latent user preferences from multi-session interactions via a generate–verify–refine loop. These latent preferences serve as action-level constraints for tool calling and remain effective under changing tool schemas. Experiments show that retrieval-oriented baselines perform well on Preference Recall but degrade sharply on Induction and Transfer, whereas PREFINE improves tool-calling accuracy using only 1.24% of the tokens required by full-history prompting. These results indicate that robust personalization depends on capturing the reasons behind user choices, not just the choices themselves. 2 Related Work Personalized Tool Calling. Recent benchmarks for tool use evaluate an agent’s ability to invoke external APIs in multi-turn settings (Wang et al., 2024; Lee et al., 2024; Yao et al., 2025; Patil et al., 2025; Chakraborty et al., 2025), focusing on planning, failure recovery, and chained execution (Shim et al., 2025). However, they treat tool use as a decision process based solely on the current dialogue state, ignoring prior interactions. In contrast, some studies incorporate dialogue history, regarding user preferences as constraints on API arguments (Moghe et al., 2024; Xu et al., 2025). These approaches assume preferences are explicitly available (e.g., profiles or past API calls), leaving the more realistic setting—where preferences are implicit and must be inferred from interaction history—unaddressed. Latent Preference Modeling.A related line of research investigates how user preferences can be derived from interaction histories. In dialogue systems, methods such as PrefEval (Zhao et al., 2025), CUPID (Kim et al., 2025), and PersonaMem (Jiang et al., 2025a;b) learn user-specific preference representations for personalization. Conversational recommender systems similarly model user preferences as latent variables from behavioral signals across interactions, enabling generalization beyond observed choices (Luo et al., 2020; Chen et al., 2019; Zhou et al., 2020; Li et al., 2025). Our notion of latent preference is similar in spirit to prior work, as it concerns user-level regularities that are not explicitly stated. However, prior work typically treats such preferences as internal representations for scoring responses or items. In contrast, our setting requires latent preferences to be externalized as reusable textual constraints governing unspecified API arguments. Memory for Long-Horizon Agents. Research on agentic memory studies how agents maintain, retrieve, and update information over long horizons (Park et al., 2023; Packer et al., 2024; Shinn et al., 2023a; Wang et al., 2023; Wei et al., 2025), with work on multi-session collaboration (Mehri et al., 2026; He et al., 2026), memory compression (Liu et al., 2025), and memory policies (Zhou et al., 2025; Wang et al., 2026). Prior work (Kwon et al., 2023; Zhang et al., 2025) typically stores explicit, factual information in memory, whereas we abstract behavioral patterns into latent preferences. 2 Preprint. Under review. 3 Problem Definition 3.1 Task Definition LetS =s 1 , . . . , s T denote a sequence of past dialogue sessions between a single user and an AI agent, where each sessions t consists of a multi-turn dialogue in which the agent may execute one or more API calls. LetA ≤T denote the accumulated API call list from past sessionsS, preserving the raw executed tool invocations and their argument values across sessions. At timestepT+1, the agent observes the current query contextq—the sequence of user–agent turns in the current session up to the API decision point. The query may explicitly specify some API arguments while leaving others underspecified. The agent must output an API calla ∗ that satisfies all explicitly stated constraints inqand infer the remaining preference-driven arguments from latent preferences reflected in the interaction history (S,A ≤T ): a ∗ = arg max a∈A f θ (a| q, S,A ≤T ), wheref θ is an LLM-based decision function andAis the set of valid API call instantiations. Because the action space is bounded by predefined API schemas, our goal is not open-ended preference discovery but schema-aligned preference reasoning: identifying persistent argument-level constraints predictable from recurring behavioral patterns in interaction history. 3.2 Preference Modeling Types Difficulty in latent preference modeling depends on how evidence for a missing argument is distributed across the interaction history, leading to three distinct cases (see Figure 7 in Appendix A.5 for details). Preference Recall. The history contains clear recurring choices for the same argument–value pair within the same domain (e.g., repeatedly selectingGetFlights(flight_class=Economy)). In this case, the missing arguments can often be resolved by retrieving and reusing past choices. Preference Induction. In this configuration, the missing argument cannot be determined by direct reuse. The agent must aggregate behavioral evidence across interactions spanning tasks and domains. It then predicts a latent preference and instantiates it as concrete argument values. Preference Transfer. In this setting, the missing argument lacks in-domain evidence. The agent must apply a latent preference from other domains to guide argument selection in the target domain. 4 Dataset Construction: MPT To evaluate latent preference modeling (§3), we introduce Multi-Session Personalized Tool-Calling (MPT), 1 a benchmark pairing multi-session interaction histories with queries featuring intentionally under-specified API arguments. Each instance is designed to reflect one of the three problem types in §3.2. We build MPT on top of Schema-Guided Dialogue (SGD; Rastogi et al. (2020)), a multi- domain task-oriented dialogue corpus with API schemas. 2 SGD provides structured domain–slot– value representations grounding preferences at the level of executable tool arguments, and spans semantically related domains that naturally support the study of cross-domain preference consistency. Multi-Session Grouping. MPT is constructed in three stages, as illustrated in Figure 2. We first group multiple SGD sessions into a single multi-session dialogueS = s 1 , . . . , s T for one user. Preference signals emerge from repeated argument patterns within a domain and consistent cross- domain selection behavior, neither of which is fully captured in a single sessions t . For each dialogue, we accumulate per-session API calls into an API call listA ≤T , preserving the action trace from which latent preferences can be inferred. Together,SandA ≤T constitute the interaction history(S,A ≤T ). 1 https://huggingface.co/datasets/HYU-NLP/MPT 2 We keep the original schema definitions and apply schema normalization following the prior work (Moghe et al., 2024), enabling coherent multi-session histories while remaining compatible with the tool schemas. See Appendix A.1 for the full schema. 3 Preprint. Under review. Preference Annotation. In the second phase, we enable evaluation of latent preference modeling by manually grouping related API arguments into higher-level preference categories. Since SGD provides only domain–slot–value triples without preference labels, this process is key to assigning gold-standard annotations. Formally, a preference group consists of a set of preferences, each spanning diverse but related API–argument pairs. For instance, the BUDGET group contains two preferences: low_cost and high_cost. The low_cost preference covers API–argument pairs such asGetRestaurants(price_range=“cheap”)andGetTravel(free_entry=True). The full mapping table for 58 API–argument pairs is provided in Appendix A.2. Multi-Session Personalized Tool-Calling (MPT) 0. SGD individual sessions, 20k+ dialogues, 20 domains USER "Korean restaurant for two tonight" AGENT ...  GetRestaurants(..., price_range="cheap") USER "Sightseeing spots this weekend" AGENT ...  GetTravel(..., location="Seattle", free_entry="True") USER "Hotel near the conference venue" AGENT ...  GetHotels(..., location="Seattle", average_star="4") USER "Dinner reservation for tonight" AGENT ...  GetRestaurants(..., time="19:00", number_of_seats="2") USER "Rental car for the week" AGENT ...  GetRentalCars(..., pickup_city="Seattle", car_type="Compact") 1. MULTI-SESSION GROUPING  S = s₁, ..., s — multi-session dialogue sUSER "Korean restaurant for two tonight" AGENT ... sUSER "Sightseeing spots this weekend" AGENT ... · sUSER "Rental car for the week" AGENT ...  A — accumulated API call list s₁GetRestaurants(...,price_range="cheap") s₂GetTravel(...,free_entry="True") · s₇GetRentalCars(...,car_type="Compact") 2. PREFERENCE ANNOTATION cross-domain evidence Group: budget_conscious s₁GetRestaurants(...,price_range="cheap") s₂GetTravel(...,free_entry="True") s₇GetRentalCars(...,car_type="Compact") recurring behavioral constraint across domains 3. QUERY CONSTRUCTION context-guided query USER Book a flight for my trip. AGENT Where will you be flying from and to? USER London to Paris. Explicit args.: origin, destination Under-specified: flight_class = ? Inferred value: "Economy" T 1 2 7 ≤T Figure 2: Overview of MPT construction. Individual SGD sessions are grouped into a multi-session interaction history (S,A ≤T ), from which cross-domain preference evidence is annotated as shared behavioral constraints. Target queries are constructed by intentionally under-specifying preference- sensitive arguments. We validate the grouping annotations through a human study with 19 anno- tators (Appendix A.6), finding strong agreement for both budget (89.7%) and travel groups (97.4%), confirm- ing that our preference groups reflect commonsense. Because the groups are defined at the level of behav- ioral constraints rather than specific slot names, the scheme generalizes to tool calling with different schemas. In other words, any new API expos- ing cost- or party-size-related argu- ments falls under the same taxon- omy without redefinition, making the scheme broadly applicable beyond SGD, as verified in §7.5. Query Construction.For each do- main, we manually design query templates that omit one or more preference-related arguments. 3 Each MPT instance combines a target- domain queryqwith an interaction history (S,A ≤T ). We design two query types. Context-guided queries include in-session dialogue context that partially states explicit argument constraints. Context-free queries omit such information entirely, requiring the agent to rely solely on preference modeling to fill in missing arguments. This distinction lets us evaluate both preference-driven argument completion under partial in-session specification and preference modeling when the current query provides little guidance. We refer readers to Table 7 in Appendix A.5 for example queries. The preference modeling type for each instance is determined not byqalone but by the relationship between q and (S,A ≤T ) (Figure 1), allowing the same history to be paired with multiple queries. Dataset Statistics. MPT comprises 265 multi-session dialogues with 2,020 sessions and 39,884 turns, averaging 7.6 sessions per dialogue and 19.7 turns per session. It includes 332 Preference Recall instances, 293 Induction instances, and 472 Transfer instances(see Table 6 in Appendix A.3 and Appendix A.4 for details). Preference-relevant evidence is distributed across sessions rather than concentrated within any single interaction, making MPT particularly suited for distinguishing shallow action reuse from preference reasoning that requires abstraction over long interaction histories. 5 Proposed Method: PREFINE 5.1 Motivation A straightforward approach to personalized tool calling is to provide the full interaction history and let an LLM complete under-specified arguments end-to-end. However, access to long histories does not 3 We exclude time and location arguments in our setting as they are not directly related to user preferences. 4 Preprint. Under review. Session 1 s"Find cheap restaurants" a GetRestaurants(..., price_range="cheap"... Session 2 s"Find free attractions" a GetTravel(..., free_entry="True") · Session 7 s"Rent a compact car" a GetRentalCars(..., car_type="Compact") PRefine (Session 7) M(Session 6 memory)+s(Session 7 dialogue)+a(Session 7 tool call)→ Generator input Generator Proposes preference hypotheses hPrefers direct flights hPrefers budget-friendly options Refine Verifier Checks cross-session consistency ✗ RejecthSession-specific ✓ AccepthConsistent across sessions MEMORY h → M MFrequently visits local restaurants MRegularly explores local spots MPrefers budget-friendly options Preference-Aware Tool Call (Session 8) M(Session 7 memory)+s=q(Current session dialogue)→ Agent tool call input MEMORYM Prefers budget-friendly options Session 8 s  "Book a flight for my trip." Tool-Call Decision a — preference-inferred arg via M, not from q alone  GetFlights(origin="London", destination="Paris", flight_class="Economy") 1 1 2 2 7 7 677 (1) (2) (1) (2) (2) 7 1 2 7 78 7 8 * 7 Figure 3: PREFINE’sgenerate-verify-refineloop. At each sessionT+1(e.g., Session 7), candidate preference hypothesesh (i) are generated from the current dialogues T+1 , tool calla T+1 , and prior memoryM T (e.g.,M 6 ). Here,M T denotes the single preference hypothesis accepted at sessionTand is updated toM T+1 upon acceptance of a new hypothesis. The updated memory is then used to constrain tool-call decisions a ∗ in subsequent sessions (e.g., Session 8). reveal which past decisions reflect reusable user constraints and which are merely local or situational. As shown in §7.1, LLMs given full history often fail to abstract and apply the behavioral regularities needed to complete such decisions. This implies that personalized tool calling is not primarily a retrieval problem but an abstraction problem: the model must infer reusable constraints from repeated behavior and apply them to guide future argument selection. 5.2 Latent Preference as Hypotheses We view a latent preference as an implicit, persistent constraint on API argument selection expressed through recurring behavioral patterns. Such preferences may appear as repeated in-domain behavior (e.g., repeated selections offlight_class=“Economy”) or as cross-domain regularities (e.g., consistently choosing budget-oriented options across flights, restaurants, and hotels). Because they are not directly observed and often emerge only from evidence accumulated across sessions, latent preferences must be treated as hypotheses. A plausible hypothesis at one point may later become too narrow or contradicted by new evidence; preference modeling is therefore not a one-shot prediction, but an ongoing process of maintaining and updating beliefs about the user’s latent constraints. 5.3PREFINE: A Memory-Based System for Latent Preference Refinement As latent preferences are not directly observed, are only partially identified at each session, and may require revision as new evidence arrives, preference memory cannot be treated as a static store of episodes. Instead, it should function as a revisable hypothesis of preference constraints. PREFINE 4 embodies this philosophy, storing the current best abstraction of behavioral regularities supported by accumulated evidence and applicable to future tool use. Table 1 highlights the unique characteristics of PREFINE from multiple perspectives, including memory content and update mechanisms. MethodMemory ContentUpdate MechanismActionableLatent Preference-Aware RAGRaw utterancesStatic index✗ Mem0Extracted factsAppend/overwrite✗ LangMemStructured factsLLM rewrite✓✗ PREFINELatent constraints Generate-verify-refine✓ Table 1: Comparison of memory-augmented methods in terms of content and memory update mechanisms. PREFINE is the only method that stores latent preferences and refines them iteratively. Generate-Verify-RefineLoop.As shown in Figure 3, at sessionT+1, PREFINE takes as input the current dialogues T+1 , the executed API call(s), and the prior memoryM T —the single preference hypothesis accepted at sessionT. We implement the update fromM T toM T+1 as a generate–verify–refine loop, following self-refinement algorithms (Madaan et al., 2023; Shinn et al., 4 https://github.com/HYU-NLP/PRefine 5 Preprint. Under review. Sessiona t StepHypothesis (Generate, Refine) / Verdict (Verify) s 1 a 1 : GetMovies(average_rating = 6);GenerateUser prefers moderately rated movies. Verify[REJECT] Over-specific and unsupported abstraction. RefineUser prefers accessible movie content. Verify[REJECT] Insufficient evidence for future decisions. RefineUser has minimal interest in movies. Verify[PASS] Abstract and observation-supported. s 2 a 2 : GetWeather(city = San Francisco);GenerateUser prefers movies while engaging with other domains. Verify[REJECT] Failed to account for weather-domain interaction. RefineUser prioritizes movies but engages across domains. Verify[PASS] Cross-domain flexibility ensured. s 3 a 3 : GetRentalCars(car_type = Standard),GenerateUser prefers economical and simple options across domains. GetRestaurants(price_range = Cheap);Verify[PASS] Consistent cross-domain behavioral signal. s 4 a 4 : GetHotels(average_star = 1);GenerateUser prefers budget-friendly and simple interactions. Verify[PASS] Stable and memory-worthy preference. M 4 Budget-conscious and simple interaction style. [Inference Example] q: “I’d like to book a flight.”→ a ∗ : GetFlights(flight_class = Economy) Table 2: Example of preference modeling with PREFINE via thegenerate-verify-refine loop, where the verifier rejects over-specific hypotheses and retains generalizable abstractions. 2023b). This design is motivated by the nature of latent preferences: no single session fully determines the underlying constraint, and subsequent sessions may refine, broaden, or overturn earlier hypotheses. Specifically, a generator proposes candidate preference hypotheses (h (1) , h (2) , . . .) that explain the observed user actions at a more abstract level. A verifier then evaluates whether each candidate is admissible as preference memory under four validity conditions: 5 (1) Evidence Support, whether the hypothesis is grounded in multiple or mutually consistent interactions; (2) Abstraction Quality, whether it generalizes beyond a one-off event or a slot-level restatement; (3) Actionability, whether it can meaningfully bias or constrain future API argument selection; and (4) Temporal Consistency, whether it remains compatible with the most recent stable behavioral pattern. Otherwise, weak or narrow hypotheses are returned to the generator for refinement, where they are revised based on the verifier’s feedback. Table 2 illustrates how this process progressively transforms narrow session-level hypotheses into reusable cross-domain constraints as observations accumulate across sessions. Schema-Agnostic Preference Memory.A key property of PREFINE is that its memory is schema- agnostic. Rather than storing schema-specific API signatures, PREFINE retains abstract preference constraints that are usable for different tool interfaces. At sessionT+1, the inference model conditions on the current queryqtogether with the retained memoryM T , and grounds these abstract constraints to the API schema at test time. Because schema grounding is deferred to inference, memory built under one schema remains useful even when the test-time schema differs in slot names, argument inventories, or schema realizations. We evaluate this property in §7.5, with detailed dynamic-schema examples provided in Appendix C.6. 6 Experimental Setup Methods and Models.We evaluate all methods without additional training to assess test-time latent preference modeling for personalized tool calling. We compare PREFINE against four baselines: Base prompting, RAG (Lewis et al., 2020), Mem0 (Chhikara et al., 2025), and LangMem (LangChain AI, 2025), representing full-dialogue prompting, retrieval-based memory, summary-based memory, and agentic memory, respectively. Under Base prompting, the inference LLM receives full dialogue history together with the accumulated API list. RAG, Mem0, LangMem, and PREFINE replace the full dialogue history with method-specific memory, while keeping the same cumulated API list. Detailed experimental settings and model nomenclature are provided in Appendix B. To test the robustness of PREFINE to the choice of memory-construction model, we build individual preference memories with four base LLMs 6 and evaluate them with the eight inference LLMs reported 5 Detailed rubrics and prompts are provided in Appendix D. 6 Gemma-3-12B-IT, GPT-4o-mini, R1-Distill-Llama-8B, R1-Distill-Qwen-7B 6 Preprint. Under review. Context-Guided QueryContext-Free Query Pref. RecallPref. InductionPref. TransferAvg.Pref. RecallPref. InductionPref. TransferAvg. Base LLMP-EM EA-F1 OA-F1P-EMEA-F1OA-F1 P-EM EA-F1 OA-F1OA-F1 Prec. Rec.F1Prec.Rec.F1Prec. Rec.F1F1 BASE PROMPTING: Full-dialogue context CodeGemma-7B18.67 38.88 38.174.1032.7830.35 0.64 37.19 29.3732.63 19.63 67.31 30.3912.5354.2720.36 5.00 15.04 7.5019.42 Gemma-3-12B7.23 60.36 49.49 2.7357.6448.16 0.00 55.86 46.2246.95 47.78 38.78 42.8143.2438.2340.58 13.65 8.47 10.4632.66 R1-Distill-Llama-8B 34.94 65.12 61.0318.4362.6058.02 6.14 59.37 49.5756.21 32.29 71.47 44.4825.2470.6537.20 8.13 18.01 11.2130.96 R1-Distill-Qwen-7B 13.55 33.49 31.58 7.1727.8825.50 0.64 25.87 20.1225.73 21.12 56.51 30.7513.3344.3720.51 3.10 8.26 4.5118.59 GPT-4o-mini32.23 58.21 53.5418.4362.4657.34 4.87 61.98 48.9453.27 50.09 76.18 60.4442.3978.8455.13 16.10 27.12 20.2145.26 GPT-5-mini47.59 65.38 66.6923.2163.4661.78 11.65 61.09 52.2560.24 61.42 88.64 72.5644.6781.5757.73 19.95 36.0225.6851.99 GPT-551.20 62.33 64.7732.4265.3464.01 23.9464.27 55.4761.42 59.39 86.70 70.5043.2276.1155.13 19.25 31.36 23.8549.83 Gemini-3-Flash62.65 72.73 74.2528.6769.6666.4914.62 69.68 56.5465.7663.27 87.8173.5544.3281.2357.35 22.11 33.69 26.7052.53 Average33.5157.0654.9416.8955.2351.467.8154.4144.8144.3771.6853.1933.6265.6643.0013.4122.2516.26 MEMORY-AUGMENTED METHODS RAG (Top-5)50.60 69.14 67.9924.9167.6061.34 8.26 69.40 55.8861.74 52.42 60.11 56.0045.9870.3155.60 21.68 24.58 23.0444.88 Mem031.93 64.59 59.7927.9965.5262.05 16.31 65.93 54.8558.90 52.36 55.40 53.8448.5172.3558.08 25.59 27.75 26.6346.18 LangMem64.4064.54 67.8326.6269.1063.56 6.57 57.59 46.7959.40 69.25 86.70 77.0046.9067.2455.26 13.59 12.92 13.2548.50 PREFINE CodeGemma-7B59.6469.5070.5116.3865.8661.001.6167.2053.9761.8335.4081.2249.3130.5170.6540.807.4118.4310.5733.56 Gemma-3-12B20.4879.2869.275.6774.1163.240.2175.3863.5465.3576.1063.6669.3052.1057.5454.2812.676.368.4544.01 R1-Distill-Llama-8B42.0562.3561.6322.1262.0758.224.8352.2242.9554.2744.7271.3054.9528.8260.6839.089.2613.7711.0735.03 R1-Distill-Qwen-7B32.1759.0554.6017.2058.9351.203.6047.3837.8147.8736.0057.2344.1926.6949.1534.5810.8816.7413.1830.65 GPT-4o-mini49.8872.6568.7128.1270.7365.039.1969.9756.9963.5862.1166.7064.2550.2273.9959.7820.9223.0521.8448.62 GPT-5-mini51.4568.0368.0832.9767.7165.1621.0267.2358.4763.9073.2383.4377.9053.1876.7262.7929.5930.0029.6256.77 GPT-552.4166.7467.8537.9565.8764.8026.1967.2359.2963.9874.4682.9978.4154.8770.8561.8127.2128.1827.6455.95 Gemini-3-Flash64.8872.7674.7529.7669.9867.1718.8170.5559.6267.1871.4585.3777.7551.1082.0562.9530.9239.8734.8158.50 Avg. Gain (%p)13.1111.7311.996.8811.6810.522.8710.239.2714.812.3111.329.822.059.015.200.203.38 Average46.6268.8066.9223.7766.9161.9810.6864.6554.0859.1873.9964.5143.4467.7052.0118.6122.0519.65 Table 3: Performance comparison between baselines and PREFINE under context-guided and context- free query settings. Bold indicates the best performance, andunderlineindicates the second-best performance. Shaded cells indicate performance changes introduced by PREFINE relative to the LLM: green denotes gains and red denotes losses. The intensity of the shading reflects the magnitude of change (|∆| < 5: light,5 ≤ |∆| < 10: moderate,10 ≤ |∆| < 20: strong,|∆| ≥ 20: very strong). Exact numerical changes are reported in Appendix C.1. in Table 3, covering all 4×8 memory–inference model combinations. Table 3 reports the performance averaged over the four memory-construction models, for each inference LLM. For RAG, Mem0, and LangMem, we report only the best-performing backbone (Gemini-3-Flash) in Table 3, deferring the rest to Appendix C.4. For PREFINE, we cap thegenerate-verify-refineloop at three iterations. As shown in Appendix C.5, increasing the budget to ten iterations provides no consistent gain, despite higher inference cost, consistent with prior findings on iterative refinement in LLMs (Madaan et al., 2023; Huang et al., 2023). Metrics.In context-guided queries, the model must both extract explicitly stated arguments from the query context and fill in unspecified arguments. We report Preference Exact Match (P-EM), Explicit-Argument F1 (EA-F1), and Overall-Argument F1 (OA-F1). P-EM measures whether the model correctly predicts the preference-driven, yet unspecified arguments. EA-F1 measures tool- calling ability on explicitly specified arguments. OA-F1 evaluates over all arguments. For context-free queries, no argument values are explicitly mentioned, so the task isolates preference modeling itself. Here we report precision, recall, and F1 over the preference-driven argument completions. Overall, P-EM and the context-free query metrics capture latent preference modeling, EA-F1 reflects standard tool-call generation, and OA-F1 captures how well the model handles both. 7 Experimental Results 7.1 Existing Baselines Recover Observations but Not Latent Preferences As reported in Table 3, existing baselines are relatively strong in Preference Recall, where the correct action can be predicted by relying on previous actions. But they degrade in Preference Induction and Preference Transfer, where the model must infer and apply a latent constraint. This gap is clearest for Base prompting in the context-free query setting, which isolates preference modeling: average F1 drops from 53.19% in Preference Recall to 43.00% in Preference Induction and 16.26% in Preference 7 Preprint. Under review. (a) Context-guided(b) Context-free # of GT args. = 3.84 CodeGemma-7b-it Gemma-3-12b-it R1-Distill-Llama-8B R1-Distill-Qwen-7B GPT-4o-mini GPT-5-mini GPT-5 Gemini-3-flash Base Prompting PRefine 234 # of GT args. = 1.11 1234 Average # of Predicted Args. Figure 4: Average number of predicted API arguments per model under Base prompting and PREFINE. Circles denote Base prompting, diamonds denote PREFINE, and the red vertical line marks the average ground-truth number of arguments. Transfer. A similar pattern holds for RAG, Mem0, and LangMem: their context-guided Preference Recall P-EM reaches 50.60%, 31.93%, and 64.40%, respectively, but these gains do not persist in Preference Induction or Preference Transfer, and the same trend appears in the context-free query setting. In summary, these results suggest that existing baselines can support direct behavioral reuse, but not the induction or transfer of latent preferences. 7.2 How PREFINE Improves Tool Use Compact, Verified Latent Preference Memory.Consistent with our abstraction view in §5, PRE- FINE improves both preference-driven argument prediction (P-EM) and explicit-argument prediction (EA-F1) in the context-guided query setting (Table 3, left). We attribute the EA-F1 gain to reduced test-time dependence on long dialogue history: by providing a compact latent preference memory, PREFINE lets the inference model focus on interpreting the current request and executing the API call. We attribute the P-EM gain to the quality of the retained memory itself. As illustrated in Table 2, thegenerate-verify-refineloop filters out over-specific or weakly supported hypotheses and retains only verified abstractions that remain supported across sessions and usable for future tool decisions. This gives the inference model directly applicable preference guidance, rather than requiring it to rediscover latent constraints from the full interaction history at inference time. Better-Calibrated Argument Generation.Beyond slot-level correctness, PREFINE also improves how well the model selects which schema arguments to instantiate. Although the schema defines the candidate slots, the model must still decide which subset is warranted by the current query and inferred preferences. Errors therefore arise not only from predicting incorrect values, but also from introducing unsupported arguments or omitting required ones. Figure 4 shows that, for most models, PREFINE predictions lie closer to the red ground-truth line in both query settings. To quantify this pattern, we compute the mean absolute deviation between each method’s predicted argument count and the ground-truth number of arguments (# of GT args.). This deviation decreases from 0.77 to 0.56 in the context-guided query setting and from 1.08 to 0.77 in the context-free query setting, corresponding to reductions of 28.1% and 28.7%, respectively. This indicates better action-space alignment: by making latent preferences explicit, PREFINE narrows the set of plausible candidate actions, reducing both unsupported extra arguments and missing required ones. 7.3 Memory Efficiency, Scalability, and Utility Figure 5 shows that PREFINE is substantially more compact than full dialogue history and other memory baselines. Across the dataset, it uses 23.28 tokens on average per dialogue, corresponding to 1.24% of the full dialogue history and more than an 80% reduction relative to the baseline memory methods. Its footprint also remains nearly constant as sessions accumulate, staying around 20–25 tokens even after ten sessions, suggesting that effective latent personalized tool calling depends more on retaining compact reusable constraints than on carrying forward long interaction histories. 8 Preprint. Under review. Figure 5: Memory footprint comparison across methods. (a) Average number of retrieved tokens at test time. (b) Memory token growth over accumulated sessions. 7.4 When and Where PREFINE Helps Most Preference Transfer Gains Depend on Inference-Time Preference Application. Preference Transfer requires both preference abstraction, namely inferring a latent preference that generalizes beyond the observed interaction history, and preference application, namely determining when that preference is relevant in a new context and translating it into argument-level constraints. PREFINE supports the former by storing latent preference hypotheses distilled from past interactions and the latter by providing directly usable preference guidance at inference time. As reported in Table 3, this improves Preference Transfer for most inference LLMs. The remaining variation across backbones suggests that, once such memory is available in an actionable form, transfer performance depends on how effectively each model applies the stored preference in a new context. Action-Space Alignment Introduces Predictable Trade-offs. The same mechanism that makes PREFINE effective—narrowing the action space toward more plausible tool calls—also explains where its gains are smaller. In the context-guided query setting, backbones such as R1-Distill-Llama- 8B can become overly conservative: as shown in Figure 4, it already under-generates arguments in the base setting and predicts even fewer after applying PREFINE (3.34→2.85), which results in lower EA-F1 in Table 3. In the context-free query setting, Gemma-3-12B shows little calibration benefit in Figure 4 and correspondingly exhibits a slight drop in Preference Transfer performance in Table 3. More generally, tighter calibration can trade recall for precision when pruned arguments are in fact required, lowering recall across models in Table 3. These cases are therefore best understood not as contradictions to the overall trend, but as predictable trade-offs of stronger action-space control. 7.5PREFINE Supports Dynamic Schema In realistic settings, tool interfaces evolve: argument inventories change and new schemas are introduced. Therefore we test whether PREFINE memory built under the original MPT schema remains useful under a dynamic schema. As detailed in Appendix C.6, this evaluation uses unseen API domains whose argument names and values differ from those seen during memory construction. Even under schema mismatch, PREFINE retains clear gains. With GPT-5, context-guided P-EM rises from 3.75% to 47.00% and context-free F1 from 36.39% to 51.45%; similar gains appear for Gemini-3-Flash (Appendix C.6). This suggests that PREFINE’s abstract preference constraints can be re-grounded to evolving schema at inference time. This supports the claim in § 5.3 that PREFINE is schema-agnostic at the memory level while remaining schema-constrained at execution time. 8 Conclusion Personalized tool calling often requires more than retrieving past actions: it requires inferring latent user constraints from multi-session behavior and applying them to under-specified API arguments. To study this, we present MPT, which provides three challenges—Preference Recall, Preference Induction, and Preference Transfer—and reveals a consistent gap between naïve pattern matching and 9 Preprint. Under review. true latent preference modeling. We also propose PREFINE, a lightweight test-time memory-based method that represents preferences as revisable hypotheses. By generating, verifying, and refining reusable preference constraints, PREFINE improves personalized tool calling and remains effective under dynamic schema. A future avenue is to extend this framework to richer forms of personalization, including broader preference taxonomies, evolving preferences, and noisier long-horizon interactions. Ethics Statement This work introduces a benchmark and method for personalized tool calling based on the Schema- Guided Dialogue dataset, which contains no personally identifiable information. The preference annotations were conducted by 19 human annotators who participated voluntarily. Our method is designed to improve agent personalization from behavioral history; while this raises general privacy considerations around user data retention, our benchmark operates entirely on synthetic task-oriented dialogues and does not involve real user data. We release MPT and experiment code to facilitate reproducible research. References Amartya Chakraborty, Paresh Dashore, Nadia Bathaee, Anmol Jain, Anirban Das, Shi-Xiong Zhang, Sambit Sahu, Milind Naphade, and Genta Indra Winata. T1: A tool-oriented conversational dataset for multi-turn agentic planning, 2025. URL https://arxiv.org/abs/2505.16986. Qibin Chen, Junyang Lin, Yichang Zhang, Ming Ding, Yukuo Cen, Hongxia Yang, and Jie Tang. Towards knowledge-based recommender dialog system. In Kentaro Inui, Jing Jiang, Vincent Ng, and Xiaojun Wan (eds.), Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP), p. 1803–1813, Hong Kong, China, November 2019. doi: 10.18653/v1/ D19-1189. URL D19-1189/. Prateek Chhikara, Dev Khant, Saket Aryan, Taranjeet Singh, and Deshraj Yadav. Mem0: Building production-ready ai agents with scalable long-term memory. arXiv preprint arXiv:2504.19413, 2025. Joseph L. Fleiss. Measuring nominal scale agreement among many raters. Psychological Bulletin, 76 (5):378–382, 1971. doi: 10.1037/h0031619. Zexue He, Yu Wang, Churan Zhi, Yuanzhe Hu, Tzu-Ping Chen, Lang Yin, Ze Chen, Tong Arthur Wu, Siru Ouyang, Zihan Wang, et al. Memoryarena: Benchmarking agent memory in interdependent multi-session agentic tasks. arXiv preprint arXiv:2602.16313, 2026. Jiaxin Huang, Shixiang Gu, Le Hou, Yuexin Wu, Xuezhi Wang, Hongkun Yu, and Jiawei Han. Large language models can self-improve. In Houda Bouamor, Juan Pino, and Kalika Bali (eds.), Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, p. 1051–1068, Singapore, December 2023. doi: 10.18653/v1/2023.emnlp-main.67. URL2023. emnlp-main.67/. Xu Huang, Yuefeng Huang, Weiwen Liu, Xingshan Zeng, Yasheng Wang, Ruiming Tang, Hong Xie, and Defu Lian. Advancing and benchmarking personalized tool invocation for llms, 2025. URL https://arxiv.org/abs/2505.04072. Bowen Jiang, Zhuoqun Hao, Young-Min Cho, Bryan Li, Yuan Yuan, Sihao Chen, Lyle Ungar, Camillo J. Taylor, and Dan Roth. Know me, respond to me: Benchmarking llms for dynamic user profiling and personalized responses at scale, 2025a. URLhttps://arxiv.org/abs/2504. 14225. Bowen Jiang, Yuan Yuan, Maohao Shen, Zhuoqun Hao, Zhangchen Xu, Zichen Chen, Ziyi Liu, Anvesh Rao Vijjini, Jiashu He, Hanchao Yu, Radha Poovendran, Gregory Wornell, Lyle Ungar, Dan Roth, Sihao Chen, and Camillo Jose Taylor. Personamem-v2: Towards personalized intelligence via learning implicit user personas and agentic memory, 2025b. URLhttps://arxiv.org/ abs/2512.06688. 10 Preprint. Under review. Tae Soo Kim, Yoonjoo Lee, Yoonah Park, Jiho Kim, Young-Ho Kim, and Juho Kim. Cupid: Evaluating personalized and contextualized alignment of llms from interactions. arXiv preprint arXiv:2508.01674, 2025. Deuksin Kwon, Sunwoo Lee, Ki Hyun Kim, Seojin Lee, Taeyoon Kim, and Eric Davis. What, when, and how to ground: Designing user persona-aware conversational agents for engaging dialogue. In Sunayana Sitaram, Beata Beigman Klebanov, and Jason D Williams (eds.), Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 5: Industry Track), p. 707–719, Toronto, Canada, July 2023. doi: 10.18653/v1/2023.acl-industry.68. URL 2023.acl-industry.68/. J. Richard Landis and Gary G. Koch. The measurement of observer agreement for categorical data. Biometrics, 33(1):159–174, 1977. doi: 10.2307/2529310. LangChain AI. LangMem: Long-term memory SDK for LLM agents.https://langchain-ai. github.io/langmem/, 2025. Accessed: 2025-11-20. Shinbok Lee, Gaeun Seo, Daniel Lee, Byeongil Ko, Sunghee Jung, and Myeongcheol Shin. Functionchat-bench: Comprehensive evaluation of language models’ generative capabilities in korean tool-use dialogs, 2024. URL https://arxiv.org/abs/2411.14054. Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, et al. Retrieval-augmented genera- tion for knowledge-intensive nlp tasks. Advances in neural information processing systems, 33: 9459–9474, 2020. Guanrong Li, Kuo Tian, Jinnan Qi, Qinghan Fu, Zhen Wu, and Xinyu Dai. Harmonizing large language models with collaborative behavioral signals for conversational recommendation. arXiv preprint arXiv:2503.10703, 2025. Jiaqi Liu, Yaofeng Su, Peng Xia, Yiyang Zhou, Siwei Han, Zeyu Zheng, Cihang Xie, Mingyu Ding, and Huaxiu Yao. Simplemem: Efficient lifelong memory for llm agents. arXiv preprint arXiv:2601.02553, 2025. URL https://github.com/aiming-lab/SimpleMem. Kai Luo, Scott Sanner, Ga Wu, Hanze Li, and Hojin Yang. Latent linear critiquing for conversational recommender systems. In Proceedings of The Web Conference 2020, W ’20, p. 2535–2541, New York, NY, USA, 2020. Association for Computing Machinery. ISBN 9781450370233. doi: 10.1145/3366423.3380003. URL https://doi.org/10.1145/3366423.3380003. Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, Shashank Gupta, Bodhisattwa Prasad Majumder, Katherine Hermann, Sean Welleck, Amir Yazdanbakhsh, and Peter Clark. Self-refine: Iterative refinement with self-feedback. In Advances in Neural Information Processing Systems, volume 36, 2023.URLhttps://proceedings.neurips.c/paper_files/paper/2023/ hash/91edff07232fb1b55a505a9e9f6c0f3-Abstract-Conference.html. Shuhaib Mehri, Priyanka Kargupta, Tal August, and Dilek Hakkani-Tür. Learning user preferences through interaction for long-term collaboration. arXiv preprint arXiv:2601.02702, 2026. Nikita Moghe, Patrick Xia, Jacob Andreas, Jason Eisner, Benjamin Van Durme, and Harsh Jhamtani. Interpreting user requests in the context of natural language standing instructions. In Kevin Duh, Helena Gomez, and Steven Bethard (eds.), Findings of the Association for Computational Linguistics: NAACL 2024, p. 4043–4060, Mexico City, Mexico, June 2024. doi: 10.18653/v1/ 2024.findings-naacl.255. URL 2024.findings-naacl.255/. Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. Memgpt: Towards llms as operating systems, 2024. URLhttps://arxiv.org/ abs/2310.08560. Joon Sung Park, Joseph C. O’Brien, Carrie J. Cai, Meredith Ringel Morris, Percy Liang, and Michael S. Bernstein. Generative agents: Interactive simulacra of human behavior, 2023. URL https://arxiv.org/abs/2304.03442. 11 Preprint. Under review. Shishir G. Patil, Huanzhi Mao, Charlie Cheng-Jie Ji, Fanjia Yan, Vishnu Suresh, Ion Stoica, and Joseph E. Gonzalez. The berkeley function calling leaderboard (bfcl): From tool use to agentic evaluation of large language models. In Forty-second International Conference on Machine Learning, 2025. Abhinav Rastogi, Xiaoxue Zang, Srinivas Sunkara, Raghav Gupta, and Pranav Khaitan. Towards scalable multi-domain conversational agents: The schema-guided dialogue dataset, 2020. URL https://arxiv.org/abs/1909.05855. Pascal J Sager, Benjamin Meyer, Peng Yan, Rebekka von Wartburg-Kottler, Layan Etaiwi, Aref Enayati, Gabriel Nobel, Ahmed Abdulkadir, Benjamin F Grewe, and Thilo Stadelmann. A comprehensive survey of agents for computer use: Foundations, challenges, and future directions. Journal of Artificial Intelligence Research, 85, 2026. Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettle- moyer, Nicola Cancedda, and Thomas Scialom.Toolformer: Language models can teach themselves to use tools. In Advances in Neural Information Processing Systems, volume 36, 2023.URLhttps://proceedings.neurips.c/paper_files/paper/2023/ hash/d842425e4bf79ba039352da0f658a906-Abstract-Conference.html. Jeonghoon Shim, Gyuhyeon Seo, Cheongsu Lim, and Yohan Jo. Tooldial: Multi-turn dialogue generation method for tool-augmented language models, 2025. URLhttps://arxiv.org/ abs/2503.00564. Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: Language agents with verbal reinforcement learning, 2023a. URLhttps: //arxiv.org/abs/2303.11366. Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: Language agents with verbal reinforcement learning. Advances in neural information processing systems, 36:8634–8652, 2023b. Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. Voyager: An open-ended embodied agent with large language models, 2023. URL https://arxiv.org/abs/2305.16291. Jize Wang, Zerun Ma, Yining Li, Songyang Zhang, Cailian Chen, Kai Chen, and Xinyi Le. GTA: A benchmark for general tool agents. In Advances in Neural Information Processing Systems, volume 37, 2024. URLhttps://proceedings.neurips.c/paper_files/paper/ 2024/hash/8a75e6d4b2eb0b777f549a32a5a5c28-Abstract-Datasets_ and_Benchmarks_Track.html. Zhenting Wang, Huancheng Chen, Jiayun Wang, and Wei Wei. Memex (rl): Scaling long-horizon llm agents via indexed experience memory. arXiv preprint arXiv:2603.04257, 2026. Tianxin Wei, Noveen Sachdeva, Benjamin Coleman, Zhankui He, Yuanchen Bei, Xuying Ning, Mengting Ai, Yunzhe Li, Jingrui He, Ed H. Chi, Chi Wang, Shuo Chen, Fernando Pereira, Wang- Cheng Kang, and Derek Zhiyuan Cheng. Evo-memory: Benchmarking llm agent test-time learning with self-evolving memory, 2025. URL https://arxiv.org/abs/2511.20857. Qiancheng Xu, Yongqi Li, Heming Xia, Fan Liu, Min Yang, and Wenjie Li. PEToolLLM: Towards personalized tool learning in large language models. In Wanxiang Che, Joyce Nabende, Ekaterina Shutova, and Mohammad Taher Pilehvar (eds.), Findings of the Association for Computational Linguistics: ACL 2025, p. 21488–21503, Vienna, Austria, July 2025. ISBN 979-8-89176-256-5. doi: 10.18653/v1/2025.findings-acl.1107. URL 2025.findings-acl.1107/. Renjun Xu and Jingwen Peng. A comprehensive survey of deep research: Systems, methodologies, and applications. arXiv preprint arXiv:2506.12594, 2025. Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik R Narasimhan. $τ$-bench: A benchmark for Tool- Agent- User interaction in real-world domains. In The Thirteenth International Conference on Learning Representations, 2025. URLhttps: //openreview.net/forum?id=roNSXZpUDN. 12 Preprint. Under review. Zhehao Zhang, Ryan A. Rossi, Branislav Kveton, Yijia Shao, Diyi Yang, Hamed Zamani, Franck Dernoncourt, Joe Barrow, Tong Yu, Sungchul Kim, Ruiyi Zhang, Jiuxiang Gu, Tyler Derr, Hongjie Chen, Junda Wu, Xiang Chen, Zichao Wang, Subrata Mitra, Nedim Lipka, Nesreen K. Ahmed, and Yu Wang. Personalization of large language models: A survey. Transactions on Machine Learning Research, 2025. ISSN 2835-8856. URLhttps://openreview.net/forum? id=tf6A9EYMo6. Survey Certification. Siyan Zhao, Mingyi Hong, Yang Liu, Devamanyu Hazarika, and Kaixiang Lin. Do LLMs recognize your preferences? evaluating personalized preference following in LLMs. In The Thirteenth International Conference on Learning Representations, 2025. URLhttps://openreview. net/forum?id=QWunLKbBGF. Kun Zhou, Wayne Xin Zhao, Shuqing Bian, Yuanhang Zhou, Ji-Rong Wen, and Jingsong Yu. Improving conversational recommender systems via knowledge graph based semantic fusion. In Proceedings of the 26th ACM SIGKDD international conference on knowledge discovery & data mining, p. 1006–1014, 2020. Zijian Zhou, Ao Qu, Zhaoxuan Wu, Sunghwan Kim, Alok Prakash, Daniela Rus, Jinhua Zhao, Bryan Kian Hsiang Low, and Paul Pu Liang. Mem1: Learning to synergize memory and reasoning for efficient long-horizon agents, 2025. URL https://arxiv.org/abs/2506.15841. 13 Preprint. Under review. Appendix A Details of MPT A.1 API Schema Table 4 lists all API domains, arguments, and types used in MPT. Preference-relevant arguments— those that appear in the grouping taxonomy—are a strict subset of these schema slots. DomainArgumentType GetBanks recipient_account_type string GetBuses departure_date string departure_time string destination string group_size string origin string GetEvents category string city string date string event_name string event_type string number_of_tickets string GetFlights airlines string departure_date string destination string flight_class string origin string passengers string return_date string GetHomes area string number_of_baths string number_of_beds string pets_allowed boolean property_name string visit_date string GetHotels average_star string check_in_date string has_wifi boolean hotel_name string location string number_of_days string number_of_rooms string DomainArgumentType GetMusic artist string playback_device string song_name string GetRentalCars car_type string dropoff_date string pickup_city string pickup_date string pickup_location string pickup_time string GetRestaurants category string date string number_of_seats string price_range string restaurant_name string time string GetRideSharing destination string number_of_seats string shared_ride boolean GetTravel category string free_entry boolean good_for_kids boolean location string GetMedia genre string GetMovies genre string GetWeather city string date string Table 4: Full API schema for MPT, covering all domains, arguments, and value types. A.2 Preference Group GroupPreferenceDomain(arguments) Budget low_cost GetRestaurants(price_range = cheap) GetRentalCars(car_type = Compact) GetHotels(average_star = 1,2) GetRideSharing(shared_ride = True) GetTravel(free_entry = True) GetFlights(flight_class = Economy) high_cost GetRestaurants(price_range = pricey) GetRentalCars(car_type = Full-size) GetHotels(average_star = 4,5) Travel solo GetBuses(group_size = 1) GetFlights(passengers = 1) GetRideSharing(number_of_seats = 1) GetEvents(number_of_tickets = 1) GetRestaurants(number_of_seats = 1) group GetBuses(group_size = 2,3,4) GetFlights(passengers = 2,3,4) GetRideSharing(number_of_seats = 2,3,4) GetEvents(number_of_tickets = 2,3,4) GetRestaurants(number_of_seats = 2,3,4) Table 5: Full preference-to-argument mapping with identical slot values grouped. Table 5 provides the full preference-to-argument mapping used in MPT, covering 11 preference- sensitive domain–argument pairs across 8 do- mains. The BUDGET group distinguishes two preferences: low_cost and high_cost, omitting a mid_cost tier because the intermediate signals in SGD (e.g.,price_range=“moderate”) are too sparse and ambiguous to serve as re- liable preference evidence. For the TRAVEL group, we retain only solo_usage and exclude group_usage: as noted in our human study (Appendix A.6), parties of size 2 are ambigu- ous between couple and group travel, making group_usage an unreliable preference signal. Be- cause groups are defined at the level of behav- ioral constraints rather than specific slot names, the taxonomy generalizes to APIs beyond SGD—any new domain exposing cost- or party-size-related arguments falls under the same grouping without redefinition, as verified in §7.5. 14 Preprint. Under review. A.3 Dataset Statistics CategoryMeasureCount Interaction History # Multi-Session Dialogue265 # Sessions2,020 # Turns39,884 Avg. Sessions / Dialogue7.6 Avg. Turns / Session19.7 Reasoning Types # Preference Recall332 # Preference Induction293 # Preference Transfer472 Table 6: Statistics of MPT, including dialogue scale and preference signals. Table 6 summarizes the scale of MPT across two di- mensions: interaction history and modeling types. Each multi-session dialogue consists of multiple SGD sessions grouped into a single interaction history, with an average of 7.6 sessions and 19.7 turns per session. This scale re- flects the practical challenge of long-horizon preference modeling: with nearly 40k turns distributed across 265 dialogues, the benchmark requires models to aggregate evidence over substantially longer contexts than typical single-session tool-calling benchmarks. A.4 Distribution of Preference Evidence Hotels RentalCars RideSharing Events Restaurants Banks Flights Buses Music Travel Media Homes Weather Movies 010203040506070 #(API_call) = 1 #(API_call) = 2 #(API_call) ≥3 ↑ Domains → example count ↑ Domains ← example count 020406080100120 None high_cost low_cost solo_usage Figure 6: Domain-wise distribution of preference groups per example (left) and API call frequency per example (right). Note that counts are not mutually exclusive, as a single example may contain multiple preference groups and multiple API calls. Figure 6 presents the distributional characteristics of preference-related API calls across domains and interaction histories. The distributions reveal substantial imbalance across API categories, as well as high variance in the number of API calls per interaction history. These patterns indicate that preference evidence is unevenly distributed and frequently scattered across heterogeneous domains, highlighting the challenges of reasoning over long-term interaction histories under sparse and imbalanced evidence conditions. A.5 Examples of MPT Table 7 shows examples of context-guided and context-free queries for two API domains. Both settings target the same preference-sensitive argument, but context-guided queries include additional in-session dialogue that partially specifies other arguments. DomainUnder-specifiedContext-Guided QueryContext-Free Query GetFlights flight_classU: Book a flight for my trip. A: Where from and to? U: London to Paris. U: Book a flight for my trip. GetRestaurants price_rangeU: Find a restaurant for two tonight. A: Any cuisine preference? U: Korean, please. U: Find a restaurant for tonight. Table 7: Examples of context-guided and context-free queries in MPT. Both settings share the same preference-sensitive argument to infer, but context-guided queries provide additional in-session dialogue context that partially specifies other arguments. U = User, A = Agent. Figure 7 illustrates the three preference modeling types introduced in §3.2, using a concrete example of a flight query from San Francisco to Seattle. 15 Preprint. Under review. Figure 7: Illustration of the three preference modeling types in MPT. Given the same context—a user requesting a flight from San Francisco to Seattle—the missing argumentflight_classrequires different modeling strategies depending on the interaction history: Recall resolves it by direct pattern match within the same domain, Induction requires aggregating cross-domain behavioral evidence to infer a latent constraint, and Transfer requires applying a preference inferred from other domains to a target domain with no prior in-domain evidence. "example_id": "...", "api_calls_pref": [ "group_preference": "budget_conscious", "value_group": "high_cost", "count": 6, "evidence": [ "domain": "GetHotels", "slot": "average_star", "values": [ "value": 4, "count": 4, "value": 5, "count": 2] ] , "group_preference": "travel", "value_group": "solo_usage", "count": 3, "evidence": [ "domain": "GetFlights", "slot": "passengers", "value": 1,,→ "domain": "GetEvents", "slot": "number_of_tickets", "value": 1,→ ] ] Figure 8: Example of multi-session preference ag- gregation in MPT. Session-level dialogues are omitted for brevity. Figure 8 illustrates how multi-session prefer- ence evidence is represented and aggregated in an MPT instance. It shows the structured rep- resentation used in the dataset, where evidence is aggregated into preference groups with ex- plicit counts and argument provenance, captur- ing latent, cross-session preference signals in a machine-readable form. A.6 Human Validation of Preference Grouping To validate that our preference grouping scheme reflects broadly shared behavioral intuitions, we conducted a human annotation study with 19 annotators. Setup. Annotators were presented with slot values drawn from the API schemas in our dataset and asked to classify each value into one of three categories: low_cost, high_cost,orNeitherforthebudget group, and solo_usage, group_usage, or Neither for the travel group. For exam- ple, givenprice_range=“Cheap”in GetRestaurantsandfree_entry=TrueinGetTravel, annotators judged whether each value belongs to the low_cost category. The study covered 27 slot values across 12 API domains for the budget group, and 4 slot values for the travel group. 16 Preprint. Under review. Results. Annotators agreed with our grouping in 89.7% of cases for the budget group and 97.4% for the travel group. Inter-annotator agreement, measured by Fleiss’κFleiss (1971), wasκ = 0.701 (substantial) for budget andκ = 0.880(almost perfect) for travel, following the interpretation scale of Landis & Koch (1977). All 19 annotators confirmed that the group names solo_usage and group_usage clearly represent the intended meaning, while 16 of 19 (84%) confirmed the same for low_cost and high_cost. Discussion.The slightly lower agreement on the budget group (κ = 0.701vs.0.880) likely reflects the broader semantic range of budget-related signals: whereas travel group membership is unam- biguous (solo vs. group size), budget-conscious behavior manifests across heterogeneous argument types—price_range,average_star,free_entry,car_type, and others—leaving more room for individual interpretation. Nevertheless, substantial agreement across both groups confirms that our preference categories are not arbitrary schema choices, but reflect intuitions broadly shared across annotators, supporting their use as a task-grounded evaluation scaffold. Among the travel group, several annotators noted that parties of 2 may reflect couple travel rather than group travel, suggesting ambiguity in the boundary between solo and group usage. Given this concern, we conservatively retain only solo_usage as a preference signal in the travel group, excluding group_usage from the benchmark to avoid introducing ambiguous preference evidence. A.7 Extension of API Schema To construct the dynamic-schema evaluation, we introduce seven new API domains absent from the original MPT training histories:GetCampground,GetCityTour,GetCookingClass, GetFitnessClass,GetSkiPass,GetParkingSpot, andGetThemePark. These do- mains share the same preference group structure as the original schema—for example, site_type=“Tent site”inGetCampgroundmaps to the low_cost budget group, and number_of_guests=1maps to solo_usage—but use entirely different slot names and argument inventories. Memory constructed from the original SGD-based interaction histories is therefore never exposed to these domains during construction, making this a strict test of schema-level generalization. Table 8 shows the full extended schema and preference grouping results. FunctionArgumentSchema Type GetCampground check_in_date string location string number_of_guests string number_of_nights string site_type string GetCityTour city string date string number_of_people string GetCookingClass class_type string date string location string number_of_attendees string GetFitnessClass class_type string date string location string number_of_attendees string GetSkiPass date string number_of_passes string pass_type string resort string GetParkingSpot date string location string parking_type string time string GetThemePark date string number_of_tickets string park string ticket_type string GroupPreference Domain(arguments) budget_conscious low_cost GetCampground(site_type = Tent site) GetCookingClass(class_type = Group class) GetFitnessClass(class_type = Group session) GetSkiPass(pass_type = Standard pass) GetParkingSpot(parking_type = Self-park garage) GetThemePark(ticket_type = General admission) high_cost GetCampground(site_type = Glamping cabin) GetCookingClass(class_type = Private) GetFitnessClass(class_type = Personal training) GetSkiPass(pass_type = VIP pass) GetParkingSpot(parking_type = Valet) GetThemePark(ticket_type = VIP FastPass) travelsolo_usage GetCampground(number_of_guests = 1) GetCityTour(number_of_people = 1) GetCookingClass(number_of_attendees = 1) GetFitnessClass(number_of_attendees = 1) GetSkiPass(number_of_passes = 1) GetThemePark(number_of_tickets = 1) Table 8: Extended API schema (left) and preference mappings (right) used in the dynamic-schema evaluation. These seven domains are absent from the original MPT training histories but share the same preference group structure, with entirely different slot names and argument inventories. 17 Preprint. Under review. B Details of Experiments B.1 Detailed Experimental Settings Table 9 summarizes the LLMs used throughout our experiments, along with their version or release information. All models are evaluated on the same fixed set of query–history pairs without stochastic sampling or reranking. Metrics are computed at the query level and aggregated via macro-averaging across queries of the same type. ModelIdentifier (Reasoning Effort) R1-distill-Llama-8B deepseek-ai/DeepSeek-R1-Distill-Llama-8B R1-distill-Qwen-7B deepseek-ai/DeepSeek-R1-Distill-Qwen-7B Gemini-3-Flash [high] gemini-3-flash-preview (high) GPT-5 [high] gpt-5-2025-08-07 (high) GPT-5-mini [high] gpt-5-mini-2025-08-07 (high) GPT-4o-mini gpt-4o-mini-2024-07-18 CodeGemma-7B-Instruct google/codegemma-7b-it Gemma-3-12B-Instruct google/gemma-3-12b-it Table 9: Versions and release dates of the LLMs used in our experiments. B.2 RAG We implement an utterance-level RAG baseline: (i) embed every utterance in the full dialogue history with OpenAItext-embedding-3-smalland index them withuser_id, (i) at test time, embed the current query and retrieve the top-5 utterances by cosine similarity, (i) append the retrieved utterances to the prompt and runGemini-3-Flashandgpt-5-2025-08-07 (reasoning effort: high) for inference. B.3 Mem0 We use Mem0 (Chhikara et al., 2025) as an off-the-shelf long-term memory system for our agents. Mem0 maintains a persistent, user-scoped memory store and exposes simple APIs for writing and retrieving memories. (i) Mem0 converts the interaction history into compact memory snippets using its memory writer (by default,gpt-4.1-mini-2025-04-14), (i) at test time, Mem0 retrieves a small set of relevant memory snippets conditioned on the current query, (i) we append the retrieved snippets to the prompt and runGemini-3-Flashandgpt-5-2025-08-07(reasoning effort: high) for tool calling. Concretely, we integrate Mem0 via its cloud REST API and official Python client (MemoryClient): we useaddto log user–assistant dialog turns as memories keyed byuser_id, andsearchto retrieve the top-5 semantically relevant memories for a given query, which are then appended to the model prompt at inference time. B.4 LangMem We use LangMem (LangChain AI, 2025) as an agentic memory SDK: (i) LangMem generates memory snippets (Semantic, Episodic, Procedural) using its memory writer (gpt-4o-mini-2024-07-18), (i) at test time, OpenAItext-embedding-3-smallis used to embed all memory contents, including the current query and retrieve top-5 memory snippets by co- sine similarity, (i) append the retreived memory contents to the prompt and runGemini-3-Flash and gpt-5-2025-08-07 (reasoning effort: high) for inference. 18 Preprint. Under review. C Details of Evaluation C.1PREFINE Gain Table 10 reports the exact numerical performance changes (∆) introduced by PREFINE relative to the corresponding LLM baselines. Each value represents the difference between PREFINE and the LLMs under the same backbone, query setting, and evaluation metric. This table serves as a numerical reference for the shaded differences shown in the main results table, enabling precise inspection of both the magnitude and direction of performance changes across Preference Recall, Preference Induction, and Preference Transfer. Shading follows the same convention as the main table, where green indicates performance gains and red indicates losses, with intensity reflecting the magnitude of change. Preference RecallPreference InductionPreference Transfer ModelP-EM EA-F1 OA-F1P-EMEA-F1OA-F1 P-EM EA-F1 OA-F1 Context-guided query CodeGemma-7B40.9730.6232.3412.2833.0830.650.9730.0124.60 Gemma-3-12B17.1760.8753.125.3356.5548.310.2161.0251.30 R1-Distill-Llama-8B7.11-2.770.603.69-0.530.20-1.31-7.15-6.62 R1-Distill-Qwen-7B 18.6225.5623.0210.0331.0525.702.9621.5117.69 GPT-4o-mini17.6514.4415.179.698.277.694.327.998.05 GPT-5-mini 3.862.651.399.764.253.389.376.146.22 Gemini-3-Flash2.230.030.501.090.320.684.190.873.08 GPT-51.214.413.085.530.530.792.252.963.82 Context-free query ModelPrec.Rec.F1Prec.Rec.F1Prec.Rec.F1 CodeGemma-7B15.7713.9118.9217.9816.3820.442.413.393.07 Gemma-3-12B66.3047.3257.0542.7640.1342.1212.445.948.15 R1-Distill-Llama-8B12.43-0.1710.473.58-9.971.881.13-4.24-0.14 R1-Distill-Qwen-7B14.880.7213.4413.364.7814.077.788.488.67 GPT-4o-mini12.02-9.483.817.83-4.854.654.82-4.071.63 GPT-5-mini11.81-5.215.348.51-4.855.069.64-6.023.94 Gemini-3-Flash8.18-2.444.206.780.825.608.816.188.11 GPT-515.07-3.717.9111.65-5.266.687.96-3.183.79 Table 10: Exact performance changes (∆) introduced by PREFINE relative to LLM baselines. C.2 Context-Guided Query Setting Results Tables 11 and 12 report per-backbone, per-reasoning-type results for the context-guided query setting. Compared to Table 3, which reports averaged results, these tables additionally provide precision and recall breakdowns for EA-F1 and OA-F1, Shaded columns (P-EM, EA-F1, OA-F1) correspond to the metrics reported in Table 3. C.3 Context-Free Query Setting Results We report single-turn query results under the PREFINE memory setting, broken down by preference query type. Table 13 presents precision, recall, and F1 scores for each backbone, enabling comparison across modeling types in a setting where no within-query temporal accumulation is available. C.4 RAG, Mem0, LangMem Backbone LLM-Specific Results Table 14 reports backbone-specific results for the memory-augmented baselines. In the main results, we report only the best-performing backbone for each method; here we provide the corresponding Gemini-3-Flash and GPT-5 results to verify that the overall pattern is stable across inference back- bones. Although absolute performance varies by backbone, the qualitative trend remains unchanged: these methods can remain competitive in Preference Recall, but their gains diminish in Preference Induction and Preference Transfer, especially in the context-free setting. 19 Preprint. Under review. BASE PROMPTING Modeling TypeModelP-EMEA-Pre.EA-Rec.EA-F1OA-Pre.OA-Rec.OA-F1 Preference Recall R1-distill-Llama-8B 34.9466.6763.6565.1264.5257.8961.03 R1-distill-Qwen-7B13.5550.8424.9733.4951.1322.8431.58 Gemini-3-Flash [high]62.6573.6071.8872.7371.4877.2574.25 GPT-5 [high]51.2065.0759.8162.3362.9466.7064.77 GPT-5-mini [high]47.5961.5869.6865.3860.8073.8566.69 GPT-4o-mini32.2357.8658.5758.2152.6154.5053.54 CodeGemma-7B-Instruct18.6748.6632.3738.8851.8930.1838.17 Gemma-3-12B-Instruct7.2367.2954.7360.3665.1239.9149.49 Preference Induction R1-distill-Llama-8B18.4364.7160.6262.6059.3956.7058.02 R1-distill-Qwen-7B7.1742.1220.8327.8840.4618.6125.50 Gemini-3-Flash [high]28.6771.6967.7469.6662.5370.9766.49 GPT-5 [high]32.4269.1261.9665.3461.0167.3164.01 GPT-5-mini [high]23.2161.4665.5963.4655.8469.1461.78 GPT-4o-mini18.4363.8161.1662.4655.0059.8857.34 CodeGemma-7B-Instruct4.1040.1627.6932.7839.3824.6930.35 Gemma-3-12B-Instruct2.7366.3750.9457.6464.1038.5748.16 Preference Transfer R1-distill-Llama-8B6.1461.5557.3459.3756.3844.2349.57 R1-distill-Qwen-7B0.6441.8418.7325.8736.6413.8720.12 Gemini-3-Flash [high]14.6269.2870.0969.6853.3860.0956.54 GPT-5 [high]23.9465.3363.2564.2753.2157.9355.47 GPT-5-mini [high]11.6554.3369.7761.0945.7061.0052.25 GPT-4o-mini4.8760.0064.1061.9848.7049.1848.94 CodeGemma-7B-Instruct0.6448.7430.0737.1943.2522.2329.37 Gemma-3-12B-Instruct0.0060.9951.5255.8659.7337.6946.22 PREFINE (GEMMA-3-12B-IT) Modeling TypeModelP-EMEA-Pre.EA-Rec.EA-F1OA-Pre.OA-Rec.OA-F1 Preference Recall R1-distill-Llama-8B 40.0667.5257.6162.1867.4955.2360.75 R1-distill-Qwen-7B32.2360.6256.3858.4257.7150.4653.84 GPT-5 [high]59.0470.6461.7365.8973.5565.0569.04 Gemini-3-Flash [high]71.9974.4071.7473.0475.3176.9776.13 GPT-5-mini [high]56.3371.3266.5368.8473.6666.9770.16 GPT-4o-mini51.2075.8269.6872.6270.6667.6169.10 CodeGemma-7B-Instruct59.3472.2968.7270.4671.6370.1870.90 Gemma-3-12B-Instruct18.6782.2376.8279.4380.0060.9269.17 Preference Induction R1-distill-Llama-8B22.8766.1557.5361.5461.8154.7758.08 R1-distill-Qwen-7B17.7561.6858.2059.8953.6048.7951.09 GPT-5 [high]37.5471.2361.5666.0467.8262.5865.10 Gemini-3-Flash [high]29.6972.7767.8870.2464.9670.7867.74 GPT-5-mini [high]30.3871.4564.9268.0366.6363.5565.05 GPT-4o-mini26.9674.2966.8070.3563.0964.1363.61 CodeGemma-7B-Instruct15.7066.4465.1965.8159.4061.5260.45 Gemma-3-12B-Instruct2.3978.1369.6273.6373.8455.2663.21 Preference Transfer R1-distill-Llama-8B4.6657.1047.1651.6650.7936.5042.47 R1-distill-Qwen-7B4.2450.1343.5146.5942.7033.2637.39 GPT-5 [high]19.9269.8663.9566.7763.8752.8757.85 Gemini-3-Flash [high]15.6871.3670.0970.7258.0259.2458.62 GPT-5-mini [high]13.5668.7765.1966.9362.4952.4757.05 GPT-4o-mini7.6370.5770.2470.4159.7154.1856.81 CodeGemma-7B-Instruct1.0667.8768.6168.2458.8551.9655.19 Gemma-3-12B-Instruct0.0075.3974.2874.8374.8654.3562.98 PREFINE (GPT-4O-MINI) Modeling TypeModelP-EMEA-Pre.EA-Rec.EA-F1OA-Pre.OA-Rec.OA-F1 Preference Recall R1-distill-Llama-8B42.1767.5857.4862.1268.7456.7062.14 R1-distill-Qwen-7B34.3462.0756.7959.3160.4551.4755.60 GPT-5 [high]46.6970.9662.6966.5767.9664.2266.04 Gemini-3-Flash [high]56.6374.1171.4772.7770.9076.2473.47 GPT-5-mini [high]40.9669.4864.3366.8164.9264.6864.80 GPT-4o-mini48.8075.9069.5572.5868.8568.3568.60 CodeGemma-7B-Instruct58.4373.3066.6769.8371.3569.4570.39 Gemma-3-12B-Instruct23.8081.6375.5878.4980.9160.6469.32 Preference Induction R1-distill-Llama-8B 24.5767.5557.9362.3762.1656.7059.30 R1-distill-Qwen-7B16.7263.4953.7658.2254.9246.8750.57 GPT-5 [high]39.5970.0860.7565.0865.1064.0364.56 Gemini-3-Flash [high]29.0172.2767.6169.8663.2470.4966.67 GPT-5-mini [high]36.8670.5464.3867.3265.2067.2166.19 GPT-4o-mini30.0375.0066.9470.7465.6969.4367.51 CodeGemma-7B-Instruct17.7567.8564.1165.9360.8462.7861.79 Gemma-3-12B-Instruct8.8779.9469.6274.4377.8954.0063.78 Preference Transfer R1-distill-Llama-8B 5.5159.1848.3353.2153.0137.5243.94 R1-distill-Qwen-7B5.0853.5645.5349.2245.9634.9139.68 GPT-5 [high]31.9970.2163.7166.8062.6257.5359.97 Gemini-3-Flash [high]22.4671.5369.7070.6058.8362.7160.70 GPT-5-mini [high]29.2468.9066.2867.5661.0359.7560.38 GPT-4o-mini11.6569.8569.3169.5858.6555.7157.14 CodeGemma-7B-Instruct1.9166.7466.9066.8256.0950.7753.30 Gemma-3-12B-Instruct0.2175.2473.8974.5674.8454.1262.82 Table 11: Context-guided query results for Base Prompting and PREFINE with Gemma-3-12B-it and GPT-4o-mini, reported by preference query type (Preference Recall, Preference Induction, Preference Transfer). 20 Preprint. Under review. PREFINE (R1-DISTILL-LLAMA-8B) Modeling TypeModelP-EMEA-Pre.EA-Rec.EA-F1OA-Pre.OA-Rec.OA-F1 Preference Recall R1-distill-Llama-8B45.4868.0257.4862.3069.0556.7062.27 R1-distill-Qwen-7B33.1362.6358.8560.6859.5852.4855.80 GPT-5 [high]54.5270.8562.6966.5271.4064.5967.82 Gemini-3-Flash [high]69.2873.8071.8872.8373.9377.5275.68 GPT-5-mini [high]56.3370.4465.7167.9971.0467.0668.99 GPT-4o-mini50.9076.2169.0072.4370.2667.6168.91 CodeGemma-7B-Instruct59.0470.6365.9868.2370.7368.7269.71 Gemma-3-12B-Instruct21.3982.6076.8279.6081.7360.7369.68 Preference Induction R1-distill-Llama-8B21.5068.9058.0663.0261.8355.9358.73 R1-distill-Qwen-7B18.0961.7957.3959.5154.1849.3751.67 Gemini-3-Flash [high]30.3873.1268.0170.4764.4770.6867.43 GPT-5 [high]36.8671.2561.2965.9066.0262.2064.05 GPT-5-mini [high]32.7670.9964.7867.7465.4364.4264.92 GPT-4o-mini29.3574.6667.3470.8164.1866.3565.24 CodeGemma-7B-Instruct15.3667.0464.7865.8959.4261.7260.55 Gemma-3-12B-Instruct5.8079.6069.2274.0577.2952.8462.77 Preference Transfer R1-distill-Llama-8B 4.2459.4047.8653.0152.0136.8443.13 R1-distill-Qwen-7B2.3351.9943.6747.4743.7132.8037.48 GPT-5 [high]26.4871.1664.0267.4063.6155.5459.30 Gemini-3-Flash [high]18.0170.8869.7770.3257.9360.6059.24 GPT-5-mini [high]19.7068.2664.4966.3260.4854.4657.31 GPT-4o-mini8.2670.2070.4770.3459.0554.9256.91 CodeGemma-7B-Instruct1.4867.4267.5267.4757.2651.3454.14 Gemma-3-12B-Instruct0.2176.4675.2175.8376.2455.0963.96 PREFINE (R1-DISTILL-QWEN-7B) Modeling TypeModelP-EMEA-Pre.EA-Rec.EA-F1OA-Pre.OA-Rec.OA-F1 Preference Recall R1-distill-Llama-8B 40.3668.0558.4462.8868.7455.6961.53 R1-distill-Qwen-7B30.1259.3655.6957.4757.1148.9952.74 GPT-5 [high]48.4972.2462.8367.2072.0662.9467.19 Gemini-3-Flash [high]60.5474.0871.7472.8973.5174.5974.04 GPT-5-mini [high]50.3070.4366.6768.5070.3665.7867.99 GPT-4o-mini49.4075.8970.3773.0269.5267.1668.32 CodeGemma-7B-Instruct60.5472.2866.5369.2972.2069.0870.60 Gemma-3-12B-Instruct18.6782.8976.4179.5181.4559.6368.86 Preference Induction R1-distill-Llama-8B20.1465.9158.7462.1260.7154.6857.53 R1-distill-Qwen-7B18.0958.4756.5957.5153.1649.4751.25 GPT-5 [high]36.8671.8161.2966.1366.3362.0165.02 Gemini-3-Flash [high]30.3872.9366.2669.4465.7768.1866.95 GPT-5-mini [high]29.6971.1865.0567.9866.1063.9365.00 GPT-4o-mini27.9974.5967.8871.0863.6865.7764.71 CodeGemma-7B-Instruct15.7066.3064.7865.5359.7661.7260.72 Gemma-3-12B-Instruct5.8079.7569.8974.5076.8554.1063.50 Preference Transfer R1-distill-Llama-8B4.6657.8447.8652.3851.7537.0143.16 R1-distill-Qwen-7B3.8150.9143.5146.9243.0932.9737.36 GPT-5 [high]25.6470.9263.8767.2164.9955.0959.63 Gemini-3-Flash [high]19.9271.2669.9370.5960.3760.7260.54 GPT-5-mini [high]22.2569.8265.9767.8462.6256.2859.28 GPT-4o-mini10.1769.4370.2469.8359.3755.4957.36 CodeGemma-7B-Instruct2.1265.7867.2166.4956.3450.9953.54 Gemma-3-12B-Instruct0.4276.3275.1475.7276.0055.0963.88 Table 12: Context-guided query results for PREFINE with reasoning-oriented backbones (R1-Distill- Llama-8B and R1-Distill-Qwen-7B), reported by preference query type. 21 Preprint. Under review. GEMMA-3-12B-ITGPT-4O-MINIR1-LLAMA-8BR1-QWEN-7B Modeling TypeModelPrec.Rec.F1Prec.Rec.F1Prec.Rec.F1Prec.Rec.F1 Preference Recall R1-Distill-Llama-8B 43.8773.4154.9244.5870.6454.6645.4171.1955.4544.7572.0255.20 R1-Distill-Qwen-7B33.6351.5240.7038.0663.1647.5037.0557.0644.9336.2259.0044.89 Gemini-3-Flash [high]73.4786.7079.5467.1085.8775.3370.9485.8777.6973.8781.4477.47 CodeGemma-7B-it34.6682.2748.7735.5981.4449.5435.4480.8949.2835.6880.0649.36 Gemma-3-12b-it76.9067.3171.7974.4363.7168.6676.7065.6570.7576.8759.8367.29 GPT-5-mini [high]81.8983.9382.9065.2283.1073.0873.1484.4978.4173.5081.4477.27 GPT-4o-mini63.7464.2764.0058.8272.0264.7663.4068.1465.6961.7363.4362.57 Preference Induction R1-Distill-Llama-8B27.7660.0737.9730.9967.5842.4928.6758.0238.3829.3060.4139.47 R1-Distill-Qwen-7B28.0648.4635.5428.3452.9036.9027.0147.1034.3325.6851.1934.21 Gemini-3-Flash [high]51.2484.6463.8448.9881.5761.2051.1782.2563.0953.9279.8664.37 CodeGemma-7B-it23.4175.4335.7328.2377.4741.3948.6850.1749.4127.1175.7739.93 Gemma-3-12b-it51.4753.9252.6754.3158.0256.1148.5473.7258.5452.5249.8351.14 GPT-5-mini [high]53.7174.0662.2752.1682.2563.8450.7173.3859.9754.3776.4563.55 GPT-4o-mini49.8766.5557.0252.6883.9664.7448.5473.7258.5450.2472.0159.19 Preference Transfer R1-Distill-Llama-8B 8.2712.509.9610.8615.2512.697.0210.818.5110.2715.8912.48 R1-Distill-Qwen-7B10.4214.6212.1713.9522.6717.279.6914.6211.6610.4816.7412.89 Gemini-3-Flash [high]28.9336.6532.3432.6644.2837.5929.3438.3533.2434.6341.5337.76 CodeGemma-7B-it7.3318.8610.559.1221.8212.866.5116.319.317.5318.6410.73 Gemma-3-12b-it14.417.209.6011.156.578.279.094.876.3514.566.368.85 GPT-5-mini [high]26.3420.7623.2230.4938.5634.0527.4229.4528.4034.2531.7832.97 GPT-4o-mini16.7815.4716.1024.1933.0527.9317.4218.8618.1124.3325.0024.66 Table 13: Context-free query results under PREFINE Memory setting (GEMMA-3-12B-IT, GPT-4O- MINI, R1-DISTILL-LLAMA-8B, R1-DISTILL-QWEN-7B ). Context-guided queryContext-free query Pref. RecallPref. InductionPref. TransferPref. RecallPref. InductionPref. Transfer MethodP-EM EA-F1 OA-F1P-EMEA-F1OA-F1 P-EM EA-F1 OA-F1 Prec. Rec.F1Prec.Rec.F1Prec. Rec.F1 Gemini-3-Flash Mem031.93 64.59 59.7927.9965.5262.05 16.31 65.93 54.85 52.36 55.40 53.8448.5172.3558.08 25.59 27.75 26.63 RAG50.60 69.14 67.9924.9167.6061.348.2669.40 55.88 52.42 60.11 56.0045.9870.3155.60 21.68 24.58 23.04 LangMem 64.40 64.54 67.8326.6269.1063.566.5757.59 46.79 69.25 86.70 77.0046.9067.2455.26 13.59 12.92 13.25 GPT-5 Mem019.58 66.39 59.2520.8266.0761.248.0565.01 54.79 51.97 51.25 51.6051.1965.8757.61 23.27 19.28 21.09 RAG21.99 65.56 58.0016.3865.3860.130.8764.91 54.84 49.06 57.89 53.1142.0268.2652.02 13.75 16.95 15.18 LangMem 47.59 66.35 65.5423.2165.2261.128.2664.12 53.92 72.16 70.36 71.2551.8059.0455.18 20.16 10.38 13.71 Table 14: Base LLM-specific performance of memory-augmented methods. 22 Preprint. Under review. C.5PREFINE Refinement Iterations We study whether allowing more generator–verifier refinement rounds improves the performance of PREFINE. To isolate the effect of the refinement budget, we follow the exact same evaluation protocol described in Appendix B and change only the maximum number ofgenerate-verify-refine iterations, comparing the default budget of three iterations against an extended budget of ten iterations. We then aggregate the results by query setting (Context-Guided vs. Context-Free) and Preference Modeling Type (Recall, Induction, Transfer). Thus, each value in Table 15 is the mean score over all memory instances that belong to the corresponding query-setting / modeling-type group. The final column reports the difference∆ = score 10-iter − score 3-iter . Table 15 shows that extending the refinement budget from three to ten iterations yields little to no consistent benefit. The effect is not uniformly positive: performance slightly decreases for context- guided Preference Recall and Preference Induction (−0.006each), improves only marginally in all context-free query settings (+0.002to+0.004), and shows a noticeable gain only for context- guided Preference Transfer (+0.034). Overall, the pattern suggests that most of the useful corrections already happen within the first few refinement rounds, while later rounds tend to make only minor reformulations rather than materially improving the resulting preference memory. Given the additional inference cost of running substantially more refinement steps, we use three iterations as a cost-effective default throughout the main experiments. QueryPreference Modeling Type10-iterations3-iterations∆ (10-iter. – 3-iter.) Preference Recall0.6090.615-0.006 context-guided Preference Induction0.5680.575-0.006 Preference Transfer0.4840.450+0.034 Preference Recall0.5340.530+0.004 context-free Preference Induction0.4020.400+0.002 Preference Transfer0.1110.109+0.003 Table 15: Comparison of PREFINE with a refinement budget of 3 vs. 10 iterations. All results are obtained under the same evaluation setup described in Appendix C. Each value is averaged over all memory instances within the corresponding query-setting and Preference Modeling Type group.∆ denotes 10-iterations minus 3-iterations. C.6 Generalization under Dynamic Schemas Mem0 is omitted from this evaluation because, under schema change, the lexical gap between stored memory contents and test-time query keywords prevents reliable retrieval, causing the Mem0 API to return no memories for any test query. As shown in Table 16, PREFINE retains clear gains over all baselines even under schema mismatch. With GPT-5, context-guided P-EM rises from 3.75% to 47.00% and context-free F1 from 36.39% to 51.45%. RAG and LangMem show sharp drops relative to their in-schema performance, confirming that surface-level retrieval fails when stored content no longer lexically matches the new schema. These results support the schema-agnostic memory design described in § 5.3. D Prompt Design We provide the prompt templates used in our experiments for both base prompting baselines and PREFINE. Figure 9 presents the prompts used by the PREFINE generator and verifier modules, which explicitly separate preference abstraction from verification. Figure 10 (left) shows the prompt used by the base LLM, which directly infers preferences and generates the final API call from the full dialogue history in a single step. Figure 10 (right) shows the inference-time prompt shared by memory-augmented methods (PREFINE, LangMem, Mem0, and RAG). 23 Preprint. Under review. Context-guidedContext-free MethodP-EMEA-F1OA-F1PrecisionRecallF1 Gemini-3-Flash Base Prompting13.5097.8873.5232.7454.7540.97 RAG2.0092.2073.4023.6820.2521.83 Mem0– LangMem4.5091.4371.0619.6919.0019.34 PREFINE30.2599.7886.3941.3163.0049.90 GPT-5 Base Prompting3.7596.1377.9425.5063.5036.39 RAG3.0090.9074.6131.1151.2538.72 Mem0– LangMem8.7594.1477.0730.5129.7530.13 PREFINE47.0089.4782.0143.9762.0051.45 Table 16: Performance under dynamic schemas for Base prompting, memory-augmented methods, and PREFINE. Memory is constructed from the original MPT interaction histories and schema, while inference is performed on schema-shifted APIs that preserve the same underlying preference groups but use different slot names and argument inventories. ### Task: Refine Preference Based on Evidence Gaps Your previous preference abstraction was rejected. You must: -Remove any claim not directly supported by the logs. -Increase abstraction if details are over-specified. -Preserve only what consistently constrains action selection. Do NOT add new information. ### Input Draft Preference: "previous_draft" Verifier Feedback: "feedback" ### Output Format (JSON) "reasoning": "How unsupported details were removed or abstracted", "implicit_pref": "The revised, evidence-tight preference constraint" RefinePrompt You are a Preference Abstraction Module for an agentic tool-calling system. Your role is NOT to summarize dialogue history. Your role is to infer stable, latent user preferences that constrain future API argument selection. Key Principles: -Preference reasoning is holistic and non- decompositional. -Do NOT enumerate slots or list past actions. -Infer abstract constraints that explain multiple past decisions. -A valid preference must be actionable: it should rule in or rule out future API arguments. If evidence is insufficient, state uncertainty explicitly. ### Context (Accumulated Data) **Previous Belief**: prev_implicit **Dialogue History**: full_dialogue **API Calls**: full_api_calls System Prompt You are a Preference Verification Module. Your task is to judge whether the candidate preference is a valid latent constraint derived from the interaction logs. Evaluation Criteria: 1. Evidence Support: -Every claim must be supported by multiple or consistent signals. 2. Abstraction Quality: -Reject preferences that merely restate slot values or actions. -Prefer abstract constraints that generalize across domains. 3. Actionability: -The preference must constrain or bias future API argument selection. -If it cannot affect future actions, it is invalid. 4. Temporal Consistency: -If behavior changed, ensure the preference reflects the latest stable pattern. ### Evidence (Logs) **Dialogue**: full_dialogue **API Calls**: full_api_calls ### Candidate Preference to Verify candidate_pref ### Output Format (JSON) "valid": true/false, "feedback": "If false, specify whether the issue is over-specificity, hallucination, lack of abstraction, or non-actionability." PRefine‘Verifier’ ### Task: Infer Latent Preference as an Action Constraint Given the accumulated interaction history, infer the user's latent preference as a compact decision-level constraint. Guidelines: 1. Do NOT describe individual turns or list slot values. 2. Identify a unifying preference that explains repeated or consistent choices. 3. If multiple signals exist, abstract them into a higher-level constraint. 4. If contradictions exist, prioritize the most recent stable pattern. 5. If no stable preference can be inferred, explicitly say "insufficient evidence". ###Output Format (JSON) "reasoning": "One-paragraph explanation of the inferred abstraction and its supporting evidence", "implicit_pref": "A single-sentence constraint describing how future API arguments should be biased or restricted" GeneratePrompt PRefine‘Generator’ Figure 9: Prompt templates for the PREFINE generator and verifier. The generator proposes latent preference hypotheses as abstract, decision-level constraints from accumulated interaction history. The verifier evaluates each candidate against four validity conditions and provides structured feedback for refinement. 24 Preprint. Under review. You are a Personalized Preference Reasoning Agent. Your task is to generate the most appropriate Service API call for the current user utterance by integrating (1) Retrieved Long-term Memories and (2) Accumulated API Call History, strictly following the given schema. [Task Definition] The user may not explicitly state all information in the current turn. You must deduce missing information by analyzing inferred preferences in the Retrieved Memories and accumulated API call history. -**Repetitiveness**: If a user frequently chose a specific value in the past, assume this is their preference. -**Cross-domain Consistency**: Identify the user's **universal behavioral patterns or constraints exhibited in previous interactions. If a direct preference is missing, **deduce** the current slot's value by applying these established patterns. [Reasoning Steps] 1. **Schema Filtering **: -Identify the target domain from the `Schema`. -Consider ONLY the slots defined in the schema. 2. **Relevant Memories**: -Infer the value by applying the user’s stable behavioral patterns -Map these abstract constraints to the most appropriate schema-valid value. 3. **Formulate Output**: -Create a slot ONLY when there is reasonable support from API history or memories. -Do NOT create empty slots -Do NOT hallucinate values or infer beyond the schema. Schema (Consider valid slots for the domain): preference_schema Relevant Memories (User Preferences & Constraints): retrieved_memories Current User Utterance: user_utterance Output Format: Domain(slot_name="value", ...) Now produce ONLY the final Service API call: Memory-based(PRefine, LangMem,Mem0, RAG) Prompt [Instruction] You are a Personalized Preference Extraction Specialist. Your goal is to infer the user’s “ Abstract Preferences” based on their dialogue history and current utterance, strictly following the provided preference schema. [Task Definition] The user may not explicitly state all information in the current turn. You must deduce missing information by analyzing patterns in the Dialogue History. -**Repetitiveness**: If a user frequently chose a specific value in the past, assume this is their preference. -**Cross-domain Consistency**: Identify the user's **universal behavioral patterns or constraints** exhibited in previous interactions. If a direct preference is missing, **deduce** the current slot's value by applying these established patterns. [Reasoning Steps] 1. **Filter Context**: Focus ONLY on the slots listed in the `Target Preference Schema`. Ignore transient slots like specific dates or times. 2. **Identify Patterns in History**: -Scan the `Dialogue History` for the target slots. -Determine the most likely preference value based on frequency and similarity. 3. **Formulate Output**: -Generate the final function call using the deduced information. Target Preference Schema: preference_schema Dialogue History: dialogue_history Current User Utterance: user_utterance Output Format: Domain(slot_name="value", ...) Now produce the final Service API call: Base Prompting Figure 10: Inference prompts used in our experiments. The base prompting template (left) instructs the LLM to infer user preferences and generate the final API call directly from dialogue history and the current query. The memory-retrieved template (right) is used by PREFINE, LangMem, Mem0, and RAG, which condition on retrieved preference memories instead of full dialogue history. 25

Instant research discovery