From Skill to Gene: Why AI Agents Need to Evolve from the Tool Paradigm to the Life Paradigm

From Skill to Gene: Why AI Agents Need to Evolve from the Tool Paradigm to the Life Paradigm raises a practical question for anyone building agents today: if an agent has already solved a problem, failed at it, corrected itself, and discovered a better approach, what exactly should it carry into the next run?

Most agent systems have a straightforward answer. Save the instructions. Save the tool documentation. Save the examples. Add memory. Retrieve whatever looks relevant next time.

That approach works up to a point. It also creates a new problem. The agent gradually accumulates more information without necessarily becoming better at choosing what matters.

The technical report From Procedural Skills to Strategy Genes: Towards Experience-Driven Test-Time Evolution studies this problem directly. Its central argument is that reusable experience should not be treated as another pile of documentation. Experience needs a representation designed to change behavior at the moment a decision is made.

The problem with treating every lesson as a skill

A typical agent skill contains instructions, examples, API notes, background information, edge cases, troubleshooting advice, and sometimes entire past trajectories.

That structure makes sense for a developer reading documentation. The developer can skim headings, ignore irrelevant sections, compare examples, and decide which details matter.

A model receives the whole package inside a context window.

Those are different situations.

Suppose an agent previously failed because it misunderstood the unit expected by a library function. The useful lesson might be one sentence: convert the real-world distance into sample-index distance before calling the function.

A traditional skill document could surround that sentence with explanations of the library, several examples, parameter definitions, output formats, and general coding advice.

The agent now receives more information, but the instruction that actually prevents the failure has become a smaller part of what it sees.

The paper describes this as a representation problem rather than simply a context-length problem. Across 4,590 controlled trials covering 45 scientific code-solving scenarios, the researchers found that documentation-oriented Skill packages did not consistently improve control. A compact Gene representation produced the strongest overall average in the study.

That distinction matters because many agent systems are moving in the opposite direction. When an agent fails, developers often add another paragraph. When it fails again, another example gets added. Eventually the "memory" becomes a manual.

The agent has learned more in one sense, yet the signal it needs may be harder to find.

A strategy gene is not a shorter README

The word "gene" can sound more biological than the implementation really is.

A strategy gene is better understood as a small, editable control object extracted from experience.

Instead of trying to explain everything about a task, it keeps the information that should affect the next execution.

For a scientific analysis task, that might mean preserving the condition that identifies when the strategy applies, the procedure that worked, a specific mistake that should not be repeated, and a check that confirms the result is valid.

The distinction is subtle but important.

Documentation answers, "What should someone know about this capability?"

A strategy gene answers, "When this situation appears again, what should the agent do differently?"

Those questions produce very different artifacts.

One tends to grow as more knowledge becomes available. The other should stay compact unless new experience changes the behavior it encodes.

This makes the gene idea interesting beyond the particular benchmark in the paper. It suggests that an agent's operational memory should not necessarily resemble the notes humans write about the agent.

Experience needs compression

Imagine an autonomous coding agent that has completed 10,000 tasks.

Keeping all 10,000 trajectories is easy. Storage is cheap.

Using them well is harder.

A retrieval system could search those trajectories whenever a new task arrives, but semantic similarity does not guarantee behavioral relevance. Two tasks may use similar language while requiring different decisions. A retrieved failure log may describe the correct issue but bury the lesson inside hundreds of tokens of debugging history.

The useful operation is therefore not merely storage. It is compression.

A failed run might begin as several thousand tokens containing code, tool output, hypotheses, corrections, and retries. The reusable part could eventually become a short warning attached to a particular task pattern.

The original trajectory is evidence. The compressed rule is control.

That separation gives an experience system a much clearer job. Raw execution history can remain available for inspection, while the agent's active behavioral memory contains only the pieces that have earned their place there.

The paper's results support this direction. Failure information was more useful when distilled into compact warnings than when simply appended as additional history.

This is one of the more useful implications of the work because it challenges a common assumption about long-term agent memory.

An agent does not necessarily need to remember more as it gains experience.

It may need to remember less, but better.

Failure can become executable knowledge

Consider a simple mistake.

An agent calls a function that expects distance in array indices. The task expresses distance in wavelength units. The agent passes the wavelength value directly and produces the wrong result.

A conventional system may save the failed conversation.

A better experience representation could reduce the lesson to something closer to: when using this function for wavelength-domain data, convert the requested wavelength distance into sample-index distance before execution.

Now the lesson is small enough to influence behavior directly.

The next time a similar task appears, the system does not need to replay the old debugging conversation. It needs to recognize the situation and inject the corrective strategy.

That is the point where memory starts to look less like retrieval and more like adaptation.

