Paper deep dive

Trajectory-Informed Memory Generation for Self-Improving Agent Systems

Gaodan Fang, Vatche Isahagian, K. R. Jayaram, Ritesh Kumar, Vinod Muthusamy, Punleuk Oum, Gegi Thomas

Year: 2026Venue: arXiv preprintArea: cs.AIType: PreprintEmbeddings: 80

Intelligence

Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 96%

Last extracted: 3/22/2026, 6:16:17 AM

Summary

The paper introduces a framework for self-improving LLM-powered agents that extracts actionable learnings from execution trajectories. It utilizes a four-component system—Trajectory Intelligence Extractor, Decision Attribution Analyzer, Contextual Learning Generator, and Adaptive Memory Retrieval—to generate strategy, recovery, and optimization tips. This approach improves agent performance on the AppWorld benchmark by enabling agents to learn from past successes, failures, and inefficiencies.

Entities (5)

AppWorld · benchmark · 99%Adaptive Memory Retrieval System · component · 98%Contextual Learning Generator · component · 98%Decision Attribution Analyzer · component · 98%Trajectory Intelligence Extractor · component · 98%

Relation Signals (3)

Adaptive Memory Retrieval System → injects → learnings

confidence 95% · injects relevant learnings into agent prompts based on multi-dimensional similarity

Trajectory Intelligence Extractor → performs → semantic analysis

confidence 95% · performs semantic analysis of agent reasoning patterns

Contextual Learning Generator → produces → guidance

confidence 95% · produces three types of guidance—strategy tips from successful patterns, recovery tips from failure handling, and optimization tips

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:LLM-powered agents face a persistent challenge: learning from their execution experiences to improve future performance. While agents can successfully complete many tasks, they often repeat inefficient patterns, fail to recover from similar errors, and miss opportunities to apply successful strategies from past executions. We present a novel framework for automatically extracting actionable learnings from agent execution trajectories and utilizing them to improve future performance through contextual memory retrieval. Our approach comprises four components: (1) a Trajectory Intelligence Extractor that performs semantic analysis of agent reasoning patterns, (2) a Decision Attribution Analyzer that identifies which decisions and reasoning steps led to failures, recoveries, or inefficiencies, (3) a Contextual Learning Generator that produces three types of guidance -- strategy tips from successful patterns, recovery tips from failure handling, and optimization tips from inefficient but successful executions, and (4) an Adaptive Memory Retrieval System that injects relevant learnings into agent prompts based on multi-dimensional similarity. Unlike existing memory systems that store generic conversational facts, our framework understands execution patterns, extracts structured learnings with provenance, and retrieves guidance tailored to specific task contexts. Evaluation on the AppWorld benchmark demonstrates consistent improvements, with up to 14.3 percentage point gains in scenario goal completion on held-out tasks and particularly strong benefits on complex tasks (28.5~pp scenario goal improvement, a 149\% relative increase).

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

80,120 characters extracted from source content.

Expand or collapse full text

