An agent spends ten minutes figuring out a website. It finds the right page, discovers that a button opens a dialog, works around an unexpected state, and finishes the task. Tomorrow, another run encounters the same site. How much of that work should it repeat?
That question brought us to continual learning. Some of our team built Webcmd, a self-learning browser system that retains useful navigation context as agents work. Later runs can consult what earlier runs discovered: page states, workflows, pitfalls, and ways to recover. Live browser behavior remains the source of truth, because websites change.
Working on that problem made a broader possibility hard to ignore. If experience can make the next browser task easier, could it improve how an agent audits code, optimizes a GPU kernel, or reasons through an unfamiliar game?
Experience should change the next attempt
A capable model can still repeat an expensive mistake. It may investigate the same dead end, reconstruct a procedure it previously discovered, or confidently use an approach that failed yesterday. A longer conversation helps within one session, but it does not automatically produce useful guidance for the next one.
We want experience to leave something better behind: a reusable procedure, a corrected assumption, or a sharper test for deciding what to try. In our experiments, the model's weights stay fixed. What evolves is its external guidance: skills and memory that the model can read and revise.
“Never repeat the same mistake twice” is a good aspiration. Making it real requires more than recording failures. A lesson needs a scope: when does it apply, what evidence supports it, and what would show that it has become wrong?
That matters for cost as well as quality. Reusing a reliable procedure could reduce exploration and token use. But producing, reviewing, and testing that procedure also costs something. The useful comparison is the total cost of learning and subsequent work, rather than just the shortest successful run.
What could agents learn?
Browser navigation is one setting with a fairly concrete feedback loop. We are interested in several others. These are research directions, with different kinds of feedback and different ways to fool ourselves.
- QA audits. An agent could learn from findings that maintainers confirm or reject. Beyond detecting a possible bug, it should classify severity as high, medium, or low and state high or low confidence. The feedback should improve both the investigation method and the relationship between confidence and correctness.
- Long-running trading research. This offers a difficult test of learning from delayed, noisy outcomes. A profitable outcome does not prove a good decision, and a pattern can disappear as conditions change. The research question is whether an agent can revise its methods without mistaking luck for evidence.
- Reddit marketing. Different communities respond to different kinds of contributions. An agent could learn which questions, formats, and explanations are useful in each community, using moderation outcomes and substantive responses as feedback. Popularity alone would be an incomplete measure of quality.
- Simulated Luma acceptance. In a controlled acceptance-prediction task, the agent produces a yes/no classification and high/low confidence. Labeled examples let us examine whether its decision rules improve and whether high confidence actually corresponds to more reliable predictions.
- Faceless content creation. An agent producing content without an on-camera presenter could improve its research, scripting, and editing procedures across successive pieces. Retention and audience response provide feedback, though topic choice and distribution make attribution difficult.
- GPU kernel optimization. Correctness checks and measured runtime provide concrete feedback. An agent could retain techniques that work for particular computational patterns, along with the conditions where they help. A faster result on one input is a starting point for further testing.
The common structure is straightforward: attempt a task, observe the outcome, propose a lesson, and test whether that lesson helps later work. The hard part is deciding what counts as evidence.
Remembering is only the beginning
People rarely become better at a craft by retaining a complete transcript of every attempt. We develop habits, compare cases, and revise our methods. That is a useful analogy for the system we want to build, without assuming that an agent learns in the same way a person does.
A growing notebook can become a liability if it accumulates contradictory advice or solutions that apply to only one example. Our goal is guidance that becomes more useful, not merely longer. That means studying which experiences to retain, how to reconcile them, and how to test the resulting changes.
The next posts unpack those questions: the recursive execution model behind our harness, the different things a system can learn, and what game experiments taught us about learning across tasks.