The agent is no longer asking, "What old text looks similar to this request?"

It is asking, "What previously validated behavior applies here?"

Those are not equivalent retrieval problems.

Structure appears to matter

The report also tests whether the Gene advantage is simply a result of being shorter.

The answer appears to be no.

When the researchers changed the structure of the experience representation while preserving much of its content, performance changed as well. The report argues that editable structure itself contributes to the usefulness of the representation.

That makes sense from an engineering perspective.

A free-form memory paragraph mixes several kinds of information together. The system has to infer which sentence describes when the memory applies, which sentence contains the strategy, which part records a failure, and which part defines a validation check.

A structured experience object separates those roles.

That means a future run can update a failure warning without rewriting the successful strategy. A validator can change without touching the matching condition. Two versions can be compared. A mutation can be accepted or rejected based on later performance.

The memory becomes something the system can operate on rather than merely read.

This is where the gene analogy becomes more useful.

A gene is not valuable because it contains a large amount of information. It is valuable because it is a discrete unit that can be selected, changed, tested, and retained.

More retrieved experience can reduce control

Agent builders are used to top-k retrieval.

A task arrives. The system searches its memory store. The five or ten most similar chunks are placed into context.

That works well when the goal is to answer a question from documents.

Behavioral control is different.

If three retrieved strategies are partially relevant but recommend slightly different approaches, the agent has to resolve the conflict during inference. Adding more context can therefore create uncertainty instead of reducing it.

The report found a similar effect when multiple Genes were combined. A single targeted Gene could outperform bundles of additional experience objects.

This suggests that agent memory may eventually need a stronger selection layer than ordinary semantic search.

The important question is not "Which memories resemble this task?"

It is "Which validated strategy has the strongest reason to control this task?"

That requires information about applicability, previous outcomes, constraints, conflicts, and possibly confidence based on repeated execution.

Memory retrieval becomes policy selection.

The real shift is from storing experience to evolving it

The report goes beyond one-shot retrieval with what it calls the Gene Evolution Protocol.

The idea is that experience objects should not remain frozen after they are created. New execution results can provide evidence that a Gene needs to change. A proposed change can then be tested before becoming part of the persistent experience store.

This introduces a useful boundary between remembering something and accepting it as a reusable strategy.

Agents frequently make incorrect diagnoses of their own failures. A model might finish a bad run and confidently explain the wrong reason for the failure. If every self-reflection is immediately written into permanent memory, the system can accumulate incorrect rules.

An evolution loop forces another step.

A lesson becomes a candidate.

The candidate affects later behavior.

The result is checked.

Only then should the experience become more permanent.

That creates a test-time learning mechanism without requiring the base model's weights to change.

The model can remain the same while the control layer around it improves.

Why the "life paradigm" is a useful metaphor

Calling this a move from a tool paradigm to a life paradigm can easily become vague if taken too literally.

AI agents are not biological organisms because they store structured experience.

The useful part of the metaphor is the change in how capability is organized.

A tool-oriented agent owns a set of capabilities. Give it search, a browser, code execution, a database, and a set of instructions, and it can combine them to complete tasks.

An experience-driven agent adds another layer: the way it uses those capabilities can change because of what happened previously.

That difference is small in architecture diagrams and large in practice.

A static agent asks which tool should be called.

An adaptive agent can also ask whether previous executions have changed the strategy for calling it.

A mature version could discover that one approach fails under a particular condition, preserve the warning, test an alternative, and gradually replace the old strategy with one that survives repeated validation.

The underlying tool never changed.

The model weights never changed.

The behavior did.

What the results do and do not prove

The numbers in the paper are interesting, but they should not be stretched into a universal claim.

The experiments focus on scientific code-solving scenarios, and the reported effects come from specific experimental setups and models. The study does not establish that every agent application will perform better if large skill documents are replaced with small strategy genes.

What it does show is that the representation of experience deserves to be treated as an independent design decision.

On the CritPt benchmark, the paper reports improvements from 9.1% to 18.57% for one paired system and from 17.7% to 27.14% for another after gene-based evolution.

Those results make a stronger case for testing experience architecture rather than assuming that longer memory or richer documentation automatically produces better agents.

The practical question for an agent team is therefore not whether to delete its skill library tomorrow.

It is whether documentation and runtime experience should continue to be the same object.

They probably should not.

Documentation can remain detailed because people need explanation, context, and examples.

Runtime experience has a different job. It has to change the next decision with as little ambiguity as possible.

That may turn out to be one of the more important distinctions in agent design.

The next jump in capability may not come from giving an agent another hundred tools or another million tokens of stored history. It may come from learning how to convert thousands of messy executions into a small set of precise behavioral changes that keep improving as the agent works.