Promotion requires evidence; failures can revoke execution authority.
The problem is not remembering a successful action
An agent completes a complex task. Its trace contains API calls, intermediate decisions, retries, retrieved information and a final outcome. A tempting next step is to save the trace and reuse it when a similar request arrives. But success on one task is not evidence that every decision in the trace was necessary, generalizable or safe. A workflow may have succeeded despite an unnecessary step, a lucky environmental condition or a fragile assumption.
My research question is therefore narrower than making an agent 'learn from experience': under what conditions should a previously successful trajectory be promoted into a reusable procedure, and what evidence should cause that procedure to be rejected or withdrawn? The distinction matters because stored experience can reduce repeated reasoning, but it can also preserve errors with greater consistency.
From experience to a candidate procedure
I think of an observed trajectory as evidence from which a procedure can be proposed, not as a procedure that deserves immediate execution authority. A candidate must identify its inputs, expected outputs, tool permissions, preconditions, postconditions and assumptions about the environment. Values that belong to one user or one transaction must not silently become constants in a generalized workflow.
A practical representation resembles a typed intermediate representation: named operations, explicit data dependencies, bounded branches and declared side effects. This representation makes a proposed workflow inspectable. It also allows a structural checker to reject invalid tool references, incompatible arguments, unbounded execution or missing postconditions before any live execution.
A lifecycle with asymmetric authority
The architecture I am exploring separates candidate, shadow, active and quarantined states. A candidate is proposed from a verified trajectory. Structural validation and controlled replay test whether the candidate behaves coherently on representative cases. In shadow mode, it can predict or simulate actions without controlling the real task. Only a candidate supported by sufficient evidence should be eligible for active execution.
Promotion should be reversible. If a workflow fails postcondition checks, encounters an out-of-distribution request or begins causing unintended side effects, the system should abstain, fall back to a general agent or quarantine the procedure. A crucial design principle is that the mechanism which proposes an optimization should not be the sole authority that approves it.
Why verification must examine state, not prose
An agent can confidently announce that a task is complete while leaving the environment in the wrong state. This makes final-answer accuracy an inadequate evaluation measure for interactive agents. AppWorld, for example, provides tasks across nine simulated applications and 457 APIs, with state-based tests that inspect outcomes and unintended changes. That makes it a useful external benchmark for studying workflow reuse, although my planned AppWorld evaluation should not be confused with completed results.
Verification should test intended postconditions, forbidden side effects, permission boundaries and recovery behavior. Where a task has no reliable automated oracle, human review or conservative abstention may be more appropriate than self-certification.
The real test: reuse versus restraint
A successful reusable workflow should save model-mediated computation on genuinely similar tasks. Yet aggressive reuse may increase wrong executions. I would evaluate verified task success, incorrect action rate, fallback and abstention rates, execution cost, latency and the number of full-agent decisions avoided. The important comparison is not only against an agent with no memory, but also against a simpler cache or fixed workflow that may already solve the problem.
Related-but-not-identical tasks are especially informative. If a workflow learned to update a record for one customer, will it correctly reject a request involving different authorization, an absent field or a changed API? The capacity to recognize when not to reuse a procedure is as important as the capacity to reuse it.
What could become possible
A mature system could compile recurring tasks into increasingly efficient procedures while retaining a cautious general-agent fallback for unfamiliar cases. It might maintain task-specific reliability histories, periodically revalidate old workflows after API or policy changes, and allocate verification effort according to the consequences of failure.
This is an ongoing independent research direction, not a claim that autonomous self-improvement has been solved. The deeper question is how an agent can gain efficiency from experience without converting a contingent past success into unjustified future authority.