PREPING: Zero-Task Agent Memory Construction via Self-Practice

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Today's paper: "PREPING: Zero-Task Agent Memory Construction via Self-Practice".

Jane: Agent memory construction can be achieved before any target-environment tasks are available by using controlled synthetic practice to build reusable procedural memory.

Tom: First, who's behind it and why it matters.

Paper summary: Tom: So we’re looking at the paper PREPING: Zero-Task Agent Memory Construction via Self-Practice. The main thing here is addressing that cold-start problem where an AI agent has no experience in a new environment and can't build any memory before it even sees a real task.

Jane: Right, so if you’re driving or walking and you don't know the road yet, you have no map. This paper is looking at how an AI can build that map just by practicing things on its own before it ever gets a real job to do. It claims that this is possible using only self-generated synthetic practice instead of needing human demonstrations upfront.

Lu: The core thesis of PREPING is that synthetic interaction alone isn't enough because you have to control what you practice and what you store, otherwise the synthetic tasks just become useless or redundant, and memory degrades fast with unfiltered data.

Meng: I’m wondering how they handle that control part. If we just throw random synthetic tasks at it, it’s going to be a mess of noise that doesn't actually help us deploy anything useful on real traffic.

Lalam: The paper introduces something called proposer memory, which is this structured control state that shapes future practice by generating synthetic tasks conditioned on that state and then having a solver execute them.

Tom: Okay, so we have the proposer memory, which dictates what the AI practices next. Then there’s the solver executing those tasks to produce trajectories. And before those go into memory, there’s a validator that checks if they are even worth storing.

Jane: That sounds like a loop where one part guides practice and another part decides what gets saved for later use when the agent actually goes out into the real world. It’s about making sure you only store things that matter to the task at hand, not just everything it tried.

Lu: They separate this into two memory states: proposer memory, or Mprop, which is this construction-time control state guiding proposals, and solver memory, or Msol, which is the deployment-facing procedural memory that the agent will actually use later.

Tom: The update rules are interesting because they’re asymmetric; all experience goes into updating the proposer memory, but only feasible task-trajectory pairs get eligible for solver memory updates. That means rejected tasks still teach the system how to propose better things, even if they don't make it into its long-term memory.

Meng: From a production standpoint, that selective update rule is what I’m interested in because it filters out the junk from the noise and only keeps things that are actually useful for solving problems at scale.

Jane: It sounds like they are trying to build a reusable procedure, which is different from just accumulating a huge log of everything it ever saw. It’s about distilling usable knowledge before deployment.

Paper summary: Lalam: The control mechanisms involve the proposer memory containing a practice-history view and a grounded-environment view, and then the validator uses those views to filter out infeasible pairs by giving feedback to guide future proposals.

Tom: So, the proposer memory tells it what to do next based on its history of tools used or APIs invoked, and the grounded-environment view helps it understand the real constraints of its world while validating if a task is feasible before it commits that trajectory to solver memory.

Jane: It seems like they are creating a system where the agent learns how to plan and practice in a safe, controlled synthetic space first so it’s ready for deployment with less initial friction.

Lu: The experimental results on AppWorld, BFCL v3, and MCP-Universe show that PREPING substantially improves over a no-memory baseline and achieves performance competitive with strong playbook-based methods built from offline or online experience.

Tom: Specifically, on AppWorld, PREPING builds memory before the first user task and improves over a no-memory baseline by seventeen point one points, while on BFCL v3 it improves by nineteen point three points compared to its base ACE-Online setup <ref:2605.13880#pg3>.

Meng: That comparison against ACE-Online is telling because it shows that PREPING achieves this level of performance without needing to accumulate fifty-eight tasks on AppWorld or even getting to two hundred tasks on BFCL v3, which means less upfront effort for the deployment team <ref:2605.13880#pg2,200 tasks on BFCL v3>.

Jane: It really emphasizes that the benefit isn't just about how many synthetic interactions you run; it’s about this proposer-side control over feasibility, redundancy, and coverage combined with those selective memory updates.

Lu: The ablations show that validation-gated admission is crucial because unfiltered trajectories can actually distill infeasible objectives or constraint violations into solver memory.

Tom: So, the main thing they’re arguing isn't just the volume of synthetic tasks but how the proposer controls feasibility and coverage, which directly impacts how useful that memory becomes.

Jane: And it has deployment benefits too; PREPING offers an initialization for online memory construction, and it can be frozen pre-task memory, which reduces deployment-time cost by two point nine nine times on AppWorld and two point two three times on BFCL v3 compared to the online method ACE-Online.

Lu: The conclusion is that PREPING demonstrates procedural memory can be constructed before deployment, outperforming pre-task baselines and providing a strong initialization for online memory adaptation.

Tom: So, if you're thinking about shipping an AI agent into a new environment where you don't have any prior human tasks, this paper suggests you can actively prepare its procedural memory through controlled practice instead of just waiting for real deployment interactions.

Jane: That means the future of building these agents isn't just passive accumulation from real user feedback; it’s about proactively preparing them with structured, environment-grounded synthetic practice before they ever go live.

Conclusion: Tom: So we’ve been talking about how an agent can build memory before it even sees its first real task, and now we’re looking at the final word on this paper, "PREPING: Zero-Task Agent Memory Construction via Self-Practice."

Jane: Right, so to recap, they’re saying you can actually build procedural memory using only controlled synthetic practice before deployment. It’s a big deal because it tackles that cold-start problem head-on for agents in new settings.

Lu: Yeah, the core idea is this proposer guided framework. You have a control state, proposer memory, that shapes all the future tasks the agent practices based on what it’s already learned about its environment.

Meng: I’m still thinking about how much control they really have over that practice distribution when you're talking about millions of interactions in production. Is this just a fancy way to say we need better initial setup scripts?

Lalam: No, it’s more specific than that. They introduce proposer memory as a construction-time state, which is totally different from the solver memory the agent actually uses later when it's deployed.

Tom: That asymmetry is key then. All experience updates that control state, but only feasible task trajectories get slotted into the actual procedural memory for solving problems. That’s a clear mechanism for filtering out the noise we talked about earlier.

Jane: And they show this works across AppWorld, BFCL v3, and MCP-Universe with performance that beats simple no-memory baselines by significant margins on those specific benchmarks.

Lu: The main finding is that it isn't just about the volume of synthetic practice; it’s about the proposer side control over feasibility and coverage, combined with that selective memory update mechanism.

Meng: So if I understand this right, the real win isn't running a million useless tasks, but having a system that intelligently decides what to practice and what to actually save for when it goes live?

Tom: Exactly. And it has some pretty practical deployment implications too, as an initialization method for online memory construction that cuts down the deployment cost by about three times on AppWorld.

Jane: It really shifts the idea from just passively accumulating data from real users to actively preparing the agent with structured practice before it ever hits the real world.

Lu: So this suggests that procedural memory doesn't have to be something you wait for deployment to build; it can be a proactive process driven by controlled, environment-grounded practice.

Meng: That’s a strong direction if we think about scaling up these systems without needing massive amounts of human interaction upfront.