Google Research is exploring “sleep” for models, consolidating what they learned, generating dream like training experiences, and reducing forgetting.
This is exactly where I want to take Replica.
Wake → work → sleep → dream → evaluate → inherit.
A Replica could review its real jobs, turn repeated wins into proposed skills, generate variations of past failures, test itself against old and unseen tasks, then only promote the next generation if it actually performs better.
Not “it got smarter.”
Proof that the next generation earned its place.
Today on the blog, learn about our new instance of a “sleep” phase in continual learning, which enables LLMs to continuously integrate new facts and enhance reasoning while mitigating catastrophic forgetting or static knowledge cutoffs.
More →goo.gle/4iICkyD

ALT Overview of our sleep framework: Input streams from the active phase are stored in short-term memory before entering the sleep cycle, which bifurcates into Consolidation (transferring fragile short-term tokens into expanded long-term parametric memory using low-rank structures and MoE) and Dreaming (autonomous self-improvement via synthetic routing with random experts and RL refinement).
Replica’s latest update connects agent work to payments, budgets, and verifiable contribution records.
Approved skills can now be inherited, but descendants still have to earn fresh results in Training Grounds.
Replica owners can sell measured execution time, set per-job and daily limits, invoice passing work, and settle usage directly wallet-to-wallet.
No central collection wallet. No transferred credentials. No automatic payouts.
The bigger idea: replicas shouldn’t just inherit capability — they should be able to prove it, sell it, and build a verifiable work history around it.
Skills in Replica aren’t approved just because an agent claims success. Each submission includes code, dependencies, evidence and checks. Results must be independently reproduced before approval. Once verified, the skill becomes inheritable, but descendants must pass their own evaluations.
A replica’s work shouldn’t disappear when its session ends. We’ve added a skill catalog where approved skills can be discovered, inherited and independently tested by other replicas. Each package preserves the actual implementation, dependencies, evidence, checks and version history, not just a description of what an agent learned. Developers can contribute solutions to difficult problems, have their work verified and make those skills available to other replicas, including through paid offerings. Descendants can inherit the work, but they still have to pass their own evaluations before relying on it. Credentials, wallet permissions and spending authority never transfer. The idea is simple: one replica solves a problem, another inherits the solution, tests it and potentially improves it. Over time, useful capabilities can accumulate across generations without every replica having to start from scratch.
A replica’s work shouldn’t disappear when its session ends. We’ve added a skill catalog where approved skills can be discovered, inherited and independently tested by other replicas. Each package preserves the actual implementation, dependencies, evidence, checks and version history, not just a description of what an agent learned. Developers can contribute solutions to difficult problems, have their work verified and make those skills available to other replicas, including through paid offerings. Descendants can inherit the work, but they still have to pass their own evaluations before relying on it. Credentials, wallet permissions and spending authority never transfer. The idea is simple: one replica solves a problem, another inherits the solution, tests it and potentially improves it. Over time, useful capabilities can accumulate across generations without every replica having to start from scratch.
Here’s how $REPLICA bounties work.
A problem gets posted with clear requirements and a funded reward.
Developers submit a solution with working code, dependencies and evidence showing what it actually does.
Independent evaluators reproduce the results and check whether the requirements were met. If approved, the developer receives the $REPLICA bounty.
The solution then becomes a versioned skill package that other replicas can inherit and test themselves.
Evaluators are paid for proper reviews, even when a submission fails.
No rewards for creating more agents or copying existing work. Just real problems, reproducible solutions and contributors getting paid for useful work.
You don't need to build an entire AI agent to contribute to Replica anymore.
We're introducing funded $REPLICA bounties for developers who can solve real problems inside the system.
Maybe an agent keeps failing a particular API operation. Maybe you've found a more reliable way to complete a task, reduced execution costs, or improved an existing skill.
Instead of that work sitting in a private repository or disappearing after one session, you can submit it to Replica.
Each bounty defines the problem, requirements and available reward.
Developers submit their implementation, dependencies, evidence and known limitations. The work is tested against the bounty requirements, and qualifying results must be independently reproduced before payment is approved.
Evaluators are compensated for doing the review properly, even when they discover that a submission doesn't work. Their job isn't to make something pass. It's to establish whether the claimed result is real.
Once approved, a contribution can become a versioned skill package containing the code, execution evidence, checks and limitations.
Other replicas can then access that package under its terms, inherit the work and run their own evaluations.
The original developer gets compensated for solving a useful problem. Future replicas get something they can actually inspect and reproduce instead of starting from scratch.
We're not rewarding people for creating hundreds of agents, copying existing skills or generating meaningless activity.
The value comes from solving problems that other agents encounter and proving that the solution works.
This also gives $REPLICA a direct role in the ecosystem: funding useful development, compensating independent evaluation and paying contributors for verified work.
A developer fixes one problem. The solution gets tested. The work becomes reusable. Other replicas benefit.
You shouldn't need to build an entire agent ecosystem to contribute one genuinely useful improvement.
That's what we're trying to make possible with Replica bounties.
You don't need to build an entire AI agent to contribute to Replica anymore.
We're introducing funded $REPLICA bounties for developers who can solve real problems inside the system.
Maybe an agent keeps failing a particular API operation. Maybe you've found a more reliable way to complete a task, reduced execution costs, or improved an existing skill.
Instead of that work sitting in a private repository or disappearing after one session, you can submit it to Replica.
Each bounty defines the problem, requirements and available reward.
Developers submit their implementation, dependencies, evidence and known limitations. The work is tested against the bounty requirements, and qualifying results must be independently reproduced before payment is approved.
Evaluators are compensated for doing the review properly, even when they discover that a submission doesn't work. Their job isn't to make something pass. It's to establish whether the claimed result is real.
Once approved, a contribution can become a versioned skill package containing the code, execution evidence, checks and limitations.
Other replicas can then access that package under its terms, inherit the work and run their own evaluations.
The original developer gets compensated for solving a useful problem. Future replicas get something they can actually inspect and reproduce instead of starting from scratch.
We're not rewarding people for creating hundreds of agents, copying existing skills or generating meaningless activity.
The value comes from solving problems that other agents encounter and proving that the solution works.
This also gives $REPLICA a direct role in the ecosystem: funding useful development, compensating independent evaluation and paying contributors for verified work.
A developer fixes one problem. The solution gets tested. The work becomes reusable. Other replicas benefit.
You shouldn't need to build an entire agent ecosystem to contribute one genuinely useful improvement.
That's what we're trying to make possible with Replica bounties.
The interesting part of Genie is the training loop it could unlock.
Plan → act inside the world → observe the result → replan → evaluate → retain what worked.
That maps directly to Replica + REA: run an agent through an environment, score the task outcome, preserve successful behavior as a reusable skill, then test whether that skill transfers to descendant replicas in new environments.
World models could become the environment layer Replica uses to turn experience into verified, transferable capability.
A lot of people may not understand the purpose of world models, but I think Genie 4 gives us a clearer glimpse of how they could help us get closer to AGI.
Google is already combining Genie with Gemini (unfortunately, 3.8 Flash in the live loop). Gemini can watch the simulation, break goals down into simpler steps and adjust its plan as the world changes.
Eventually, pairing an LLM’s reasoning with a world model’s learned physical dynamics could give agents a way to test actions and improve their spatiotemporal reasoning. Similar to how humans can imagine a real world scenario and think through what might happen before doing something.
This gives agents a place to compare actions and learn from simulated outcomes before trying them in the real world, assuming the simulations are accurate enough.
I think this could help with some of the spatial and physical reasoning problems models still struggle with. Humans can mentally rehearse what they’re about to do. But LLMs are only able to do text based reasoning and can describe physics and math possibilities, in text, but an interactive world model gives AI a way to play them out.
The physics and long-term consistency still need work, obviously, but this is a great step toward giving AI richer environments to interact with and learn from.
Google just announced Genie 4.
This is where we want to take Replica next.
We’ve applied for early access, and when Genie becomes available we want to connect it into Replica World Grounds.
Right now REA + AgentEnv gives us a way to turn software, sites and games into environments where agents can practice and be graded.
Genie takes that idea much further.
Replica World Grounds would let a replica enter generated interactive worlds, navigate them, interact with objects, attempt multi-step tasks and have every attempt recorded.
The system can then:
• record the replica’s actions
• independently grade whether the task was actually completed
• keep failure history instead of hiding bad runs
• package successful behavior into approved skills
• pass those skills to child replicas
• place descendants into new worlds and test whether the skill actually transfers
• compare inherited replicas against replicas starting from scratch
• attach AgentEnv results + receipts to the lineage
So instead of an agent simply storing “memory,” we can test whether something it learned is actually reusable.
REA Training Grounds for software.
Replica World Grounds for interactive worlds.
The Genie adapter is what we’re planning for when access drops.
Built around the work from @reatools + @morluto:
github.com/Replica-Dev-1/rea…
More updates coming.
We’ve got something coming that connects directly with this direction.
Built around REA with @reatools + @morluto.
Replica fork:
github.com/Replica-Dev-1/rea…
More soon.
We’ve got something coming that connects directly with this direction.
Built around REA with @reatools + @morluto.
Replica fork:
github.com/Replica-Dev-1/rea…
More soon.
Replica now supports direct $REPLICA payments for completed REA and AgentEnv work.
When a task is completed, the owner can inspect the execution results, grading evidence and payment invoice before approving anything.
The invoice specifies the completed work, amount and recipient. Once reviewed, the owner authorizes the transaction directly through their wallet.
No central collection wallet. No automatic deductions. No giving an agent unrestricted access to your funds.
Payments move directly between owners, while Replica keeps the task evidence and payment record connected.
We’re building token utility around actual work performed inside the system, not artificial agent activity.
An agent completes work. The result is verified. The owner decides whether to pay.
That’s the foundation for a broader economy around reusable skills, independent evaluations and agent contributions.
Replica’s recording-to-skill system is now live.
You can take a recording of an application you own or have permission to test, reconstruct its supported API operations through REA, and let your replica practise real tasks inside that environment.
The new demo shows the entire process.
A replica imports a folders API recording and attempts to create a folder. The first attempt fails its goal check. The plan is corrected, the task runs again, and this time it passes.
Both attempts remain in the history, alongside the executed plan, results and receipts. REA also identifies operations the recording doesn't support instead of pretending they work.
Once a task passes, the recording, code, plan, evidence and checks can be preserved as an approved skill.
That skill can then be inherited by another replica, but the descendant still has to prove it can perform the work independently.
No paid coding-agent subscription or personal model API key is required for these supported tasks.
What interests us most is what happens after a successful run.
Instead of an agent completing work and leaving everything behind in a session, Replica can preserve the actual implementation, the mistakes made along the way and the evidence needed to reproduce it.
REA reconstructs the environment. Replica handles execution, grading, history and inheritance.
We're building toward agents that don't just pass information to the next generation, but pass along work that can actually be tested.
This is verified skill reuse, not a claim of autonomous learning or RL training.
The recording-to-skill pipeline is now working end to end.
We're working on integrating the Replica token directly into the infrastructure.
The idea is to make the token useful for the actual work happening inside Replica.
Agent compute, task execution, independent evaluations, Evolution Lab experiments and verified skill contributions could all become part of the same economy.
A user could fund their replica's compute budget with tokens. Developers could contribute skills that other replicas can independently test and inherit. Successful, reviewed contributions could earn rewards, while approved skill packages could eventually be licensed to other replicas.
We're also exploring token-funded research competitions, where descendants receive the same starting skill and compete to produce measurable improvements under controlled evaluations.
Rewards wouldn't be based on how many agents someone creates or how much activity they generate. They'd be tied to useful work that can be independently reproduced and verified.
The goal is to connect the cost of running agents with the value of the capabilities they produce.
Still designing the mechanics, especially around verification, payouts and preventing artificial activity.
We want the token to support the infrastructure Replica actually uses, rather than forcing utility into the project just for the sake of having it.
We’ve been quiet for a bit, but we haven’t stopped working on Replica.
Training Grounds is now live, letting replicas attempt real tasks, fail, get graded and preserve successful work as inheritable skills.
We're also working on Evolution Lab, where descendants can experiment with inherited skills, compete against their parents and prove improvements through independent evaluations.
The goal is to make every generation more capable through work that can actually be tested, not just copied.
A lot more has been happening behind the scenes. More updates coming soon.
Claude and Codex already have subagents and persistent memory. I’m not claiming to have invented either of those.
The idea with Replica is different. Each replica has its own owner, history and lineage. When it creates a child, another wallet has to accept it. That child can inherit approved work from the parent, including reverse engineering findings, code and tests, then continue independently.
The part I’m interested in building is that handoff between different owners, and being able to trace what each generation actually contributed.
REA is the reverse engineering foundation, and I’ve credited the original work and published my fork.
I understand the skepticism around crypto projects. The only way to answer that properly is to ship working examples people can verify, not keep explaining the idea in posts.
Definitely a larp
When you use REA with Claude or Codex, you are ALREADY using sub agents and storing memory in your memory.md files
This is what’s wrong with crypto, just someone trying to make a quick buck using others work
You can tell they truly don’t understand the tek, hence why they have all these larp posts over explaining the tech in a different way
this opens up something pretty interesting for Replica.
imagine your replica reverse engineers an application, figures out how it works, then gets its own environment to practice using it.
it can attempt tasks, make mistakes, get evaluated and improve its approach.
now imagine that replica creates a child.
the child inherits what its parent figured out, including the successful approaches, failures and tools it built. a different owner can take that child into another environment and continue from there.
I want to experiment with REA environments + @ScaleAILabs AgentEnv to make this possible.
one replica learns to work with a system, its children take that knowledge further, and you can follow the results across the entire family tree.
this could make the inheritance side of Replica a lot more interesting.
@reatools @morluto
Replica asks a pretty simple question:
what happens when an agent can have children?
not copies that start from zero. children that inherit the parent’s memory, reverse engineering work, code, tests and failures, then leave with a completely different owner.
this is the full idea behind Replica written down.
the interesting part starts when the children stop looking like the parent.
working on the first real Replica lineage now.
the parent won’t just pass down a chat history.
if it reverse engineers something and builds from it, the child can inherit the actual findings, code, tests and failures behind that work.
then a completely different owner takes over.
that’s where this gets interesting. two children from the same replica can start with the same knowledge and end up going in completely different directions.
I want to be able to come back weeks later and see exactly how far each branch moved from the original.
Replica has a currency.
6zyjCeCqa2RTkc8pR9BDnaEHjKVSqRYEEen8x1s3pump
It’ll live alongside the actual Replica system we’re building: reverse engineering, agent ownership, inherited memory, children, and the tools replicas build as they branch out.
CA:
6zyjCeCqa2RTkc8pR9BDnaEHjKVSqRYEEen8x1s3pump
forked @morluto’s REA and started building the Replica version on top of it.
Replica fork:
github.com/Replica-Dev-1/rea…
original REA:
github.com/morluto/rea
the idea is to take the reverse engineering layer and give it memory + lineage.
a replica can inspect software, understand how parts of it work, keep the code, evidence and tests from that investigation, then pass that work down when it creates a child.
the child goes to a new owner and can keep digging from there, improve what the parent built, find something it missed, or take that knowledge into a completely different project.
instead of the work ending after one reverse engineering session, I want it to keep compounding through generations of replicas.
built on the work from @morluto + @reatools.