Trajectory-Informed Memory Generation for Self-Improving Agent Systems Gaodan Fang, Vatche Isahagian, K. R. Jayaram, Ritesh Kumar, Vinod Muthusamy, Punleuk Oum, Gegi Thomas ∗ Agents and Automation Lab, IBM Research USA Abstract LLM-powered agents face a persistent challenge: learning from their execution experiences to improve future performance. While agents can successfully complete many tasks, they often repeat inefficient patterns, fail to recover from similar errors, and miss op- portunities to apply successful strategies from past executions. We present a novel framework for automatically extracting actionable learnings from agent execution trajectories and utilizing them to improve future performance through contextual memory retrieval. Our approach comprises four components: (1) a Trajectory Intelli- gence Extractor that performs semantic analysis of agent reasoning patterns, (2) a Decision Attribution Analyzer that identifies which decisions and reasoning steps led to failures, recoveries, or ineffi- ciencies, (3) a Contextual Learning Generator that produces three types of guidance—strategy tips from successful patterns, recovery tips from failure handling, and optimization tips from inefficient but successful executions—and (4) an Adaptive Memory Retrieval System that injects relevant learnings into agent prompts based on multi-dimensional similarity. Unlike existing memory systems that store generic conversational facts, our framework understands exe- cution patterns, extracts structured learnings with provenance, and retrieves guidance tailored to specific task contexts. Evaluation on the AppWorld benchmark demonstrates consistent improvements, with up to 14.3 percentage point gains in scenario goal completion on held-out tasks and particularly strong benefits on complex tasks (28.5 p scenario goal improvement, a 149% relative increase). CCS Concepts • Computing methodologies→Information extraction; Multi- agent systems; Knowledge representation and reasoning;• Information systems→Enterprise applications; Information re- trieval. Keywords agentic memory, self evolving agents ACM Reference Format: Gaodan Fang, Vatche Isahagian, K. R. Jayaram, Ritesh Kumar, Vinod Muthusamy, Punleuk Oum, Gegi Thomas. 2026. Trajectory-Informed Memory Generation for Self-Improving Agent Systems. In Technical Report describing research ∗ Author names listed alphabetically. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). Technical Report, Yorktown Heights, NY © 2026 Copyright held by the owner/author(s). https://doi.org/10.1145/n.n done at IBM. ACM, New York, NY, USA, 14 pages. https://doi.org/10.1145/ n.n 1 Introduction Large Language Model (LLM) powered agents have enabled in- creasingly sophisticated automation of tasks ranging from web navigation to API orchestration. These agents operate by iteratively reasoning about tasks, selecting actions, executing them, and ob- serving results. However, a fundamental limitation persists: Agents have amnesia because most LLMs are stateless. Agents lack system- atic mechanisms to learn from their execution experiences [4,17]. An agent that struggles with a particular API authentication flow today will struggle with the same flow tomorrow unless its prompts are manually updated. An agent that discovers an efficient strategy for a task cannot automatically apply that strategy to similar future tasks. An agent that successfully recovers from an error provides no benefit to future executions that encounter similar errors. Consider a simple e-commerce task: adding items to a shop- ping cart and completing checkout. An agent might successfully complete this task but do so inefficiently—for instance, by call- ingamazon_remove_from_cart(item_id)in a loop to empty the cart when a singleamazon_empty_cart()call would suffice. In another execution, the agent might fail entirely because it attempts checkout without first adding a payment method, then successfully recover by recognizing the error and adding payment information. In yet another execution, the agent might execute the task cleanly from the start by systematically verifying prerequisites before each operation. Each of these trajectories contains valuable learnings (for future executions), but of different types. The inefficient success suggests an optimization tip: when emptying a cart with multiple items, use the bulk operation rather than iterating through individual re- movals. The failure-then-recovery suggests a recovery tip: when checkout fails due to missing payment method, verify payment in- formation is configured before retrying. The clean success suggests a strategy tip: before initiating checkout operations, systematically verify all prerequisites including cart contents, shipping address, and payment method availability. Current approaches to agent improvement are inadequate for capturing these diverse learning opportunities. Rule-based systems require developers to manually anticipate patterns and encode them as decision rules, making them brittle and unable to adapt to unforeseen situations. Prompt engineering improves common patterns through iteratively refined instructions and examples, but this guidance is generic rather than specific to actual deployment experiences, and there is no mechanism for automatic improvement based on observed outcomes. Generic memory systems [2,15] store arXiv:2603.10600v1 [cs.AI] 11 Mar 2026 Technical Report, Published Feb 2026, Yorktown Heights, NYFang et al. facts extracted from conversations in vector databases for later re- trieval, but these systems lack several critical capabilities: they have no understanding of agent execution patterns and reasoning flows, they cannot perform causal analysis to identify which decisions led to failures or inefficiencies, they lack structured learning extraction with categories like strategy, recovery, and optimization, and they provide no provenance tracking from learnings back to source tra- jectories. Recent work has begun extracting reusable knowledge from agent trajectories—including workflows from successful exe- cutions [6,13], procedural instructions [5], reasoning strategies [9], and evolving context playbooks [16]—but these approaches typi- cally learn only from successful trajectories, lack explicit causal attribution of failures, or produce monolithic documents rather than structured, retrievable memory entries. Empirical studies fur- ther demonstrate that naive experience accumulation leads to error propagation and misaligned replay [14], underscoring the need for quality-aware memory curation. We present a framework that addresses these limitations through trajectory-informed memory generation and retrieval. Our key in- sight is that agent execution histories—trajectories—contain rich semantic information about not just what happened, but why agents made decisions, how they reasoned about tasks, which strategies succeeded, which patterns proved inefficient, and where decision chains led to failures and recoveries. By analyzing these trajecto- ries with semantic understanding, we can automatically extract actionable learnings across multiple categories, attribute failures and inefficiencies to specific decisions and reasoning steps, generate context-aware guidance, and retrieve relevant learnings based on multiple contextual dimensions. Our contributions are as follows: •We introduce trajectory intelligence extraction that moves beyond raw logging to semantic understanding of agent reasoning patterns, including analytical thoughts, planning patterns, validation behaviors, reflection patterns, and self- correction sequences. •We present automated decision attribution that distinguishes immediate causes, proximate causes, and root causes of fail- ures, while also identifying which decisions led to successful recoveries and which execution patterns prove inefficient despite succeeding. •We develop contextual learning generation that produces three distinct types of guidance: strategy tips encoding suc- cessful patterns from clean executions, recovery tips captur- ing failure handling and error correction approaches, and optimization tips identifying efficiency improvements from successful but suboptimal executions. • We design adaptive memory retrieval that combines seman- tic similarity with metadata filtering and priority-based rank- ing to ensure agents receive the most relevant guidance for their specific context, including task type, domain, and exe- cution patterns. •We demonstrate the framework’s effectiveness on the App- World benchmark, showing consistent improvements across all difficulty levels, with particularly strong gains on complex tasks where learned experience is most valuable. 2 Problem Statement 2.1 The Agent Learning Challenge LLM-powered agents execute tasks by iteratively reasoning, select- ing actions, and observing outcomes. Each execution trajectory—the complete sequence of thoughts, actions, and results from initial request to final outcome—contains patterns that could inform fu- ture executions [11]. However, extracting actionable learnings from these trajectories is non-trivial for several reasons. First, valuable patterns exist across diverse outcome cate- gories. Not all learning opportunities arise from failures. An agent that successfully completes a task may have employed an elegant strategy worth replicating, discovered an efficient API usage pat- tern, or executed a thorough validation sequence that prevented errors. Conversely, an agent that ultimately succeeds may have done so inefficiently—taking unnecessary steps, making redundant API calls, or using granular operations where bulk operations exist. And agents that encounter failures may successfully recover, with the recovery pattern itself being valuable to capture. A comprehen- sive learning system must extract insights from clean successes, inefficient successes, failure-then-recovery sequences, and com- plete failures. Second, causality is often non-obvious from raw logs. When an agent fails at step 15 of an execution, the problematic decision may have occurred at step 3. When an agent successfully recovers from an error, identifying which specific reasoning led to the recov- ery requires semantic understanding of the agent’s thoughts, not just observation of the final outcome. When an agent completes a task inefficiently, determining which alternative approach would be more efficient requires understanding both what the agent did and what other options were available. Third, learnings must be contextually retrieved. An opti- mization tip about using bulk cart operations is relevant when the agent is performing cart management but irrelevant for email com- position tasks. A recovery tip about handling authentication failures is critical for tasks involving authenticated APIs but unnecessary for read-only operations. The retrieval system must match learn- ings to contexts based on multiple dimensions: task type, domain, semantic similarity to current request, and the specific execution patterns involved. The importance of precise retrieval is amplified by empirical evidence that agents closely follow retrieved experi- ences [14], making mismatched retrieval a direct source of degraded performance. Fourth, learnings must be actionable and specific. Generic advice like "be careful with API calls" provides little value. Effective learnings specify concrete validation checks, particular API usage patterns, specific error recovery sequences, or explicit prerequisite verification steps. They must be formulated in terms the agent can directly apply: "Before initiating checkout, verify payment method is configured by callingget_payment_methods()and checking for non-empty results" is actionable; "make sure payment works" is not. Fifth, learnings must be traceable to their source. Each learn- ing must maintain provenance—a link back to the specific trajectory and outcome from which it was derived [3]. This enables validation of whether learnings are effective (do similar failures still occur Trajectory-Informed Memory Generation for Self-Improving Agent SystemsTechnical Report, Published Feb 2026, Yorktown Heights, NY after the learning is deployed?), investigation of why certain guid- ance was generated, and auditing of the learning system’s decisions. Without provenance, it is impossible to debug incorrect guidance, assess learning quality over time, or build trust in the system’s recommendations. 2.2 Learning Requirements For agents that reason and act iteratively (e.g., ReAct-style, plan-and- execute), the learning system must satisfy several requirements. Strategy extraction from successful patterns: When an agent executes a task cleanly—without errors, unnecessary steps, or re- covery sequences—its approach often embodies effective strategies. The system must identify these patterns: Did the agent verify prereq- uisites before attempting operations? Did it systematically explore available APIs before selecting one? Did it validate intermediate results before proceeding to dependent steps? These successful pat- terns should be encoded as strategy tips that guide future executions toward similarly effective approaches. Recovery extraction from failure handling: When an agent encounters an error but successfully recovers, the recovery se- quence is valuable. The system must identify what went wrong, what the agent recognized about the failure, how it adjusted its approach, and what specific actions led to successful recovery. For example, if an agent attempts checkout without payment config- ured, receives an error, recognizes the missing payment method, adds payment information, and successfully retries, this entire se- quence should be encoded as a recovery tip including the failure pattern, recognition signals, and correction steps. Optimization extraction from inefficient successes: When an agent successfully completes a task but does so suboptimally, the system must identify the inefficiency and determine the more efficient alternative. This requires understanding not just what the agent did, but what other options were available. For example, if an agent removes items from a cart one-by-one in a loop when a bulkempty_cart()operation exists, the system must recognize this pattern, identify the more efficient alternative, and encode an optimization tip specifying when and how to use the bulk operation. Step-level decision attribution: When failures or inefficiencies occur, the system must identify which specific reasoning steps and decisions led to the outcome. This requires semantic analysis of the agent’s thoughts, not just observation of actions. If an agent fails because it assumed an API was available without verifying, the attribution must identify the assumption step, explain why it was problematic, and specify what verification should have occurred. Thought pattern recognition: Agents often exhibit meta-cognitive behaviors that indicate their reasoning quality. An agent that explic- itly validates prerequisites is demonstrating a positive pattern. An agent that recognizes its own errors and self-corrects is exhibiting reflection. An agent that makes assumptions without verification is exhibiting a negative pattern. The system must identify these cog- nitive patterns semantically—recognizing that "I should verify all APIs are available" exhibits a validation pattern even without using the word "validate"—and use them to guide learning extraction. Semantic reasoning analysis: Beyond recognizing individual thought patterns, the system must move beyond raw execution logs to understand the full structure of agent reasoning. The system must identify and classify distinct reasoning modes—analytical thoughts (examining data or constraints), planning thoughts (formulating action sequences), validation thoughts (checking prerequisites or intermediate results), reflection thoughts (evaluating past actions), and self-correction sequences (recognizing and recovering from errors)—to understand how agents reasoned about tasks and where their reasoning succeeded or failed. This structured understanding of reasoning flows is what enables the extraction of meaningful learnings from trajectories rather than surface-level pattern match- ing on actions alone. 2.3 Limitations of Existing Approaches Existing approaches to agent improvement fail to address these challenges comprehensively. Rule-based systems encode decision rules based on anticipated patterns, but they cannot adapt to unforeseen situations and re- quire constant manual maintenance as new patterns emerge. They also cannot automatically extract rules from observed execution trajectories—each rule must be manually crafted by developers who may not have visibility into actual deployment patterns. Prompt engineering improves agent performance through iter- atively refined guidance and examples, but this guidance is generic rather than specific to actual deployment experiences. If an agent repeatedly fails at a particular API authentication flow, prompt engineering might eventually capture this pattern, but only after manual observation and prompt modification. There is no mecha- nism for automatic improvement based on observed outcomes, and no systematic way to capture the full range of learning opportuni- ties from successes, failures, and recoveries. Generic memory systems represent a more sophisticated ap- proach but still fall short. Systems like Mem0 [2] and Letta [10] store facts extracted from conversations in vector databases for later retrieval. However, these systems lack several critical capa- bilities for agent learning. They have no understanding of agent execution patterns—they treat all memories uniformly rather than distinguishing between strategy patterns, recovery sequences, and optimization opportunities. They cannot perform causal analysis to identify which decisions led to failures or inefficiencies—they store outcomes but not the decision chains that produced them. They lack structured learning extraction with categories, priorities, and actionable steps—memories are typically free-form text without the structure needed for agent guidance. They provide no provenance tracking from learnings back to source trajectories, making it im- possible to validate whether learnings are effective or to investigate why certain guidance was generated [17]. Reinforcement learning approaches learn from reward sig- nals but have their own limitations for this problem. They require extensive training data to learn effective policies, which may not be available when failures are rare but consequential. They are compu- tationally expensive to train and update, making them impractical for continuously evolving agent systems. They provide limited inter- pretability regarding why certain decisions improve outcomes—the learned policy is often a black box. For scenarios where under- standing the reasoning behind improvements is valuable (such as debugging or auditing agent behavior), RL approaches provide in- sufficient transparency. Additionally, RL approaches struggle with Technical Report, Published Feb 2026, Yorktown Heights, NYFang et al. the multi-category learning problem—they optimize for overall re- ward but do not naturally distinguish between strategy patterns, recovery sequences, and optimization opportunities. 3 Approach As illustrated in Figure 1, we propose a framework that trans- forms raw agent execution trajectories into actionable, contextually- retrieved guidance for future invocations. The framework operates as a three-phase pipeline: (1) Phase 1: Trajectory Analysis and Tips Extraction. Given an agent’s execution trajectory for a completed task, the sys- tem analyzes the reasoning trace to identify causal decision chains—why outcomes occurred—and extracts structured tips capturing effective strategies, recovery patterns, and optimization opportunities. Tips are extracted at two com- plementary granularities: task-level tips that capture holistic end-to-end patterns, and subtask-level tips that decompose trajectories into reusable logical phases (authentication, data retrieval, processing, etc.) for cross-task transfer. (2)Phase 2: Tip Storage and Management. Extracted tips are generalized, clustered, and consolidated before storage. Subtask descriptions are abstracted to remove entity-specific details, enabling semantic clustering of tips from different tasks that share common subtask patterns. An LLM-based merging process consolidates redundant or overlapping tips within each cluster, producing a curated memory of non- redundant, high-quality guidance. Tips are stored with dual representations—vector embeddings for semantic search and structured metadata for filtering. (3)Phase 3: Runtime Retrieval. When an agent is invoked for a new task, the system retrieves relevant tips from memory and injects them into the agent’s prompt as guidelines before reasoning begins. Two retrieval strategies are supported: cosine similarity retrieval (fast, no LLM call) and LLM-guided selection (richer reasoning about task context at the cost of an additional LLM invocation). These phases form a self-reinforcing cycle: as more trajectories are processed, the memory system accumulates increasingly com- prehensive and refined guidance. Agents that receive this guidance produce higher-quality trajectories that may reveal subtler patterns for further learning. The following subsections detail each phase. 3.1 Phase 1: Trajectory Analysis and Tips Extraction This phase analyzes completed agent trajectories to extract struc- tured, actionable tips. It comprises three stages: trajectory intelli- gence extraction, decision attribution analysis, and tip generation. A key design dimension of the tip generation stage is the granu- larity at which tips are extracted—either at the level of entire task trajectories (task-level) or at the level of individual logical subtasks within a trajectory (subtask-level). We explore both granularities and compare their effectiveness in Section 4. 3.1.1Trajectory Intelligence Extractor. The Trajectory Intelligence Extractor transforms raw agent execution data into a structured in- termediate representation that captures semantic meaning beyond what traditional logging provides: why agents made particular de- cisions, how they validated their reasoning, where they exhibited self-corrective behavior, and what patterns characterized successful versus unsuccessful executions. The component receives raw agent trajectories containing se- quential steps with agent invocations, prompts or contexts, agent responses including thoughts and reflections, actions taken and their results, and optionally, evaluation reports or ground-truth outcome assessments. Each trajectory represents a complete task execution from initial user request through final outcome. Crucially, ground-truth outcome labels (success or failure) are not required: when they are available—for instance, from a benchmark evaluation harness—the system uses them directly to classify the trajectory; when they are absent, the system infers outcome from the agent’s own self-reflective signals identified in subsequent stages. The first processing stage parses agent responses to identify and categorize reasoning into four types based on cognitive function: Analytical thoughts where the agent analyzes the situation and assesses constraints; Planning thoughts where the agent decides what actions to take and in what sequence; Validation thoughts where the agent checks assumptions or verifies preconditions; and Reflection thoughts where the agent reconsiders its approach, often triggered by unexpected results. Beyond categorization, the extractor identifies status indicators, execution summaries, and error recognition statements, enabling downstream components to understand the reasoning process that led to actions. The second stage uses an LLM to identify cognitive patterns within extracted thoughts through semantic understanding rather than keyword matching. The system recognizes: Validation pat- terns—any expression of checking or verifying assumptions, even without validation-related keywords (e.g., “I need to ensure all re- quired APIs are included” exhibits validation behavior); Reflection patterns—reconsideration of previous decisions, often after errors; Self-correction patterns—proactively identifying and fixing er- rors before external signals; Error recognition patterns—noticing problems that may affect task completion; API discovery pat- terns—systematic exploration of available APIs; and Efficiency awareness patterns—considering whether more efficient alter- natives exist. This semantic approach generalizes across linguistic variations, unlike rule-based keyword matching. The third stage determines the trajectory outcome. When ground- truth evaluation reports are present, the stage interprets them with semantic understanding: a report stating “API response returned 400 Bad Request” is converted into “Checkout API failed because re- quired payment method parameter was not provided,” and for each outcome indicator, the module determines what the test validates, why it failed (if applicable), the impact on task completion, and overall quality assessment. When ground-truth labels are absent, the stage instead synthesizes outcome from the self-reflective sig- nals extracted in stages 1 and 2—reflection thoughts, self-correction patterns, and error recognition patterns—to infer whether the agent succeeded, failed, or recovered. In both cases, the result is an out- come classification used by downstream components. A fourth stage specifically analyzes successful executions, dis- tinguishing: Clean successes—task completed without errors or unnecessary steps, with patterns that are candidates for strategy tips; Inefficient successes—task completed but suboptimally (e.g., Trajectory-Informed Memory Generation for Self-Improving Agent SystemsTechnical Report, Published Feb 2026, Yorktown Heights, NY EXTRACTION Trajectory Intelligence Extractor Decision Attribution Analyzer Contextual Learning Generator Subtask-level Decomposition STORAGE & MGMT Description Generalization Semantic Clustering Tip Merging and Consolidation Dual-Indexed Store RETRIEVAL & USAGE Cosine similarity or top-k selection LLM-guided selection Priority Weighted Ranking Prompt integration Agent Trajectory TIPSTIPS Agent Task Description Figure 1: Overview of our approach repeated operations that could be batched), yielding candidates for optimization tips; and Recovery sequences—successful error han- dling within otherwise successful executions, yielding candidates for recovery tips. The output is a structured intermediate representation enriched with extracted thoughts, identified patterns with confidence scores, evaluation intelligence, success patterns, and metadata including trajectory identifier, task intent, step count, and overall outcome classification. 3.1.2Decision Attribution Analyzer. The Decision Attribution An- alyzer performs automated causal analysis to identify which deci- sions and reasoning steps led to observed outcomes. It analyzes all outcome types—not just failures. The first stage scans the intermediate representation for outcome indicators across four categories: Failure indicators—failed evalua- tions, error messages, task incompletion signals; Recovery indica- tors—failure followed by successful completion, error recognition followed by corrective actions; Inefficiency indicators—repeated operations that could be batched, unnecessary intermediate steps, granular operations where bulk alternatives exist; and Success pat- terns—clean completion, systematic prerequisite verification, effi- cient API usage. For each detected outcome, contextual information is extracted as the starting point for causal analysis. Importantly, the outcome location is typically not the cause location. The causal analysis module uses an LLM to trace backwards through the agent’s reasoning steps to identify which decisions led to the observed outcome. For failures, the analysis distinguishes: the immediate cause (what directly triggered the failure), the prox- imate cause (recent decisions that enabled it), the root cause (the underlying issue that originated the chain), and contributing fac- tors. For recoveries, it identifies what enabled the failure, how the agent recognized the problem, what corrective action was taken, and why the correction succeeded. For inefficiencies, it identifies what made execution suboptimal, what more efficient alternative exists, why the alternative is better, and whether the agent was aware of the inefficiency. For success patterns, it identifies what strategies contributed to clean success, why they were effective, and what made the approach particularly good. The final stage generates specific prevention or improvement steps for each attributed decision point. These steps must be ac- tionable—the agent can actually perform them; specific—concrete actions rather than vague advice; causal—directly addressing the root cause; and preventive or improving—stopping similar fail- ures from occurring or specifying more efficient approaches. 3.1.3 Contextual Learning Generator. The Contextual Learning Generator converts decision analyses into reusable memory entries that are actionable, contextually rich, and properly categorized. The key innovation is generating three distinct tip types based on trajectory outcomes. Strategy tips encode effective patterns from clean successful executions—what worked well and should be replicated. Example: Content: ”When performing checkout operations, systematically verify all prerequisites (cart contents, shipping address, payment method) before initiating the checkout sequence.” Category: strategy Steps: 1. Call get_cart_items() to verify cart is not empty 2. Call get_shipping_address() to verify address is configured 3. Call get_payment_methods() to verify payment method exists 4. Only proceed with checkout if all prerequisites are satisfied Trigger: ”When task involves checkout, purchase, or payment operations” Technical Report, Published Feb 2026, Yorktown Heights, NYFang et al. Recovery tips encode both the failure pattern and the recovery pattern from failure-then-recovery sequences. Example: Content: ”When checkout fails with ́payment method required ́ error, verify payment configuration and add payment method if missing before retrying.” Category: recovery Steps: 1. Recognize error message indicating missing payment method 2. Call get_payment_methods() to check current configuration 3. If empty, call add_payment_method() with appropriate details 4. Retry the checkout operation Trigger: ”When checkout or payment operations fail” Negative Example: ”Do not simply retry without addressing the missing payment method.” Optimization tips identify efficiency improvements from suc- cessful but suboptimal executions. Example: Content: ”When emptying a shopping cart with multiple items, use empty_cart() instead of iterating remove_from_cart(item_id) for each item.” Category: optimization Steps: 1. Check if cart has multiple items to remove 2. Instead of looping remove_from_cart(), call empty_cart() once 3. Verify cart is empty with get_cart_items() Trigger: ”When task requires removing all items from cart” Negative Example: ”Do not use for i in items: remove_from_cart(i) when emptying the entire cart.” The system analyzes trajectories to determine contextual di- mensions for both generation and retrieval: the application context (which domain the task involves), the task category (type of oper- ation within the domain), and the complexity level. Tip content is generated using specialized prompts for each category, incorpo- rating the relevant execution patterns, and each prompt includes guidelines for generating actionable, specific, generalizable tips. Each generated memory entry contains: a unique identifier, tip category (strategy, recovery, optimization), actionable content, ex- planatory purpose, concrete implementation steps, trigger condi- tion, optional negative example, application context (or null for generic tips), task category (or null for generic tips), priority level (critical/high/medium/low based on outcome severity), source tra- jectory ID, and source outcome description. The system also generates both domain-specific and generic tips from the same trajectory, maximizing precision and coverage. From a failure involving missing payment APIs in e-commerce checkout, the system generates a domain-specific tip (“For e-commerce tasks involving checkout, verify payment method is configured before initiating checkout”) and a generic tip (“When initiating operations that have prerequisites, systematically verify all prerequisites before beginning”). This dual-level generalization ensures high precision when context matches domain-specific tips and broad coverage through generic tips that apply even in novel domains. 3.1.4 Task-Level vs. Subtask-Level Extraction. The tip generation stage can operate at two granularities. Task-level extraction treats an entire trajectory as a unit, producing holistic tips that capture end- to-end execution patterns. Subtask-level extraction first decomposes the trajectory into logical subtasks and then extracts focused tips for each subtask independently. The two approaches offer different tradeoffs. Task-level tips are straightforward to extract and capture overarching strategies span- ning the full task. However, their reusability is limited by task speci- ficity: a tip extracted from “Name the artist most recommended to me on Spotify” may not transfer to “Move my go-to-sleep phone alarm to 20 minutes later,” even though both share common sub- tasks such as authentication and paginated data retrieval. Task-level tips also bundle concerns from distinct execution phases, reducing retrieval precision. Subtask-level extraction addresses these limitations by scoping each tip to a single logical phase. Many tasks share common sub- tasks that generalize across contexts: • Authentication subtasks follow a common pattern across apps (Spotify, Phone, Venmo): retrieve credentials from a supervisor, login, and store the access token. •Data retrieval subtasks share pagination patterns: issue paginated API calls, aggregate results, and store them for downstream processing. •Data processing subtasks involve domain-independent op- erations: counting, filtering, aggregation, and transformation of retrieved data. •Task completion subtasks are near-universal: reporting results and marking tasks complete. By extracting tips at this granularity, we enable cross-task trans- fer (authentication tips from Spotify tasks help with Phone app tasks), better matching (a task about updating alarms retrieves tips from a “retrieve all alarms” subtask even if the original task was about deleting alarms), and compositional learning (new complex tasks leverage tips from multiple simpler subtasks). Two-Phase Extraction Pipeline. The subtask-level extraction op- erates as a two-phase LLM-based pipeline. Phase A: Trajectory Segmentation. An LLM analyzes the full agent trajectory and segments it into logical subtasks. For each subtask, the model produces a generalized description (deliberately generic, e.g., “Authenticate with Spotify” rather than “Login as user@gmail.com”), the set of applications involved, the step range in the original trajectory (maintaining traceability), and the subtask’s purpose. The segmentation prompt instructs the model to iden- tify natural boundaries between distinct logical phases—transitions from authentication to data retrieval, from data retrieval to process- ing, and so on. For example, a trajectory for “Name the artist most recommended to me on Spotify” might be segmented into: (1) discover relevant APIs and their specifications, (2) authenticate with Spotify, (3) re- trieve recommended songs via paginated requests, and (4) analyze recommendations to determine the most recommended artist. Phase B: Per-Subtask Tips Extraction. An LLM independently extracts 2–4 actionable tips for each subtask. By scoping each ex- traction call to a single subtask, the prompts remain focused and the tips avoid conflating concerns from different execution phases. The Trajectory-Informed Memory Generation for Self-Improving Agent SystemsTechnical Report, Published Feb 2026, Yorktown Heights, NY tips are constrained to be concrete (specific API patterns rather than vague advice), generalizable (avoiding task-specific details such as particular email addresses, song names, or payment amounts), and actionable (directly applicable by an agent encountering a similar subtask). Optionally, different models can be used for Phase A and Phase B—a more capable model for segmentation and a lighter model for per-subtask extraction—to balance cost and quality. Example output for the “Authenticate with Spotify” subtask: Tips: 1. ”Always retrieve account credentials from supervisor.show_account_passwords() before attempting authentication” 2. ”Immediately store and validate access tokens after login to ensure successful subsequent API calls” 3. ”Filter credentials by app name to select the correct password for the target service” Subtask-level and task-level tips are complementary rather than competing. Task-level tips capture holistic patterns about end-to- end execution strategy (e.g., “verify all prerequisites before check- out”), while subtask-level tips capture focused patterns about spe- cific execution phases (e.g., “use paginated retrieval when fetching large result sets”). Both levels are stored in the same memory system and can be retrieved together during Phase 3. 3.2 Phase 2: Tip Storage and Management As tips accumulate from many trajectories across diverse tasks, the memory system must address redundancy, inconsistency, and scalability. Two trajectories involving e-commerce checkout may in- dependently produce tips about verifying payment methods; dozens of trajectories across different apps will produce authentication- related tips with overlapping guidance. Without consolidation, the memory grows linearly with the number of processed trajectories, retrieval quality degrades as near-duplicate tips compete for limited prompt space, and contradictory tips from different trajectories may confuse the agent. Phase 2 addresses these challenges through a pipeline of subtask description generalization, semantic clustering, and LLM-based tip consolidation. 3.2.1Subtask Description Generalization. Subtask descriptions pro- duced by Phase 1 contain varying levels of specificity that hinder clustering. “Retrieve Spotify password for john.doe@email.com using supervisor API,” “Get Venmo login credentials for user al- ice_smith,” and “Fetch Phone app password from supervisor” all describe the same abstract operation: retrieving service credentials. To enable meaningful clustering, the system generalizes subtask descriptions through three transformations: • Entity abstraction: Replaces specific user names, email addresses, app names, item IDs, and other entity references with generic placeholders. “Retrieve Spotify password for john.doe@email.com” becomes “Retrieve service account credentials.” •Action normalization: Maps semantically equivalent verbs and phrases to canonical forms. “Get,” “fetch,” “retrieve,” and “obtain” are normalized to a single canonical verb. “Log in,” “sign in,” and “authenticate” are similarly unified. •Context removal: Strips task-specific contextual qualifiers that do not affect the subtask’s core operation. “Retrieve cre- dentials in order to check subscription status” is reduced to “Retrieve service account credentials,” since the downstream purpose does not change how credential retrieval should be performed. These transformations are applied using an LLM with a prompt that instructs it to produce maximally abstract descriptions while preserving the core operation. The generalized descriptions serve as the basis for clustering: tips whose generalized subtask descrip- tions are semantically similar are likely to contain overlapping or complementary guidance. 3.2.2Semantic Clustering. The system clusters tips by computing cosine similarity between the vector embeddings of their general- ized subtask descriptions, then applying hierarchical agglomerative clustering with a similarity threshold. Two generalized descrip- tions such as “Retrieve service account credentials” and “Authenti- cate with external service” may describe distinct subtasks despite surface-level relatedness, while “Retrieve service account creden- tials” and “Obtain application login credentials” describe the same operation. Hierarchical clustering with an appropriate threshold (empirically,∼0.85 on generalized descriptions) groups truly equiva- lent subtask descriptions while keeping distinct operations separate. Within each cluster, all associated tips are collected regardless of their source trajectory, task context, or extraction granularity. A cluster for “Retrieve service account credentials” might contain tips from Spotify authentication trajectories, Venmo login trajec- tories, and Phone app credential retrieval—all reflecting the same underlying subtask pattern observed across different tasks. 3.2.3Tip Consolidation and Merging. Within each cluster, an LLM- based consolidation process merges redundant tips, resolves con- flicts, and produces a curated set of non-overlapping guidance. The consolidation operates in three steps: Deduplication. Tips with near-identical content are identified and merged. “Always callshow_account_passwords()before lo- gin” and “Retrieve credentials using the supervisor password API before authentication” convey the same guidance; the consolidation produces a single canonical tip that captures the shared insight. Conflict resolution. When tips from different trajectories offer contradictory guidance (e.g., one tip recommends retrying failed au- thentication immediately while another recommends re-retrieving credentials first), the system uses outcome metadata—tip category, priority level, and source trajectory success/failure status—to deter- mine which guidance is more reliable. Tips derived from successful trajectories take precedence over those from failed ones, and recov- ery tips that encode proven correction patterns take precedence over speculative prevention strategies. Synthesis. Complementary tips that address different aspects of the same subtask are synthesized into coherent, comprehensive guidance. If one tip covers credential retrieval and another covers token validation after login, the consolidated output combines both into a single tip with ordered steps covering the full authentication workflow. Technical Report, Published Feb 2026, Yorktown Heights, NYFang et al. The consolidation also produces a canonical cluster description—a single generalized subtask description that represents the clus- ter for retrieval purposes. This description is re-embedded and stored alongside the consolidated tips, replacing the individual per-trajectory descriptions. 3.2.4Storage Representation. Each consolidated memory entry is stored with two complementary representations. The vector em- bedding is a dense vector computed from the tip content and pur- pose using a text embedding model. This captures semantic mean- ing, enabling similarity search across different terminology—for instance, a tip about “renewing a subscription” can match a task de- scription mentioning “extending my membership,” and a tip about “scheduling a recurring event” can match “set up a weekly meeting.” The structured metadata consists of filterable attributes: tip cate- gory (strategy, recovery, optimization), priority level, application context, task category, source trajectory IDs (plural, since consol- idated tips may derive from multiple trajectories), and creation timestamp. Tips are indexed by their canonical cluster description for subtask- level tips, and by the original task description for task-level tips, creating natural groupings that enable retrieval at both granulari- ties. 3.3 Phase 3: Runtime Retrieval When an agent is invoked to execute a new task with description 푑, the system retrieves relevant tips from memory and injects them into the agent’s prompt as guidelines before reasoning begins. The retrieval strategy directly affects whether the agent receives rel- evant, actionable guidance or is distracted by irrelevant tips. We consider two strategies with different cost-accuracy tradeoffs. 3.3.1 Cosine Similarity Retrieval. The most straightforward ap- proach embeds the incoming task description푑and computes co- sine similarity against the embeddings of stored task (and subtask) descriptions. Tips associated with the most similar stored descrip- tions are retrieved and injected into the prompt. This strategy re- quires no LLM calls at retrieval time and is fast and inexpensive—a pure vector database lookup. Two complementary mechanisms control which tips are selected: •Similarity threshold휏: Only tips whose source description has cosine similarity≥ 휏with푑are eligible. A high threshold (e.g.,휏 ≥0.85) ensures retrieved tips are closely related to the current task, but risks excluding tips from tasks that are semantically equivalent yet phrased differently. For example, “I want an Amazon Prime membership” and “Sign me up for Amazon Prime” describe the same task but may have cosine similarity below 0.85 due to lexical differences. A low threshold (e.g.,휏 ≤0.6) casts a wider net, but risks pulling in tips from unrelated tasks—tips from “Book a flight to New York” are unlikely to help an agent executing “Update my calendar for next week,” yet both involve scheduling- adjacent language that could produce moderate similarity scores. •Top-푘selection: After filtering by threshold, the system selects the푘highest-scoring tips. This bounds the number of tips injected into the prompt regardless of how many pass the threshold, preventing prompt bloat when many stored tasks are moderately similar. In practice, these two mechanisms are combined: the system retrieves all tips with similarity≥ 휏, then selects the top푘by similarity score. Typical values are 휏 ∈ [0.5, 0.7] and 푘 ∈ [5, 10]. 3.3.2LLM-Guided Selection. A more expressive approach uses an LLM at retrieval time to analyze the task description푑, detect the application context and task category, and reason about which types of guidance are most relevant. The LLM constructs a structured retrieval query that combines: •Metadata filters: The LLM identifies that a task about “Com- plete my pending Venmo payment requests” involves the Venmo application and payment operations, and constrains retrieval to tips from the payment domain (or generic tips with null application context). • Category awareness: Based on the task description, the LLM may determine that recovery tips are particularly rele- vant (e.g., the task mentions retrying a failed payment) or that strategy tips should be prioritized (e.g., the task involves a multi-step workflow). LLM-guided selection is more expensive (requiring an additional LLM call per task) but can reason about nuances that pure embed- ding similarity misses. For instance, an LLM can recognize that “Delete all my read emails older than 30 days” and “Clean up my inbox by removing old messages” are the same task even when their embeddings diverge, and it can infer that a task involving “check- out” implies payment-related tips are relevant even if “payment” is never mentioned in the task description. Comparison. Cosine similarity retrieval is simple, fast, and requires no LLM calls at runtime—making it suitable for latency- sensitive or cost-constrained deployments. LLM-guided selection provides richer reasoning about task context at the cost of an addi- tional LLM invocation. We evaluate both strategies empirically in Section 4. 3.3.3 Prompt Integration. Regardless of retrieval strategy, the se- lected tips are injected into the agent’s prompt as a “guidelines” section positioned after the task context but before the standard agent instructions. Each tip is formatted to be quickly scannable and actionable, highlighting priority level, category, actionable content, purpose, implementation steps, and trigger condition. For example: [PRIORITY: HIGH] Recovery Tip: When a login attempt fails with ”invalid credentials,” verify you are using the correct app-specific password by re-calling supervisor.show_account_passwords() and filtering by the target app name. Apply when: Authentication fails on any app after an initial login attempt. Steps: 1. Re-retrieve credentials from supervisor 2. Filter for the specific app name (exact match) 3. Retry login with the correct credentials Trajectory-Informed Memory Generation for Self-Improving Agent SystemsTechnical Report, Published Feb 2026, Yorktown Heights, NY This formatting enables agents to quickly identify the type of guidance, prioritize critical tips, and understand both what to do and why. The prompt integration creates a feedback loop: agents receiving relevant tips avoid failure patterns, execute more effi- ciently, and apply successful strategies, producing higher-quality trajectories that reinforce the memory system’s value. 4 Evaluation We evaluate our trajectory-informed memory generation frame- work on the AppWorld benchmark, a comprehensive evaluation suite for LLM agents that perform complex tasks across multiple ap- plications. Our evaluation examines two dimensions: (1) the effect of tip extraction granularity (task-level vs. subtask-level tips), and (2) the effect of retrieval strategy (cosine similarity vs. LLM-guided selection). The evaluation demonstrates that agents equipped with learned memory from past executions substantially outperform agents without memory, with particularly strong improvements on challenging tasks. 4.1 Experimental Setup 4.1.1Benchmark Description. AppWorld is a benchmark designed to evaluate LLM agents on realistic task completion across diverse application domains. The benchmark contains tasks spanning e- commerce, email, calendar, file management, and other common application scenarios. Each task consists of a natural language instruction that the agent must execute by interacting with APIs provided for various applications. The benchmark includes two key evaluation metrics: Task Goal Completion (TGC) measures the percentage of in- dividual tasks where the agent passes all programmatic unit tests, which verify correct API usage, database state changes, and ex- pected end states. Each task is a complex, multi-step, app-based challenge that typically requires multiple API calls across an av- erage of 1.8 apps and 9.5 APIs. A task is successful only if all unit tests pass. Scenario Goal Completion (SGC) measures the percentage of scenarios where the agent correctly completes all task variants (typically three) associated with a given scenario, testing for consis- tency across related tasks. A scenario is only counted as successful if every variant passes, making this a stricter metric than TGC. Tasks in AppWorld are categorized by difficulty level: • Difficulty 1 (Easy): Simple tasks requiring basic API inter- actions, typically single-domain with straightforward execu- tion sequences •Difficulty 2 (Medium): Moderate complexity tasks that may span multiple domains or require conditional logic and error handling •Difficulty 3 (Hard): Complex multi-step tasks requiring careful planning, prerequisite management, cross-domain coordination, and robust error recovery, often involving 50+ lines of equivalent code and up to 26 APIs 4.1.2Agent Configuration. We evaluate using a single-agent con- figuration implementing a simplified ReAct-style reasoning and action loop. The agent iteratively reasons about the current task state, selects actions to take, executes those actions via API calls, and observes the results. The agent continues this loop until it determines the task is complete or encounters an unrecoverable failure. Both the agent and the tip extraction pipeline use GPT-4.1. The base agent (without memory) receives only the task in- struction and standard prompting that includes its role descrip- tion, available APIs, and general guidelines for task execution. The memory-enhanced agent additionally receives retrieved tips from the memory system, injected into the prompt before the agent begins reasoning. 4.1.3Tip Extraction Configurations. We evaluate two tip extraction granularities: Task-level tips are extracted from entire trajectories as de- scribed in Section 3.1.3. Each trajectory produces a holistic set of strategy, recovery, and optimization tips that capture end-to-end execution patterns. Task-level tips are well-suited for capturing overarching strategies (e.g., “verify all prerequisites before check- out”) but may bundle unrelated concerns from different execution phases. Subtask-level tips are extracted using the two-phase pipeline described in Section 3.1.4. Trajectories are first segmented into logical subtasks (authentication, data retrieval, data processing, etc.), and tips are then extracted independently for each subtask. Subtask-level tips are more focused and reusable across tasks that share common subtasks. Both tip types were generated from agent executions on the AppWorld training and development partitions, processed through our pipeline. 4.1.4Retrieval Strategy Configurations. We evaluate two retrieval strategies for selecting which tips to inject into the agent’s prompt at runtime: Cosine similarity retrieval embeds the task instruction using a text embedding model and retrieves the top-푘tips whose vector embeddings have the highest cosine similarity to the query embed- ding. This is a standard retrieval approach that requires no LLM calls at retrieval time and is fast and inexpensive. LLM-guided selection uses an LLM to analyze the task instruc- tion, detect the application context and task category, and construct a retrieval query that combines semantic similarity with metadata filtering and priority-weighted ranking. This approach is more ex- pressive—it can reason about which tip categories are most relevant and ensure critical tips surface—but requires an additional LLM call at retrieval time. For both strategies, the top 5 tips are retrieved and injected into the agent’s prompt before reasoning begins. 4.1.5 Evaluation Protocol. We evaluated configurations on three partitions of AppWorld: (1) the test-normal partition, which con- tains held-out tasks not seen during memory generation, measuring the agent’s ability to generalize learned patterns to novel tasks; (2) the train partition, from which tips were generated, measuring how effectively tips improve performance when the same task is encountered again; and (3) the dev partition, also used during tip generation, providing a complementary view. Each task was executed independently with a maximum of 30 reasoning-action steps. Task and scenario goal completion were as- sessed using AppWorld’s automated evaluation framework, which Technical Report, Published Feb 2026, Yorktown Heights, NYFang et al. verifies that all explicit requirements (task goals) and implicit re- quirements (scenario goals) are satisfied by examining the final state of all involved applications. 4.2 Held-Out Results (Test-Normal) The test-normal partition contains tasks not seen during memory generation, providing the most rigorous evaluation of the memory system’s ability to generalize learned patterns to novel tasks. We present results for multiple configurations. 4.2.1Subtask-Level Tips with LLM-Guided Selection. Tables 1 and 2 present results for subtask-level tips with LLM-guided selection— the best-performing configuration for scenario goal completion. Table 1: Subtask Tips + LLM Selection: Test-Normal TypeTask GoalScenario Goal Aggregate73.264.3 Difficulty 191.289.5 Difficulty 270.856.2 Difficulty 358.747.6 Table 2: Baseline Agent (No Memory): Test-Normal TypeTask GoalScenario Goal Aggregate69.650.0 Difficulty 189.579.0 Difficulty 266.756.2 Difficulty 354.019.1 The memory-enhanced agent achieves 73.2% TGC compared to 69.6% for the baseline (+3.6 p) and 64.3% SGC compared to 50.0% (+14.3 p). The larger SGC improvement suggests that the memory system not only helps agents complete individual tasks correctly but substantially improves consistency across task variants within scenarios. Since SGC requires all variants to pass, it is sensitive to sporadic failures—exactly the brittleness that learned tips help mitigate. The benefits scale with task complexity. Difficulty 1 tasks show improvements of +1.7 p TGC and +10.5 p SGC, with the baseline already achieving high TGC. Difficulty 2 tasks show +4.1 p TGC with no SGC change, benefiting from learned patterns around er- ror handling and prerequisite verification. Difficulty 3 tasks show the most dramatic improvements: +4.7 p on TGC and a remark- able +28.5 p on SGC (19.1%→47.6%), a 149% relative increase. These complex tasks require sophisticated planning and robust error recovery—areas where the memory system provides the most guidance. 4.2.2 Task-Level Tips with Cosine Similarity Retrieval. We next evaluate task-level tips with cosine similarity retrieval. Task-level tips extract holistic insights from entire trajectories rather than decomposing them into subtasks. At retrieval time, the incoming task description is embedded and compared against stored task de- scription embeddings; tips from descriptions exceeding a similarity threshold휏are retrieved. We evaluate three retrieval parameter configurations to examine the effect of threshold and top-푘selec- tion. Table 3: Task-Level Tips + Cosine (휏 ≥0.5, top-3): Test-Normal TypeTask GoalScenario Goal Aggregate66.748.2 Difficulty 1 86.068.4 Difficulty 270.856.2 Difficulty 3 46.023.8 Table 4: Task-Level Tips + Cosine (휏 ≥ 0.6): Test-Normal TypeTask GoalScenario Goal Aggregate72.062.5 Difficulty 1 91.284.2 Difficulty 272.968.8 Difficulty 3 54.038.1 Table 5: Task-Level Tips + Cosine (휏 ≥ 0.5): Test-Normal TypeTask GoalScenario Goal Aggregate70.257.1 Difficulty 191.284.2 Difficulty 264.643.8 Difficulty 355.642.9 The three cosine similarity configurations reveal important in- teractions between threshold, top-푘selection, and task complexity. Top-푘restriction hurts performance. The most restrictive configuration (휏 ≥0.5, top-3) performs below the baseline at the aggregate level (66.7% TGC, 48.2% SGC), a drop of−2.9 p and −1.8 p respectively. The top-3 restriction limits the agent to tips from only three matched task descriptions, which may exclude relevant guidance. This is especially damaging for complex tasks: Difficulty 3 drops to 46.0% TGC (−8.0 p from baseline). Threshold휏=0.6 is the sweet spot. The configuration with 휏 ≥0.6 (no top-푘restriction) achieves the strongest overall results among cosine similarity configurations: 72.0% TGC (+2.4 p) and 62.5% SGC (+12.5 p). This threshold strikes an effective balance: tight enough to exclude tips from unrelated tasks, yet loose enough to capture semantically equivalent task descriptions that differ lexically (e.g., “I want an Amazon Prime membership” and “Sign me up for Amazon Prime”). The Difficulty 3 SGC improvement is striking: 19.1%→ 38.1% (+19.0 p), a 99% relative increase. Lower threshold includes noise. Dropping to휏 ≥0.5 (no top-푘) yields 70.2% TGC (+0.6 p) and 57.1% SGC (+7.1 p)—better than the baseline but weaker than휏 ≥0.6 on both metrics. The lower threshold admits tips from marginally related tasks, diluting the signal. Interestingly, Difficulty 3 TGC is slightly higher with 휏 ≥0.5 (55.6%) than with휏 ≥0.6 (54.0%), suggesting that for the most complex tasks, casting a wider net occasionally surfaces useful tips from loosely related tasks. However, the reverse pattern holds for Difficulty 2 (64.6% vs. 72.9%), where the noise from irrelevant tips is more damaging. Trajectory-Informed Memory Generation for Self-Improving Agent SystemsTechnical Report, Published Feb 2026, Yorktown Heights, NY 4.2.3Subtask-Level Tips with Cosine Similarity Retrieval. To isolate the effect of the retrieval strategy from the effect of tip granularity, we also evaluate subtask-level tips with cosine similarity retrieval (휏 ≥0.6, no top-푘)—the same retrieval parameters as the best task- level cosine configuration, but with subtask-level tips instead. Table 6: Subtask Tips + Cosine (휏 ≥ 0.6): Test-Normal TypeTask GoalScenario Goal Aggregate73.857.1 Difficulty 1 91.273.7 Difficulty 2 72.956.2 Difficulty 358.742.9 This configuration achieves 73.8% TGC (+4.2 p over baseline)— the highest TGC of any configuration—and 57.1% SGC (+7.1 p). Comparing with subtask-level tips with LLM-guided selection (Ta- ble 1) isolates the effect of the retrieval strategy while holding tip granularity constant: TGC is slightly higher with cosine retrieval (73.8% vs. 73.2%), but SGC drops substantially (57.1% vs. 64.3%, a 7.2 p gap). This divergence is most pronounced on Difficulty 3, where SGC drops from 47.6% to 42.9%. The LLM-guided selection’s ability to reason about task context and prioritize tip categories appears critical for cross-variant consistency, even though simple cosine retrieval suffices (and marginally excels) for individual task completion. 4.2.4 Configuration Comparison. Table 7 compares all configura- tions on the held-out test-normal partition, using휏 ≥0.6 (no top-푘) for both cosine similarity configurations. The three configurations reveal a clear separation between what drives task goal completion versus scenario goal completion. Tip granularity drives TGC. Subtask-level tips outperform task-level tips on TGC regardless of retrieval strategy: 73.8% (cosine) and 73.2% (LLM-guided) versus 72.0% (task-level cosine). The finer- grained decomposition into reusable subtask patterns provides more targeted guidance for completing individual tasks, particularly for Difficulty 3 tasks where subtask-level tips yield 58.7% TGC versus 54.0% for task-level (+4.7 p). Retrieval strategy drives SGC. LLM-guided selection dramati- cally improves scenario goal completion compared to cosine simi- larity at the same tip granularity: 64.3% versus 57.1% for subtask- level tips (+7.2 p). This gap is consistent across difficulty levels, with Difficulty 1 showing the largest difference (89.5% vs. 73.7%, +15.8 p). The LLM’s ability to reason about task context, prioritize tip categories, and apply metadata filters produces more consis- tent guidance across task variants within a scenario, reducing the sporadic failures that SGC penalizes. Interaction effect. Interestingly, task-level tips with cosine similarity achieve higher SGC (62.5%) than subtask-level tips with cosine similarity (57.1%), despite lower TGC. Task-level tips encode holistic end-to-end strategies that promote uniform execution pat- terns across related task variants, while subtask-level tips—though more precise for individual task completion—may retrieve different subsets of subtask tips for different variants of the same scenario, in- troducing behavioral variance. LLM-guided selection compensates for this by reasoning about the overall task context and ensuring consistent tip selection across variants. All configurations substantially outperform the baseline, con- firming that the memory system provides genuine value regardless of the specific configuration chosen. The best configuration depends on the deployment objective: subtask-level tips with LLM-guided selection for the best overall performance, subtask-level tips with cosine similarity for the highest individual task accuracy at lower retrieval cost, or task-level tips with cosine similarity for a strong balance without LLM retrieval overhead. 4.3 Source Partition Results (Train and Dev) The train and dev partitions were used during tip generation: tips were extracted from agent trajectories on these tasks. Results on these partitions measure a distinct scenario from test-normal: what happens when the agent encounters the same or structurally iden- tical tasks again, augmented with tips derived from its own prior executions? This setting evaluates the memory system’s ability to enable self-improvement on recurring tasks, complementing the generalization evaluation on test-normal. Tables 8–11 present results for subtask-level tips with LLM- guided selection on the source partitions. As expected, improvements on the source partitions are larger than on test-normal: +4.4 p TGC / +10.0 p SGC on train, and +12.3 p TGC / +26.3 p SGC on dev. Tips are most contextually relevant when the agent encounters tasks structurally similar to those from which the tips were derived, so these larger gains are expected. Two partition-specific patterns are worth noting. On train Diffi- culty 1 tasks where the baseline already achieves 100%, the memory- enhanced agent scores slightly lower (94.4% TGC, 83.3% SGC), sug- gesting that for simple tasks where the agent already performs optimally, injecting additional tips can introduce minor interfer- ence. On dev, the Difficulty 3 baseline already achieves 100% TGC and 100% SGC, so the aggregate dev gains (+12.3 p TGC, +26.3 p SGC) are driven entirely by Difficulty 1 and 2 improvements. In both cases, the overall gains on the tasks that benefit from memory substantially outweigh any ceiling or interference effects. 4.4 Cross-Configuration Summary Table 12 summarizes the aggregate improvements for subtask-level tips with LLM-guided selection across all three partitions. Several observations emerge. First, the memory system improves performance on all three partitions, confirming that the benefits are not limited to tasks that generated the tips. The test-normal gains (+3.6 TGC, +14.3 SGC) demonstrate genuine generalization to unseen tasks. Second, the source partitions show larger TGC improvements, as expected—tips are most contextually relevant when the agent re-encounters tasks from which the tips were de- rived. Interestingly, the test-normal SGC gain (+14.3 p) exceeds the train SGC gain (+10.0 p), suggesting that the subtask-level decomposition and LLM-guided retrieval generalize particularly well for improving cross-variant consistency. Third, the SGC im- provements consistently exceed the TGC improvements across all partitions, indicating that the memory system is particularly ef- fective at improving consistency across task variants. Recovery Technical Report, Published Feb 2026, Yorktown Heights, NYFang et al. Table 7: Configuration Comparison on Test-Normal (Aggregate) Tip GranularityRetrieval StrategyTGCΔ TGCSGCΔ SGC Baseline (no memory)69.6—50.0— Subtask-levelLLM-guided selection73.2+3.664.3+14.3 Subtask-level Cosine sim. (휏 ≥ 0.6)73.8+4.257.1+7.1 Task-levelCosine sim. (휏 ≥ 0.6)72.0+2.462.5+12.5 Table 8: Subtask Tips + LLM Selection: Train TypeTask GoalScenario Goal Aggregate91.183.3 Difficulty 194.483.3 Difficulty 2 88.983.3 Difficulty 388.983.3 Table 9: Baseline Agent (No Memory): Train TypeTask GoalScenario Goal Aggregate86.773.3 Difficulty 1100.0100.0 Difficulty 277.858.3 Difficulty 377.850.0 Table 10: Subtask Tips + LLM Selection: Dev TypeTask GoalScenario Goal Aggregate89.573.7 Difficulty 190.080.0 Difficulty 287.562.5 Difficulty 3 100.0100.0 Table 11: Baseline Agent (No Memory): Dev TypeTask GoalScenario Goal Aggregate77.247.4 Difficulty 180.060.0 Difficulty 270.825.0 Difficulty 3100.0100.0 tips and strategy tips encode prerequisite verification and error handling patterns that reduce behavioral variance, enabling the agent to reliably complete all variants rather than succeeding on some and failing on others. 5 Related Work Our work sits at the intersection of agent memory systems, trajectory- based learning, and self-improving agents. We organize related work along three axes: memory architectures for LLM agents, sys- tems that learn from execution trajectories, and approaches to agent self-improvement through experience. 5.1 Memory Taxonomies and Architectures Two recent surveys provide comprehensive taxonomies of memory in LLM-based agents. Zhang et al. [17] organize the design space along three dimensions—memory sources (agent-environment in- teractions, internal reasoning, user feedback), memory forms (natu- ral language, embeddings, databases, structured knowledge), and memory operations (read, write, reflect, manage)—and identify key limitations of existing work: overly simplistic representations, un- sophisticated operations for deciding what to remember or forget, and fragmented evaluation. Du et al. [4] take a complementary operations-centric view, defining six atomic memory operations: consolidation, updating, indexing, forgetting, retrieval, and com- pression. In their vocabulary, our tip extraction constitutes a form of consolidation (converting raw trajectories into abstract tips), tip refinement is updating, and selective retention is forgetting. Both surveys note that most existing systems store raw or lightly pro- cessed text, lacking the structured abstraction and quality-aware curation that effective agent memory requires. Our framework directly addresses these identified gaps. 5.2 Semantic Memory Systems The most widely deployed agent memory systems operate at the se- mantic level, storing factual knowledge extracted from interactions. Mem0 [2] extracts and consolidates factual snippets—user pref- erences, entities, relationships—from conversations into a vector store, achieving strong latency and token efficiency for conversa- tional personalization. A-MEM [15] introduces a self-organizing memory architecture inspired by the Zettelkasten method, where each memory is stored as a structured note with contextual descrip- tions, keywords, and explicit links to related memories, creating an emergent knowledge network. While both systems are well- engineered for their purposes, they fundamentally store declarative knowledge (what is known) rather than procedural or experien- tial knowledge (what to do and what was learned from doing it). They have no mechanism for analyzing execution trajectories, per- forming causal attribution of failures, or generating categorized behavioral guidance. Our framework addresses this gap by extract- ing structured, actionable tips from execution experience rather than conversational facts. 5.3 Learning from Execution Trajectories A growing body of work addresses how agents can learn from their past execution traces, which is most directly related to our contribution. Workflow and procedure extraction. Agent Workflow Mem- ory (AWM) [13] extracts reusable multi-step workflows from suc- cessful agent trajectories in web navigation, achieving 24.6% and Trajectory-Informed Memory Generation for Self-Improving Agent SystemsTechnical Report, Published Feb 2026, Yorktown Heights, NY Table 12: Summary of Aggregate Improvements: Subtask Tips + LLM Selection PartitionTask GoalTask GoalScenario GoalScenario Goal (Baseline)(+Memory)(Baseline)(+Memory) Test-Normal69.673.2 (+3.6)50.064.3 (+14.3) Train 86.791.1 (+4.4)73.383.3 (+10.0) Dev77.289.5 (+12.3)47.473.7 (+26.3) 51.1% relative improvements on Mind2Web and WebArena respec- tively. AWM demonstrates a compelling “snowball effect” where simple workflows compose into more complex ones. However, AWM only learns from successful trajectories—it has no mecha- nism for extracting lessons from failures, recoveries, or inefficient executions. Mem 푝 [5] treats procedural memory as a first-class optimization object, systematically exploring strategies for build- ing memory from trajectories, retrieving relevant procedures, and updating entries over time. While Mem 푝 addresses the full mem- ory lifecycle, it focuses on procedural instructions (“how to do X”) rather than the diagnostic behavioral insights (“what went wrong and why”) that our tip categories capture. AgentRR [6] borrows the record-and-replay paradigm from software engineering, record- ing complete agent interaction traces and summarizing them into structured experiences for future replay. Like AWM, it primarily learns from successful executions. Reasoning and strategy extraction. ReasoningBank [9] is among the closest works to ours, distilling generalizable reasoning strategies from an agent’s self-judged successful and failed expe- riences. It shares our insight that agents should learn from both successes and failures. The key distinction is in abstraction level: ReasoningBank focuses on meta-cognitive reasoning strategies, while our tips focus on concrete behavioral guidance derived from specific execution patterns. The two approaches are complemen- tary. Context engineering and self-improvement. ACE (Agentic Context Engineering) [16] treats an agent’s context as an evolv- ing “playbook” that accumulates and refines strategies through a generate-reflect-curate cycle, achieving a 10.6 percentage point improvement on AppWorld. Our framework differs from ACE in several respects: we produce structured memory entries with typed categories (strategy, recovery, optimization), rich metadata, and selective retrieval rather than an evolving text document included in full; we perform explicit causal attribution tracing outcomes to specific decisions; and we maintain provenance tracking from tips to source trajectories. Experience replay with learned retrieval. Memento [18] in- troduces a memory-augmented MDP formalization where a learned neural policy selects which stored trajectories to retrieve for a given task. However, Memento stores raw trajectories without abstracting them into transferable insights—the consolidation from trajectory to actionable lesson is left to the LLM’s in-context reasoning. 5.4 Empirical Foundations Xiong et al. [14] provide critical empirical grounding for trajectory- based memory systems, identifying the experience-following prop- erty and two failure modes: error propagation and misaligned ex- perience replay. They find that combining selective addition with selective deletion yields a 10% absolute performance gain over naive memory growth. These findings directly motivate our structured approach: by extracting abstract tips with explicit applicability con- ditions rather than storing raw trajectories, and by categorizing tips with metadata for precise contextual matching, our framework mitigates both failure modes. 6 Conclusions We presented a framework for automatically extracting actionable learnings from LLM-agent execution trajectories and storing them as structured memory tips that improve future agent performance. Our four-component pipeline—trajectory intelligence extraction, decision attribution analysis, contextual learning generation, and adaptive memory retrieval—captures the full spectrum of learning opportunities across failures, recoveries, inefficient successes, and clean successes. Evaluation on the AppWorld benchmark demon- strates consistent improvements, with up to 14.3 percentage point gains in scenario goal completion on held-out tasks, and particularly strong benefits on complex, multi-step tasks (28.5 p SGC improve- ment, a 149% relative increase). The framework naturally extends to multi-agent systems with cross-agent attribution and agent-role- aware guidance, which we leave to future work. We also plan to evaluate the framework with additional state-of-the-art and open- source models—such as Qwen [12] and GPT-OSS [1]—to assess how tip quality and retrieval effectiveness vary across model families. The techniques described in this paper are being applied to IBM’s Configurable Generalist Agent (CUGA) [7,8] platform for build- ing and deploying enterprise agentic systems, where trajectory- informed memory enables agents to continuously improve from operational experience. References [1]. 2025. TODO: Add GPT-OSS reference. Placeholder — please replace with the correct GPT-OSS citation. [2] Prateek Chhikara, Dev Khant, Saket Aryan, Taranjeet Singh, and Deshraj Yadav. 2025. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv preprint arXiv:2504.19413 (2025). [3]Chad DeChant. 2025. Episodic Memory in AI Agents Poses Risks That Should Be Studied and Mitigated. arXiv preprint arXiv:2501.11739 (2025). [4]Yiming Du, Wenyu Huang, Danna Zheng, Zhaowei Wang, Sébastien Montella, Mirella Lapata, Kam-Fai Wong, and Jeff Z. Pan. 2025. Rethinking Memory in AI: Taxonomy, Operations, Topics, and Future Directions. arXiv preprint arXiv:2505.00675 (2025). [5]Runnan Fang, Yuan Liang, Xiaobin Wang, Jialong Wu, Shuofei Qiao, Pengjun Xie, Fei Huang, Huajun Chen, and Ningyu Zhang. 2025. Mem 푝 : Exploring Agent Procedural Memory. arXiv preprint arXiv:2508.06433 (2025). [6]Erhu Feng, Wenbo Zhou, Zibin Liu, Le Chen, Yunpeng Dong, Cheng Zhang, Yisheng Zhao, Dong Du, Zhichao Hua, Yubin Xia, and Haibo Chen. 2025. Get Experience from Practice: LLM Agents with Record & Replay. arXiv preprint arXiv:2505.17716 (2025). [7]IBM. 2025. CUGA: Configurable Generalist Agent. https://github.com/cuga- project/cuga-agent. [8]Sami Marreed, Alon Oved, Avi Yaeli, Segev Shlomov, Ido Levy, Offer Akrabi, Aviad Sela, Asaf Adi, and Nir Mashkif. 2025. Towards Enterprise-Ready Computer Using Technical Report, Published Feb 2026, Yorktown Heights, NYFang et al. Generalist Agent. arXiv preprint arXiv:2503.01861 (2025). [9]Siru Ouyang, Jun Yan, I-Hung Hsu, Yanfei Chen, Ke Jiang, Zifeng Wang, Rujun Han, Long T. Le, Samira Daruki, Xiangru Tang, Vishy Tirumalashetty, George Lee, Mahsan Rofouei, Hangfei Lin, Jiawei Han, Chen-Yu Lee, and Tomas Pfister. 2025. ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory. arXiv preprint arXiv:2509.25140 (2025). [10] Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. 2023. MemGPT: Towards LLMs as Operating Systems. arXiv preprint arXiv:2310.08560 (2023). [11]Mathis Pink, Qinyuan Wu, Vy Ai Vo, Javier Turek, Jianing Mu, Alexander Huth, and Mariya Toneva. 2025. Position: Episodic Memory is the Missing Piece for Long-Term LLM Agents. arXiv preprint arXiv:2502.06975 (2025). [12] Qwen Team. 2025. Qwen2.5 Technical Report. arXiv preprint arXiv:2412.15115 (2025). [13]Zora Zhiruo Wang, Jiayuan Mao, Daniel Fried, and Graham Neubig. 2024. Agent Workflow Memory. arXiv preprint arXiv:2409.07429 (2024). [14]Zidi Xiong, Yuping Lin, Wenya Xie, Pengfei He, Jiliang Tang, Himabindu Lakkaraju, and Zhen Xiang. 2025. How Memory Management Impacts LLM Agents: An Empirical Study of Experience-Following Behavior. arXiv preprint arXiv:2505.16067 (2025). [15]Wujiang Xu, Zujie Liang, Kai Mei, Hang Gao, Juntao Tan, and Yongfeng Zhang. 2025. A-MEM: Agentic Memory for LLM Agents. arXiv preprint arXiv:2502.12110 (2025). [16]Qizheng Zhang, Changran Hu, Shubhangi Upasani, Boyuan Ma, Fenglu Hong, Vamsidhar Kamanuru, Jay Rainton, Chen Wu, Mengmeng Ji, Hanchen Li, Urmish Thakker, James Zou, and Kunle Olukotun. 2025. Agentic Context Engineer- ing: Evolving Contexts for Self-Improving Language Models. arXiv preprint arXiv:2510.04618 (2025). [17]Zeyu Zhang, Xiaohe Bo, Chen Ma, Rui Li, Xu Chen, Quanyu Dai, Jieming Zhu, Zhenhua Dong, and Ji-Rong Wen. 2025. A Survey on the Memory Mechanism of Large Language Model based Agents. ACM Transactions on Information Systems (TOIS) (2025). doi:10.1145/3748302 arXiv:2404.13501. [18]Huichi Zhou, Yihang Chen, Siyuan Guo, Xue Yan, Kin Hei Lee, Zihan Wang, Ka Yiu Lee, Guchun Zhang, Kun Shao, Linyi Yang, and Jun Wang. 2025. Me- mento: Fine-tuning LLM Agents without Fine-tuning LLMs. arXiv preprint arXiv:2508.16153 (2025).

Instant research discovery