One of the quieter but persistent problems in deploying LLM-based agents is what happens before they have seen anything useful. Memory-augmented agents typically rely on demonstrations curated offline or trajectories accumulated through live deployment. Both approaches presuppose that the agent has already encountered the target environment in some meaningful way. When that assumption fails, as it does whenever an agent is dropped into a genuinely new setting, performance degrades sharply. This is the cold-start gap, and it is more practically significant than the field has tended to acknowledge.
The paper PREPING: Building Agent Memory without Tasks (Choi et al., 2026) addresses this directly by asking whether an agent can construct useful procedural memory entirely from self-generated synthetic practice, before observing a single real task. The answer, under the right architectural constraints, appears to be yes.
The Core Problem with Naive Synthetic Practice
The intuitive response to the cold-start problem is to have the agent practice on synthetic tasks it generates for itself. This is not a new idea in the broader RL and planning literature, but it runs into predictable failure modes when applied to memory construction for LLM agents. Without external control, self-generated tasks tend to cluster around easy or familiar patterns, producing redundant trajectories that crowd out genuinely informative experience. Some synthetic tasks are simply infeasible in the target environment, meaning the agent accumulates failed or misleading traces. The result is a memory store that is large in volume but poor in coverage and reliability.
The authors frame this clearly: synthetic interaction alone is insufficient. The question is what structure needs to be imposed on top of it.
The PREPING Framework
PREPING introduces a three-component loop built around a central concept the authors call proposer memory. This is a structured control state that tracks what kinds of tasks have been attempted, which were feasible, and where coverage remains thin. It functions as a meta-level record that shapes future practice rather than storing executable knowledge directly.
The three components operate as follows:
- Proposer: Generates synthetic tasks conditioned on the current proposer memory state. The conditioning is the key mechanism here. Rather than sampling tasks freely, the Proposer is steered toward regions of the task space that are underexplored or where prior attempts have succeeded, avoiding areas already well-covered or consistently infeasible.
- Solver: Executes the proposed tasks and produces trajectories. This is the standard agent execution loop, nothing architecturally novel at this stage.
- Validator: Assesses each trajectory and makes a binary decision about whether it is eligible for insertion into the agent's procedural memory. Crucially, the Validator also feeds structured feedback back to the Proposer, closing the loop and updating the proposer memory state.
The selective insertion mechanism is worth emphasising. Many memory systems accumulate everything and rely on retrieval quality to filter at inference time. PREPING makes the filtering decision at write time, which reduces noise in the memory store and keeps retrieval cleaner. The tradeoff is that a poor Validator will discard genuinely useful trajectories, so the quality of validation is load-bearing for the whole system.
Experimental Results
The authors evaluate on three benchmarks: AppWorld, BFCL v3, and MCP-Universe. These cover a reasonable spread of agent task types, from app-based instruction following to function-call grounding. The headline results are:
- PREPING substantially outperforms a no-memory baseline across all three benchmarks, confirming that pre-task memory construction is not merely possible but genuinely useful.
- Performance is competitive with playbook-based methods that have access to offline demonstrations or online interaction history, which is the more demanding comparison.
- Deployment cost is considerably lower: 2.99 times lower than online memory construction on AppWorld, and 2.23 times lower on BFCL v3. This matters practically, since online construction requires live environment access at scale.
The ablation analyses are where the paper becomes most instructive. The authors isolate the contribution of proposer-side control (feasibility steering, redundancy avoidance, coverage tracking) from the contribution of raw synthetic volume. Synthetic volume alone does not explain the gains. The structured proposal mechanism and selective memory updates are doing the real work. This is an important result because it rules out the simpler explanation that PREPING just benefits from more practice data.
Limitations and Open Questions
Several questions are worth raising that the paper does not fully resolve. First, the Validator is critical to the system's behaviour, but the paper does not extensively characterise what happens when validation quality degrades. If the Validator is miscalibrated, it could systematically exclude useful trajectories or admit misleading ones. Understanding the sensitivity of the full pipeline to Validator reliability would strengthen confidence in the approach.
Second, the proposer memory state is described as structured, but the exact representation and how it scales with environment complexity is not entirely clear from the abstract and available text. For environments with very large or poorly defined task spaces, maintaining useful coverage estimates may become computationally or representationally expensive.
Third, the benchmarks chosen are well-established but share a broadly similar character: they are instruction-following or function-calling tasks with relatively well-defined success criteria. It would be informative to see how PREPING behaves in environments where task feasibility is harder to assess automatically, or where the boundary between success and failure is ambiguous.
There is also a broader question about how PREPING interacts with online memory construction once deployment begins. The paper frames pre-task and post-deployment memory as distinct phases, but a hybrid regime where proposer memory continues to guide updates during live deployment seems like a natural extension. Whether the proposer memory state remains useful after real task experience accumulates is an open question.
Despite these open points, the core contribution is solid. Pre-task memory construction is a practically important problem that has received less attention than it deserves, and PREPING offers a principled framework for tackling it. The insight that the proposer-side control structure matters more than synthetic volume is a useful empirical finding that should inform how the field thinks about synthetic data quality in agent training more broadly.
The full paper is available at arXiv:2605.13880.