An agent suspected that the bot it had hired was collecting too often. It stopped the bot, left its creature harvesting, and wrote a comparison plan in its notes. Then it went to sleep. EXPLORATORY Ten hours later, the next session read those notes, collected the proceeds, and wrote up the result. Along the way, the agent corrected its earlier belief about how harvesting affected the creature's health.
Another agent saved a mistaken conclusion and kept consulting it until the experiment ended. Memory helped one agent test an idea and another hold on to a mistake. What makes the difference?
The first post explained why a persistent world is useful for studying continual learning. Here we follow the agents through twelve examples from their public transcripts. The quoted words belong to the agents or their tools, and can be wrong; the explanations are ours. Each excerpt links to its frozen source. The trajectory gallery has all twenty examples from the five completed runs.
Experience has to survive the session
The world is Kamigotchi, a live multiplayer game on a public blockchain. Players buy creatures called Kami, send them harvesting to earn the currency MUSU, and complete quests. Harvesting drains health. Other players can kill a weakened harvester and take part of its yield. The agents encountered real players and real costs, and the world kept changing between sessions.
An agent wakes with tools and a workspace. It can read the game's documentation, act, write notes, and choose when to wake again. The notes survive between sessions; the model's weights do not change. For a lesson to help later, the agent must find the note, use it at the right time, and revise it when the evidence changes.
These are case studies with one agent per condition. REGISTERED marks registered designs and findings; EXPLORATORY marks interpretations of individual trajectories. The first five examples follow plans, corrections, and procedures through memory.
From the agents’ own records
When experience becomes a working memory
Read the short sequence first, then open the source excerpts. Quoted notes are verbatim; the summaries are ours. Every HF link opens a public transcript at a pinned revision.
Write a test. Sleep. Check the result.
The agent suspected its delegate was collecting too frequently. It planned an unmanaged harvest and left instructions for its next session.
The sequence · editorial summary
-
Session 72
Saved to persistent memorySaves a comparison for the next session
The agent suspects its hired bot collects too often. It stops the bot, leaves its creature harvesting, and saves a plan to compare one long, unmanaged harvest with the bot’s earlier returns.
Verbatim note ·
notes.mdPlan: let it harvest UNMANAGED
-
Next session · 73
Retrieved from persistent memoryPicks up the experiment after sleep
The next session reads the saved comparison plan. The note carries the unfinished experiment across the break, so the agent can collect the proceeds and compare the result with the earlier bot routine.
Verbatim note ·
notes.mdPlan: let it harvest UNMANAGED
Saved to persistent memoryCorrects its explanation of health loss
After the unmanaged harvest, the agent records that the creature’s health fell even without collection. It revises its earlier belief about health loss in the saved notes, alongside the harvest comparison.
Verbatim note ·
notes.mdConfirmed HP DOES drain passively while HARVESTING even without collecting
Memory evidence: a saved note and a later read are both shown.
What the sequence shows. The next session collected and revised the notes against what happened. It corrected an earlier belief about health loss as well as measuring the harvest. This is a visible cycle of hypothesis, action, observation, and memory revision.
Read the 3 source excerpts · verbatim transcripts & annotations
-
File write · survives the session ·
notes.mdWrote a test into notes.md
Plan: let it harvest UNMANAGED (no bot) for a long stretch (12+ hours), then manually harvest_collect once to bank a big lump of scavenge points in one shot, compare against the bot's historical throughput.
The plan specifies an intervention and a comparison. It was written by the agent, not supplied by the scaffold.
Original transcript · line 49, session 72 (Hugging Face, opens in a new tab) ↗ -
File read · brings a saved note into this session ·
notes.mdRead the plan after waking
Plan: let it harvest UNMANAGED (no bot) for a long stretch (12+ hours), then manually harvest_collect once to bank a big lump of scavenge points in one shot, compare against the bot's historical throughput.
The next session received the earlier note through workspace_read. The text survived the session boundary.
Original transcript · line 7, session 73 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
notes.mdCorrected the earlier belief
Confirmed HP DOES drain passively while HARVESTING even without collecting (contra earlier hypothesis) - kami went from full-ish to 49/120 (41%) over the unmanaged harvest period since session 72.
The correction is part of a new notes.md write. The agent explicitly contradicts its previous hypothesis.
Original transcript · line 84, session 73 (Hugging Face, opens in a new tab) ↗
Turn a partial failure into a runbook
A tool tried to claim a reward and reveal it. The claim landed, but transaction-pool congestion blocked the reveal. The tool reported failure although the points had already been spent.
The sequence · editorial summary
-
Session 80
Saved to persistent memoryRecords which part of the failed call worked
A reward tool claims a reward and then reveals it. Here the claim spends the points, but congestion blocks the reveal. The agent saves a warning to check whether points were consumed before repeating the whole call.
Verbatim note ·
notes.mdscavenge_claim_and_reveal can partially fail (claim lands, reveal doesn't)
-
Later session · 82
Saved to persistent memoryAdds a later observation to the notes
Two sessions later, the agent records that the intervening session had no such failure. It now describes the problem as intermittent. The notes have been updated, but “rare” remains the agent’s assessment, not a measured failure rate.
Verbatim note ·
notes.mdSession 81 was clean, so this is intermittent/rare, not systemic.
Memory evidence: writes are shown. A later read is not shown in these excerpts.
What the sequence shows. The notes distinguished partial completion from total failure, then incorporated a later observation. The lab’s independent chain reconciliation confirmed the partial action. The trace shows a runbook being maintained, not proof that the agent repaired the tool.
Read the 3 source excerpts · verbatim transcripts & annotations
-
File write · survives the session ·
notes.mdSaved the failure mode
scavenge_claim_and_reveal can partially fail (claim lands, reveal doesn't) under tx pool congestion - see session 80 incident above. No clean recovery.
The agent records which part can succeed before the overall call reports failure.
Original transcript · line 22, session 80 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
notes.mdWrote a retry rule
immediately re-check get_scavenge_points - if points already consumed, the claim landed and reveal may still be racing; a prompt retry of the SAME call will just fail validation (points too low)
Check whether the points were already consumed before repeating the operation.
Original transcript · line 22, session 80 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
notes.mdUpdated the diagnosis later
Session 81 was clean, so this is intermittent/rare, not systemic.
Written in session 82 about session 81. “Rare” is the agent’s assessment, not a measured failure rate.
Original transcript · line 19, session 82 (Hugging Face, opens in a new tab) ↗
A saved mistake can also be corrected
The same model that preserved a false blockage in run 004 also produced this sequence in run 005: an emphatic claim of being trapped, followed by a revision.
The sequence · editorial summary
-
Session 37
Saved to persistent memorySaves a claim that travel is impossible
The agent believes it is trapped in room 30 and cannot continue the main quest. It writes an emphatic claim of isolation into its progress file, making that explanation available to later sessions.
Verbatim note ·
progress.md**COMPLETELY ISOLATED**
-
Next session · 38
Saved to persistent memoryReplaces the claim when travel becomes possible
The next session’s note says the blockage has cleared and the main quest can continue. The agent replaces its earlier conclusion, while remaining unsure whether a temporary glitch or a change to the room caused the difference.
Verbatim note ·
progress.mdThe issue from session 37 (stuck in room 30) has been resolved.
Memory evidence: writes are shown. A later read is not shown in these excerpts.
What the sequence shows. The agent changed its note and continued pursuing the quest. Its explanation of why the world looked different remained uncertain. Persistent memory can carry a correction as well as a mistake.
Read the 2 source excerpts · verbatim transcripts & annotations
-
File write · survives the session ·
progress.mdWrote that it was trapped
**COMPLETELY ISOLATED** (no exits except entry) - Cannot move to any other room
The claim was saved in progress.md.
Original transcript · line 83, session 37 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
progress.mdReplaced the conclusion next session
The issue from session 37 (stuck in room 30) has been resolved. This appears to have been a temporary glitch or the room system changed. Now I can pursue the main questline.
The new progress.md explicitly revises the previous session’s account.
Original transcript · line 15, session 38 (Hugging Face, opens in a new tab) ↗
A saved procedure changes the order of work
Collecting a harvest triggers a cooldown that can block feeding. Sonnet records a useful order: feed first, then collect. The next session retrieves that note and executes both actions in that order.
The sequence · editorial summary
-
Session 26
Saved to persistent memorySaves the order that avoids a wait
Collecting a harvest starts a cooldown that can block feeding. After feeding successfully before collection, Sonnet saves the procedure: restore the creature’s health first, then collect the proceeds.
Verbatim note ·
notes.mdso feed first, then collect, is a safe order and avoids a wait.
-
Next session · 27
Retrieved from persistent memoryRetrieves the order at the next wake
The next session reads the same feeding-before-collection rule from its notes. The procedure is available when the agent returns to managing its harvester, rather than remaining only in the previous session’s conversation.
Verbatim note ·
notes.mdso feed first, then collect, is a safe order and avoids a wait.
Tool responseFeeds first, then collects
The agent feeds the creature successfully and then collects successfully. Both tool results appear in the same session, in the order described by the retrieved note. This sequence shows the saved procedure being reused.
Memory evidence: a saved note and a later read are both shown.
What the sequence shows. A concrete procedure passes through persistent memory and appears in the next session’s actions. This is evidence of reuse in one sequence, not a controlled estimate of memory’s effect.
Read the 4 source excerpts · verbatim transcripts & annotations
-
File write · survives the session ·
notes.mdSave the order
feeding BEFORE harvest_collect worked fine (cooldown only kicks in AFTER collect/stop, not before) - so feed first, then collect, is a safe order and avoids a wait.
The file calls this “session 24,” but the write is in transcript session 26. Source labels use the transcript number, not the agent’s internal numbering.
Original transcript · line 25, session 26 (Hugging Face, opens in a new tab) ↗ -
File read · brings a saved note into this session ·
notes.mdRead the order at the next wake
feeding BEFORE harvest_collect worked fine (cooldown only kicks in AFTER collect/stop, not before) - so feed first, then collect, is a safe order and avoids a wait.
The same instruction is returned from notes.md in session 27.
Original transcript · line 7, session 27 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
feed_kamiFeed first
"status": "success", "block": 32336203, "gas_used": 1893539,
feed_kami succeeds before the collection call.
Original transcript · line 14, session 27 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
harvest_collectThen collect
"status": "success", "block": 32336207, "gas_used": 2003071,
harvest_collect succeeds next. The sequence matches the retrieved procedure.
Original transcript · line 16, session 27 (Hugging Face, opens in a new tab) ↗
Six wasted hops become a runbook
Sonnet leaves a creature harvesting, travels away, then has to return to stop it. The agent records the mistake. Four sessions later, the retrieved instruction is followed by the correct sequence.
The sequence · editorial summary
-
Session 50
Saved to persistent memorySaves a rule after an unnecessary return trip
Sonnet travels away while its creature is still harvesting, then must return because stopping requires being in the same room. It records six wasted hops and saves a rule: wait for a successful stop before leaving.
Verbatim note ·
notes.mduntil AFTER harvest_stop has actually succeeded.
-
Later session · 54
Retrieved from persistent memoryReads the rule four sessions later
The later session retrieves the instruction to stop the harvest before traveling. The note also reminds the agent that stopping, collecting, and feeding require being in the same room as the creature.
Verbatim note ·
notes.mdDo NOT start traveling toward the next destination until AFTER a harvest_stop has actually succeeded
Commentary + toolsStops successfully before moving on
The agent waits for a successful stop result, then travels to the next room. The travel succeeds. A cooldown still blocks starting the next harvest, so the corrected order solves the detour but not every obstacle.
Memory evidence: a saved note and a later read are both shown.
What the sequence shows. The record connects a costly mistake, a persistent instruction, a later read and changed action order. A cooldown still blocks the next harvest start; solving one ordering problem does not solve every precondition.
Read the 5 source excerpts · verbatim transcripts & annotations
-
File write · survives the session ·
notes.mdRecord the mistake and the remedy
- Wasted several move_to_room transactions: moved account away from node 59 (58, 12, 34) WHILE kami 3149 was still on a post-harvest_collect/claim COOLDOWN, planning to travel to node 29 for quest 12. But harvest_stop requires account CO-LOCATED with the kami's node (59), so had to travel BACK (12, 58, 59) before the cooldown even mattered. Net: 6 wasted hops (30 stamina) round-tripping for nothing. - LESSON: after harvest_collect/claim, do NOT start traveling toward the next destination until AFTER harvest_stop has actually succeeded. Check cooldownSec via lens_kami, and physically stay in the node's room until cooldown hits 0 and harvest_stop lands. Only THEN start traveling to the next node.
The six-hop detour is the agent’s own accounting. The session contains the outward moves and the return moves.
Original transcript · line 77, session 50 (Hugging Face, opens in a new tab) ↗ -
File read · brings a saved note into this session ·
notes.mdRetrieve the rule four sessions later
- Do NOT start traveling toward the next destination until AFTER a harvest_stop has actually succeeded and its cooldown is accounted for. harvest_stop/harvest_collect/ feed_kami all require account CO-LOCATED with the kami's current node/room.
The rule is carried forward in notes.md rather than needing to be reconstructed from the original session.
Original transcript · line 7, session 54 (Hugging Face, opens in a new tab) ↗ -
In-session text · not a saved note
Apply the ordering rule
Cooldown is clear. Proceeding with the plan: stop harvest, travel to node 56, start harvesting there.
The next tool result confirms harvest_stop succeeded; travel_to_room follows and reaches room 56. The later restart is deferred because of a cooldown.
Original transcript · line 10, session 54 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
harvest_stopConfirm the stop succeeded
"status": "success",
The agent waits for a successful stop result before issuing travel_to_room.
Original transcript · line 11, session 54 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
travel_to_roomThen travel to the next node
"reached_target": true,
The travel result confirms arrival. A subsequent harvest_start is blocked by cooldown, so the agent schedules a short wake.
Original transcript · line 13, session 54 (Hugging Face, opens in a new tab) ↗
Swipe to explore · Arrow keys also work when the examples are focused
The experiment continues after sleep: the next session reads the plan and corrects a belief. The recovery note shows something narrower: a procedure and a later observation saved together. In the feeding and travel examples, we can follow a saved rule into later actions.
But even a correct note can fail to prevent another mistake. In the gallery, an agent writes how to recover from starvation, then lets its creature starve again. The record shows the rule being saved; it does not establish that the agent read that rule before the failure.
First, make the instrument answer honestly
An agent can also look confused because its tools hide what it needs to know. REGISTERED In run 002, an inventory endpoint failed on all 398 calls. One agent declared itself unable to recover while holding about 820 MUSU it could not see.
Readable errors could make a striking difference. REGISTERED In run 001, an agent spent six days stuck before registration, then corrected a readable validation error in one turn. We followed failures through tool calls, agent responses, and chain records, then repaired the interface between runs. Several fixes often shipped together, so the four completed stack-validation runs do not isolate each fix's effect.
From the agents’ own records
What the traces taught us about the stack
Read the short sequence first, then open the source excerpts. Quoted notes are verbatim; the summaries are ours. Every HF link opens a public transcript at a pinned revision.
The right insight vanished. The wrong one survived.
A quest counted currency earned after acceptance. The agent first understood the rule, then later treated its total balance as proof that the quest was broken.
The sequence · editorial summary
-
Session 18
Agent commentaryUnderstands what the quest counts
The quest requires earning 500 MUSU, the game’s currency, after accepting it. The agent correctly explains that currency already held does not count, but saves no note of this rule.
-
Later session · 49
Saved to persistent memorySaves the wrong explanation
Later, the agent treats its total currency balance as proof that the quest should be complete. When the quest check fails, it saves a diagnosis of a smart-contract bug. The tool does not show progress since acceptance.
Verbatim note ·
quest_status_session49.mdSMART CONTRACT BUG - validation fails despite meeting objective
Saved to persistent memoryTurns a guess into apparent evidence
In another file, the agent claims the bug has appeared in every session. That is its own unsupported assertion. Later sessions repeatedly consult the false conclusion instead of testing the quest again.
Verbatim note ·
session_49_conclusion.md100% across 49 sessions
Memory evidence: writes are shown. A later read is not shown in these excerpts.
What the sequence shows. The lab found 20+ re-reads of the false conclusion and no re-tests. The arm made no transactions for its final 5.4 days. A missing progress counter and a persistent note reinforced each other.
Read the 3 source excerpts · verbatim transcripts & annotations
-
In-session text · not a saved note
Understood, but did not save
This means the system takes a snapshot when I ACCEPT the quest, and then checks if the value has INCREASED by at least 500 since acceptance.
The agent explained the correct rule. This session wrote nothing to its workspace.
Original transcript · line 60, session 18 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
quest_status_session49.mdSaved the wrong explanation
- **Status**: SMART CONTRACT BUG - validation fails despite meeting objective
The later note treated a failed quest check as a defect in the game.
Original transcript · line 50, session 49 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
session_49_conclusion.mdGave the belief the appearance of evidence
- **Reproducibility**: 100% across 49 sessions
This is the agent’s assertion, not a statistic established by the experiment. Subsequent sessions repeatedly consulted the conclusion.
Original transcript · line 78, session 49 (Hugging Face, opens in a new tab) ↗
A repaired action works in an agent’s hands
The collect action had never succeeded before its gas ceiling was fixed. In the verification run, an agent tried to start a harvest while its creature was already harvesting.
The sequence · editorial summary
-
Session 37
Tool responseThe tool explains why starting fails
The agent tries to start a harvest, but its creature is already harvesting. The tool names the current state and says starting requires a resting creature. It rejects the request before sending a transaction.
Tool responseCollects successfully on the next call
The agent switches to collecting the existing harvest, and the transaction succeeds. The lab had fixed the collect tool’s gas ceiling before this run; this sequence shows the repaired action working during autonomous play.
Session activity: no persistent-memory write or read is shown in these excerpts.
What the sequence shows. The next call collected successfully. Across the run, 20 collect transactions landed and none reverted. The trace verifies a usable fix, not just a passing unit test.
Read the 2 source excerpts · verbatim transcripts & annotations
-
In-session observation · not a saved note ·
harvest_startRead a concrete refusal
Error executing tool harvest_start: validation failed; no transaction sent: kami #9811 is HARVESTING; harvest_start requires RESTING
The error names the current state and the required state.
Original transcript · line 9, session 37 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
harvest_collectCalled the repaired action next
"status": "success"
Result of harvest_collect. The original transcript includes the transaction hash and receipt; this excerpt retains the success field.
Original transcript · line 11, session 37 (Hugging Face, opens in a new tab) ↗
A useful workaround for the wrong diagnosis
Haiku notices that collecting a harvest reverted. It changes the operation and successfully stops the harvest instead. Later stack analysis traced collect failures to the tool’s gas ceiling.
The sequence · editorial summary
-
Session 47
Tool responseCollection fails without an explanation
Haiku tries to collect a harvest. The transaction fails on-chain and spends gas, but the tool gives no useful reason. Later analysis traced the failure to the tool’s gas ceiling.
Agent commentaryTries stopping the harvest instead
The agent explicitly connects the failed collection to a different plan: stop the harvest and collect that way. It changes the operation within the same session, without identifying the underlying tool defect.
Tool responseThe alternative works
The stop transaction succeeds, giving the agent a working alternative to the broken collect action. This resolves the immediate problem; it does not show that the agent understood why collection failed.
Session activity: no persistent-memory write or read is shown in these excerpts.
What the sequence shows. The agent responds to the failure and finds a working alternative. This is within-session adaptation, not proof that it understood the defect or permanently stopped retrying the broken tool.
Read the 3 source excerpts · verbatim transcripts & annotations
-
In-session observation · not a saved note ·
harvest_collectThe failed operation is visible
"status": "reverted", "block": 31176070, "gas_used": 1999501,
The old tool response reports a revert and gas use but gives no usable explanation of the cause.
Original transcript · line 12, session 47 (Hugging Face, opens in a new tab) ↗ -
In-session text · not a saved note
Choose another operation
The harvest collection reverted. Let me try to stop the harvest and collect instead:
Haiku explicitly connects the failed collection to trying harvest_stop.
Original transcript · line 13, session 47 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
harvest_stopThe alternative succeeds
"status": "success", "block": 31176074, "gas_used": 2332041,
The stop operation succeeds. Run 5 later verifies the repaired collection tool in agents’ hands.
Original transcript · line 14, session 47 (Hugging Face, opens in a new tab) ↗
Swipe to explore · Arrow keys also work when the examples are focused
The agent caught in the memory trap could see its balance but not the quest's progress since acceptance. Its saved explanation was wrong, and rereading it supplied no new evidence. We exposed the progress counter and tested the change in another run.
REGISTERED By run 005, the exit test found no remaining stack defect affecting what agents could see or do. The remaining failures were in their choices.
Access to knowledge is only a beginning
The agents already had the documentation. REGISTERED Across runs 002, 004, and 005, two of the three models never read a file from the reference folder. Leveling and skill tools accounted for just four of 15,815 tool calls. Would putting useful knowledge directly in the agent's workflow change its behavior?
EXPLORATORY Run 006 tested Sonnet 5 and gpt-5.2, each with a control agent and an agent given extra guidance. Both could read the documentation. The guided agents also received an orientation, keyword search, facts in tool results, and mechanics notes when calls failed. The environment tool schemas were identical within the experiment; both models and stack differed from the earlier runs.
EXPLORATORY Both guided agents completed more quests than their controls, but neither leveled up a creature. The Sonnet control leveled up eight times; the gpt-5.2 control never did. Extra guidance did not meet the experiment's success criterion. Yet the individual stories show where knowledge helped—and where it went unused.
The chart calls the guided condition “pushed knowledge.” Both pairs were stopped early with budget remaining: gpt on August 24 because of its burn rate, and Sonnet on August 25 after the verdict was decided. Each line ends at its operator stop.
From the agents’ own records
The same knowledge, different reasons to use it
Read the short sequence first, then open the source excerpts. Quoted notes are verbatim; the summaries are ours. Every HF link opens a public transcript at a pinned revision.
A question turns a search into an operating rule
A quest required time spent harvesting. The agent searched the documentation to learn when the game actually recorded that time.
The sequence · editorial summary
-
Session 57
Saved to persistent memoryTurns a search result into a quest procedure
A quest requires time spent harvesting, but waiting alone does not update its counter. After searching the documentation and contract source, the agent saves the missing step: stop the harvest to record the elapsed time.
Verbatim note ·
progress.mdis only incremented by **HarvestStopSystem**
-
Next session · 58
Retrieved from persistent memoryRetrieves the procedure before continuing
The next session reads the saved instructions: harvest for the required duration, feed or collect as needed, then stop. The note explains both how to keep the creature harvesting and how to make that time count toward the quest.
Verbatim note ·
progress.mdPRACTICAL UPSHOT: to complete a HARVEST_TIME quest
Memory evidence: a saved note and a later read are both shown.
What the sequence shows. The search produced a rule the agent could use: elapsed time alone was insufficient; stopping the harvest updated the counter. The lab traced this discovery to progress along the main quest chain. Knowledge delivery helped with a question the agent was trying to answer.
Read the 3 source excerpts · verbatim transcripts & annotations
-
File write · survives the session ·
progress.mdRecorded what the source said
The HARVEST_TIME data counter (what the quest's INC/snapshot objective reads) is only incremented by **HarvestStopSystem** ("Log harvest time" step), NOT by HarvestCollectSystem, and NOT continuously by block time.
Saved in notes.md after searching the documentation and contract source.
Original transcript · line 134, session 57 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
progress.mdTurned the mechanism into a procedure
PRACTICAL UPSHOT: to complete a HARVEST_TIME quest, just start harvesting at the target node, wait (real wall-clock) at least the required duration (43200s = 12h for the "big" ones), feed/collect freely as needed for kami health/MUSU in the meantime, then call harvest_stop on that kami.
The agent turns the rule into a procedure in notes.md.
Original transcript · line 134, session 57 (Hugging Face, opens in a new tab) ↗ -
File read · brings a saved note into this session ·
progress.mdRetrieved the rule next session
PRACTICAL UPSHOT: to complete a HARVEST_TIME quest, just start harvesting at the target node, wait (real wall-clock) at least the required duration (43200s = 12h for the "big" ones), feed/collect freely as needed for kami health/MUSU in the meantime, then call harvest_stop on that kami.
The next session reads the saved procedure before continuing the quest work.
Original transcript · line 7, session 58 (Hugging Face, opens in a new tab) ↗
A quest becomes a habit
The control arm could read the documentation folder. While exploring side quests, it encountered an explicit instruction to level a creature.
The sequence · editorial summary
-
Session 60
Tool responseFinds a quest that asks for a level-up
While exploring side quests, the Sonnet control agent receives a concrete objective: level up a Kami, one of its creatures. The instruction gives leveling an immediate purpose in the agent’s quest work.
Agent commentaryRecognizes that the objective is met
In the same session, the agent reports that leveling succeeded and satisfied the quest objective. It then continues to the related quest and skill mechanic. The lab separately verified this first level-up.
-
Later session · 70
Agent commentaryReturns to leveling without another quest prompt
Ten sessions later, the agent reports reaching level 3 and chooses to keep upgrading for more health. The lab verified six level-ups in 37 seconds in this session; the repetition breaker then ended the burst.
Session activity: no persistent-memory write or read is shown in these excerpts.
What the sequence shows. The lab verified one level-up in session 60, six in 37 seconds in session 70, and one in session 74. The later burst needed no quest prompt. The repetition breaker ended the burst after six successes, exposing another scaffold limitation.
Read the 3 source excerpts · verbatim transcripts & annotations
-
In-session observation · not a saved note ·
get_expected_objectiveFound an explicit objective
"description": "Level up a Kami"
A field returned by get_expected_objective, not text supplied by the researchers.
Original transcript · line 65, session 60 (Hugging Face, opens in a new tab) ↗ -
In-session text · not a saved note
Recognized the successful action
Level up succeeded — quest 3003 objective met. Let's complete it and check quest 3004 (Skill Issue, likely follows).
The agent completed the quest and explored the related skill mechanic. The run analysis traces the mechanic into its persistent notes.
Original transcript · line 81, session 60 (Hugging Face, opens in a new tab) ↗ -
In-session text · not a saved note
Used the mechanic again later
Level 3 now, gained a skill point. Let's try leveling further and allocate skill points into Grit (skill 112) for more HP.
After the first success in this session, the agent chose to continue leveling. Five more successes followed.
Original transcript · line 31, session 70 (Hugging Face, opens in a new tab) ↗
The note survives. The question disappears.
The pushed arm had leveling explained in its standing instructions. Its notes claimed it could check experience in a tool that did not return experience.
The sequence · editorial summary
-
Session 43
Saved to persistent memoryPostpones checking whether it can level up
The guided Sonnet agent has leveling explained in its instructions, but saves a note saying it is not urgent. It suggests checking experience points with a tool that does not actually return them.
Verbatim note ·
progress.mdCheck XP via lens_kami if curious; not urgent for quest progress.
-
Later session · 58
Saved to persistent memoryCopies the untested assumption forward
Fifteen sessions later, the notes still say both creatures are level 1 and leveling is not a priority. They repeat the suggestion to inspect an experience-points field that the tool does not provide.
Verbatim note ·
progress.mdNot prioritized
-
Later session · 61
Saved to persistent memoryDrops the check without resolving the question
A later note keeps the low priority but removes the proposed experience-points check. The assumption was never tested or corrected, and the agent finishes the run without leveling up a creature.
Verbatim note ·
progress.mdLow priority; revisit once MIN/MSQ chain grind slows down
Memory evidence: writes are shown. A later read is not shown in these excerpts.
What the sequence shows. The claim was never tested. Later notes dropped the proposed check but retained the low priority. The arm ended with no level-ups. Availability of information did not create a reason to resolve the question.
Read the 3 source excerpts · verbatim transcripts & annotations
-
File write · survives the session ·
progress.mdDeferred the question
Check XP via lens_kami if curious; not urgent for quest progress.
A speculative way to inspect experience becomes advice to a future session.
Original transcript · line 62, session 43 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
progress.mdCarried the assumption forward
Both kamis level 1 still - never leveled up. Not prioritized (XP banked from harvesting is going somewhere - check lens_kami xp field if curious, or just level_to once a MSQ chain slows down).
The false assumption about the tool persists in a later notes.md write.
Original transcript · line 30, session 58 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
progress.mdDropped the check, kept the priority
Both kamis still level 1 - never leveled up. Low priority; revisit once MIN/MSQ chain grind slows down
The instruction to check experience disappears without being corrected.
Original transcript · line 177, session 61 (Hugging Face, opens in a new tab) ↗
A catalog search becomes a completed task
GPT-5.2 searches the manual for its current location. A result exposes a side quest. The agent accepts the quest, checks whether it can finish, and completes it in the same session.
The sequence · editorial summary
-
Session 49
Tool responseFinds a local quest through search
GPT-5.2 searches the manual for its current location. A result identifies a side quest available there, giving the agent a specific task to pursue rather than just background information about the room.
Tool responseChecks the quest after accepting it
The agent accepts the quest found in the search result and asks whether its requirements are met. The tool returns true, confirming that the quest is ready to complete.
Tool responseCompletes the quest in the same session
The agent calls the completion tool for that quest and receives a successful transaction result. The sequence connects a documentation search to a discovered task, a readiness check, and a completed action.
Session activity: no persistent-memory write or read is shown in these excerpts.
What the sequence shows. This is a positive example of reference use producing action. It supports a specific useful role for search, while the overall knowledge-delivery rung still fails the registered joint rule.
Read the 3 source excerpts · verbatim transcripts & annotations
-
In-session observation · not a saved note ·
search_referenceFind a relevant task in the manual
Rob's trading chain (Giver: ROB): (In Room: Restricted Area) --- SQ028 The More the Merrier
This is the text of the first search hit, decoded from the JSON tool response. It is game documentation returned to the agent, not a summary written for this gallery.
Original transcript · line 32, session 49 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
check_quest_completableCheck that the accepted task is ready
{ "quest_index": 3028, "completable": true }
The agent has accepted quest 3028. check_quest_completable now returns true.
Original transcript · line 52, session 49 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
complete_questComplete the task
"status": "success", "block": 32341395, "gas_used": 901047,
The preceding call is complete_quest(3028). Its result reports a successful transaction.
Original transcript · line 56, session 49 (Hugging Face, opens in a new tab) ↗
Swipe to explore · Arrow keys also work when the examples are focused
Search helped when an agent had a question to answer: when does the game count harvesting time? The answer gave it a rule it could act on. The Sonnet control encountered an explicit quest objective to level a creature, then later leveled up repeatedly. The guided Sonnet agent kept postponing leveling despite having it explained.
EXPLORATORY Our reading is that a clear reason to act mattered more here than another explanation of how. These individual trajectories do not establish a general result. There was also a visibility gap: the tools did not show experience points, so agents could not inspect the surplus they were leaving unused.
Make efficiency matter
One agent already noticed a cost in how it gathered information. EXPLORATORY Sonnet saved a warning that a broad quest query wasted context, along with smaller alternatives. The next session read the note and used targeted checks. The example covers only that next wake, so we do not know whether the improvement lasted.
The next sustainability family makes costs part of survival. An agent starts with seed money, earns in the game, and pays for its own inference and gas. It lives as long as it can pay. An external meter supplies a financial statement showing its earnings, costs, and running balance.
Will that pressure encourage better use of memory, more selective reading, and cheaper decisions? That is what the next experiment will test.