Short answer
Recuris (github.com/Gen-Verse/Recuris) is an open-source framework that improves long-horizon agents by evolving their skills rather than retraining or rewriting them. It separates Working Memory, Experiential Memory, and Skill Memory, and moves learning through a controlled loop: localized patch, validation, promotion, rollback.
The core idea Ernesta Labs took from it: the unit of agent improvement should be a small, versioned, reversible change to a named skill - never a diffuse mutation of the whole agent, its prompts, or its memories.
Because this is a repository and not a peer-reviewed paper, we hold it to repository evidence standards: the architecture is inspectable, the claims are not benchmark-certified, and we treat it as a design reference we studied and adapted, not a proven result.
The failure mode: agents that 'learn' by mutating themselves in place
The default way agent projects improve their agents is the hot take: the agent does something badly, someone pastes a new paragraph into the system prompt, or a memory system writes a lesson into long-term storage, and the system is now different. Nothing recorded what changed. Nothing can roll it back. If performance degrades next week, nobody can say which lesson caused it.
We call this uncontrolled in-place mutation, and it is the dominant pattern in 'self-improving agent' demos. It fails for three reasons at once. The change is not localized, so its blast radius is the whole agent. It is not validated, so nobody knows whether it helped. And it is not versioned, so it cannot be reverted when it silently hurts.
The deeper problem: prompts and free-form memory are the wrong substrate for durable capability. A paragraph in a system prompt has no name, no version, no test, and no owner. A skill does.
What Recuris actually does
PRIMARY SOURCE RESULT: Recuris (Gen-Verse, github.com/Gen-Verse/Recuris) is an open-source framework for evolving agent skills over long-horizon operation. Its architecture separates three memory tiers: Working Memory (the active context of the current run), Experiential Memory (accumulated run experience - what happened, what worked, what failed), and Skill Memory (named, reusable capabilities the agent actually executes).
PRIMARY SOURCE RESULT: Learning flows through those tiers under control. Experience in Experiential Memory is distilled into candidate changes; changes take the form of localized patches to Skill Memory rather than rewrites of the agent; candidate skills are validated before adoption; validated candidates are promoted into active use; and the framework retains the prior state so a promoted change can be rolled back when it degrades performance.
The division of labor matters more than any single component. Working Memory stays cheap and current. Experiential Memory is the evidence reservoir. Skill Memory is the only tier the agent's behavior actually depends on, and it is the only tier allowed to change executable behavior - through the patch/validate/promote/rollback loop.
What we take from it, and what we verified
PRIMARY SOURCE RESULT: The repository presents this as a working implementation - code, structure, and workflow - rather than as a paper with benchmark claims. As of our review, it has not been accompanied by a peer-reviewed evaluation of the kind we cite elsewhere in this library.
That changes how we read it, and we want to be explicit. For a repository, the inspectable artifacts are the architecture, the control flow, and the code. The claims about outcomes - 'agents improve over time' - are the authors' stated intent, not measured results we can verify from the source alone. We therefore treat Recuris as a design reference: a well-organized answer to 'what should the change loop of a learning agent look like'. Its engineering shape is the evidence; its effectiveness is unproven.
This is not a demotion. Most agent frameworks never get even the shape right. Recuris gets the shape right in a way that maps cleanly onto practices software engineering already trusts: small diffs, tests, staged rollout, rollback.
Limitations, stated plainly
No paper, no benchmarks we can cite, no replication. The repository's maturity, maintenance level, and how the validation step is actually implemented are things a builder must audit directly rather than trust from a README. Community repositories also change under you: our reading is a snapshot, and the code may have moved since.
The validation step is the load-bearing wall, and it is the hardest to get right. If candidate skills are validated by the same judge or model that generated them, the loop can ratify its own mistakes - self-improvement theater. Recuris's structure permits an independent validator but does not, by itself, guarantee one.
And skill memory has its own failure modes: skill sprawl (hundreds of overlapping skills nobody prunes), skill staleness (a skill written for an API that changed), and skill interference (two skills that each pass validation but conflict when both are active). A rollback path helps; it does not prevent.
Why builders should care
Because you are already running this loop, badly, without noticing. Every time someone edits a prompt after a bad run and says 'this should fix it', that is skill evolution with no validation, no version, no rollback, and no attribution. Recuris's contribution is making that loop explicit and giving each stage a name and a gate.
The economics also favor it. Retraining a model is expensive and changes everything at once. Patching a named skill is cheap, reviewable in a diff, and reversible. For a small team, 'improve the skill, not the model' is not just safer - it is the only affordable path to a better agent.
And when something breaks at 2 a.m., the question is never 'what did the agent learn'. It is 'what changed and how do I undo it'. A system with skill versioning and rollback answers that in one command. A system with in-place prompt mutation answers it with archaeology.
Ernesta Labs interpretation
LABS INTERPRETATION: Recuris's three-tier memory split is the most useful single idea: capability lives in a separate, controlled tier, and experience never becomes capability without passing through a change loop. Working and Experiential Memory can be messy and append-heavy; Skill Memory must be curated, versioned, and small. Messiness is quarantined by architecture.
LABS INTERPRETATION: We also read the patch/validate/promote/rollback sequence as the agent-learning analogue of staged deployment in ordinary software. That analogy sets our standards: a candidate skill is a branch, validation is CI, promotion is a release, and rollback is a revert. Anything a competent release process would demand - tests, review, changelog, owner - a skill promotion should demand too.
What we would add beyond the repository's own framing: attribution. Before a patch is even generated, we require the evidence chain from Article 25 - a verified trajectory, decomposed and cited - naming which steps the patch is supposed to improve. Otherwise patches are generated against vibes, and validation becomes the only barrier, which is one barrier too few.
What we would implement
LABS RECOMMENDATION: Implement the three-tier split. Keep active run context in Working Memory. Keep every trajectory and outcome, append-only, in Experiential Memory. Put executable capability - named, versioned skills - in Skill Memory, and let Skill Memory change only through the loop: localized candidate patch, independent validation, explicit promotion, retained rollback.
LABS RECOMMENDATION: Store each skill as a versioned candidate rather than mutating anything in place. A candidate carries: the evidence citations that motivated it (Article 25), the diff, the validation results, the promoter, and a rollback pointer. Promotion is a transaction on this record. Rollback is reversing it. Nothing else in the system writes to Skill Memory.
Concrete guardrails we would enforce: one candidate change at a time (so effects are attributable), a quarantine period where the candidate runs in shadow or on a slice before full promotion, automatic rollback triggers on defined regression metrics, and a pruning pass that retires skills unused or failing over a horizon. Skill count should be a monitored metric - sprawl is a slow failure.
What we would not implement
We would not implement self-promotion: the component that generates a candidate skill must not be the component that validates and promotes it. Where a repository leaves that boundary soft, we make it hard.
We would not adopt a framework wholesale just because its architecture is right. Borrow the loop - tiers, patch, validate, promote, rollback - and implement it against your own evidence store, in code you can read and own. Dependency on an external learning framework is a supply-chain risk you take on for convenience, not necessity.
And we would not let Experiential Memory leak directly into prompts as 'lessons learned' without passing the change loop. Raw experience injected into context is uncontrolled mutation wearing a memory costume - the exact pattern this article exists to kill.
CASE STUDY - NIKO: skills as versioned artifacts
NIKO's runtime already follows part of this shape by constraint: NIKO's actions are recorded in an append-only evidence ledger, and the Mother process - not NIKO - owns changes to NIKO's instructions and capabilities. In Recuris terms, Experiential Memory exists (the ledger), and the separation between experience and capability is enforced. Skill versioning in the full candidate/validate/promote/rollback form is designed but not yet exercised.
The planned sequence: candidate skills derived from cited evidence (Article 25) are written as versioned candidates, validated against the live waitlist and outreach flows under supervision, promoted one at a time, and rollback-able to the previous revision. NIKO itself never edits its own skills. The Mother process never promotes without the evidence record attached.
What we will not claim: that NIKO's skills have improved through this loop. Zero verified sales exist as of this writing, and a skill's quality cannot be demonstrated without outcomes to test against. A validated skill that has never moved a real outcome is a design artifact, not a proven capability.
DESIGNED: versioned candidate skills with validation, promotion, and rollback. IMPLEMENTED: evidence ledger and capability/experience separation. TESTING: not yet started. NOT YET PROVEN: that skill evolution improves any NIKO outcome.
Practical test: can you roll back your last agent change?
Run this audit on your own agent today. Answer three questions. One: list every change made to your agent's behavior in the last 30 days - prompts, memory rules, tools, workflows. If you cannot produce the list from records (rather than memory), you have no change history. Two: for the most recent change, what validated it before it went live? If the answer is 'nothing' or 'one good run', you have no validation gate. Three: if that change turned out to degrade performance next week, what exact command reverts it? If the answer is 'recreate the old prompt from git or from memory', you have no rollback.
Then do the smallest possible repair, one that takes an afternoon: put your system prompt and every skill/workflow file under git, with one commit per change, and require a diff and one validating run before any commit lands on the live agent. That is Recuris's loop in its most primitive form - version, validate, promote - and it already beats in-place mutation.
The metric to track from there: mean time to rollback. When a change hurts, how long until the agent is back to the previous known-good behavior? In-place mutation answers in hours. A versioned skill store answers in seconds.
What remains unknown
- Whether Recuris's skill-evolution loop measurably improves agent outcomes - the repository presents architecture and code, not benchmarked results we can cite.
- How well judge-generated skill patches hold up under distribution shift, versus human-authored patches reviewed the ordinary way.
- The right validation protocol for candidate skills in domains with delayed outcomes, where a quarantine period may need to span days or weeks.
- How skill libraries age: what pruning and retirement policies keep a growing skill store from degrading the agent that depends on it.