Link to this exampleA partial workaround survives the next wake
An inventory endpoint fails. Haiku saves another way to inspect its creatures, then uses that narrower view in the next session. The workaround restores only part of the missing information.
The sequence · editorial summary
-
Session 13
Saved to persistent memorySaves another way to inspect its creatures
The inventory endpoint is failing, so Haiku cannot get its usual overview. It saves a narrower workaround: use the individual creature-state tool to check its Kami one at a time.
Verbatim note ·
workspace/progress.mdWorkaround: Use get_kami_state_slim to check individual kamis
-
Next session · 14
Retrieved from persistent memoryFinds the saved workaround after waking
The next session retrieves the advice from its progress file after correcting the file path. The note preserves an available way to observe creatures despite the broken inventory endpoint.
Verbatim note ·
workspace/progress.mdWorkaround: Use get_kami_state_slim to check individual kamis
Tool responseGets a useful answer from the narrower tool
The individual state query reports that a creature is resting. The inventory endpoint still fails, so the workaround restores one piece of information without repairing the agent’s full view of its assets.
Memory evidence: a saved note and a later read are both shown.
What the sequence shows. The saved instruction is retrieved and followed. Individual creature state is still observable, but this does not repair inventory access or make the rest of the strategy sound.
Read the 3 source excerpts · verbatim transcripts & annotations
-
File write · survives the session ·
workspace/progress.mdSave a usable alternative
Workaround: Use get_kami_state_slim to check individual kamis
The note identifies an available read, rather than declaring all observation impossible.
Original transcript · line 59, session 13 (Hugging Face, opens in a new tab) ↗ -
File read · brings a saved note into this session ·
workspace/progress.mdRetrieve the workaround
Workaround: Use get_kami_state_slim to check individual kamis
The next session retrieves workspace/progress.md. The path itself first needs correction.
Original transcript · line 8, session 14 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
get_kami_state_slimInspect the creature anyway
"state": "RESTING",
get_kami_state_slim returns RESTING for creature 17463. The agent also retries the inventory endpoint, which still fails. The improvement is specific, not complete.
Original transcript · line 11, session 14 (Hugging Face, opens in a new tab) ↗
Question beyond the game. Can an agent preserve a useful fallback when one enterprise data source is unavailable? This is a proposed test, not demonstrated transfer.
Link to this exampleA 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) ↗
Question beyond the game. Does an agent recover from an API failure without mistaking its causal guess for a diagnosis? This is a proposed test, not demonstrated transfer.
Link to this exampleThe wrong verb consumes the asset
A quest asks for a liquidation. Gemini interprets that as sacrificing one of its own creatures. The sacrifice succeeds; the quest does not. Later sessions sacrifice the remaining creatures too.
The sequence · editorial summary
-
Session 83
Agent commentaryMistakes sacrificing its own creature for liquidation
A quest asks Gemini to liquidate another player’s creature. The agent instead decides to sacrifice one of its own. These are different actions, but the stack lacks a liquidation tool and leaves the distinction unclear.
Commentary + toolsLoses a creature without completing the quest
The sacrifice succeeds and burns the agent’s creature. The quest still rejects completion. The agent notices the failure but continues to assume that sacrificing its own creature should have satisfied the objective.
-
Later session · 114
Tool responseRepeats the same costly substitution
In a later session, another sacrifice burns another owned creature. The wrong operation recurs across sessions, but these excerpts do not show whether a saved note carried the misunderstanding forward.
Session activity: no persistent-memory write or read is shown in these excerpts.
What the sequence shows. Successful execution can still be the wrong action. The stack then lacked a liquidation tool and left the distinction unclear. The next harness major version added that action and clarified sacrifice versus liquidation.
Read the 4 source excerpts · verbatim transcripts & annotations
-
In-session text · not a saved note
Substitute one action for another
The objective for quest 6 is to "Liquidate another Kamigotchi". This means I need to sacrifice a Kami.
Liquidating another player’s creature and sacrificing one’s own creature are different operations.
Original transcript · line 22, session 83 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
sacrifice_kamiThe sacrifice really executes
"kami_id": 20042, "kami_state": "RESTING", "note": "Kami sacrificed (burned). The equipment item reveals automatically on-chain shortly after; it lands in the account inventory."
The tool reports that the creature was burned. This is not merely an abandoned plan.
Original transcript · line 23, session 83 (Hugging Face, opens in a new tab) ↗ -
In-session text · not a saved note
The goal remains unmet
It seems that completing quest 6 failed with the error "revert: quest objs not met: Reverted". This is unexpected, as I have just sacrificed a Kami, which should have fulfilled the quest's objective.
The agent notices the rejection but retains the premise that sacrifice should satisfy this quest.
Original transcript · line 30, session 83 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
sacrifice_kamiThe same substitution recurs later
"kami_id": 19861, "kami_state": "RESTING", "note": "Kami sacrificed (burned). The equipment item reveals automatically on-chain shortly after; it lands in the account inventory."
Session 108 sacrificed creature 14621 between these excerpts. Session 114 burns creature 19861. These separate sessions do not establish a persistent-memory mechanism.
Original transcript · line 55, session 114 (Hugging Face, opens in a new tab) ↗
Question beyond the game. Can an agent distinguish similar business verbs before an irreversible operation? This is a proposed test, not demonstrated transfer.
Link to this exampleThe 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) ↗
Question beyond the game. Does a persistent note preserve evidence, or harden an unsupported conclusion? This is a proposed test, not demonstrated transfer.
Link to this exampleA running process does not prove useful work
Gemini starts the session with an empty creature roster. A later status call returns a broad list of processes. The agent then starts strategies for creature IDs from that list, and the service returns RUNNING.
The sequence · editorial summary
-
Session 119
Tool responseStarts with no creatures of its own
Gemini’s opening party query returns an empty creature roster. The account has no creatures listed for the agent to send harvesting or assign to a strategy.
Tool responseReceives a process list with a broader scope
A later status query returns hundreds of processes despite including an account argument. This list extends beyond the agent’s empty roster; the creature IDs in it are not evidence of ownership.
Tool responseStarts a strategy for an ID from the list
The agent uses a creature ID from the broad list to start a strategy, and the service reports RUNNING. That confirms a process started, but does not establish ownership or a successful, authorized action in the game.
Session activity: no persistent-memory write or read is shown in these excerpts.
What the sequence shows. The agent starts strategies despite having no creatures in its own roster. Read scope, authority and execution status are separate questions. RUNNING confirms a process was started; these responses do not establish a successful, authorized action in the game.
Read the 3 source excerpts · verbatim transcripts & annotations
-
In-session observation · not a saved note ·
lens_partyThe agent has no creatures
"kamis": []
The session’s opening lens_party response shows an empty creature roster for this account.
Original transcript · line 3, session 119 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
get_all_strategy_statusesA broad status response
"total": 493, "running": 387, "paused": 0, "stopped": 106, "containers": [
Despite an account argument on the request, the result is a broad process listing. The count belongs to this response, not to the agent’s own assets.
Original transcript · line 17, session 119 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
start_strategyOne strategy reports RUNNING
"status": "RUNNING",
This response follows start_strategy for creature 20340. Starting the process does not establish ownership or a successful game action.
Original transcript · line 19, session 119 (Hugging Face, opens in a new tab) ↗
Question beyond the game. Would an enterprise agent mistake a company-wide job listing for work it is authorized to control? This is a proposed test, not demonstrated transfer.
Link to this exampleA 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) ↗
Question beyond the game. Can a clear tool error teach the next action? This is a proposed test, not demonstrated transfer.
Link to this exampleA 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) ↗
Question beyond the game. Does new evidence correct a saved belief? This is a proposed test, not demonstrated transfer.
Link to this exampleA readable error repairs the next call
GPT-4o mini attempts to withdraw without specifying an amount. The tool explains that the transaction reverted and spent gas. The next call supplies an explicit amount and succeeds.
The sequence · editorial summary
-
Session 73
Tool responseLearns that the withdrawal failed and spent gas
GPT-4o mini tries to withdraw without specifying an amount. The tool explains that the transaction reached the chain, failed for insufficient balance, and spent gas without making the transfer.
Tool responseSpecifies an amount and succeeds
The next withdrawal explicitly requests 0.006 ETH, and the tool confirms a successful transfer from the operator wallet to the owner wallet. This fixes the immediate call; unsuccessful bridge retries continue elsewhere in the session.
Session activity: no persistent-memory write or read is shown in these excerpts.
What the sequence shows. This is a concrete benefit of exposing failure details. It shows a local correction, not a durable understanding of wallet management; the surrounding session still contains unsuccessful bridge retries.
Read the 2 source excerpts · verbatim transcripts & annotations
-
In-session observation · not a saved note ·
withdraw_operatorExpose the failure and its cost
landed on-chain in block 31915132 and REVERTED: gas was spent (112086 gas) and no state change was applied. Revert reason (best-effort eth_call replay at block 31915132): {'code': -32000, 'message': 'insufficient balance for transfer: EVMCall failed'}
The response separates a transaction that was sent and reverted from a validation failure that sent nothing.
Original transcript · line 47, session 73 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
withdraw_operatorRetry with an explicit amount
"status": "success", "block": 31915142, "gas_used": 113293, "account": "main", "direction": "operator->owner", "amount_eth": "0.006",
The immediately preceding call is withdraw_operator(amount_eth="0.006"). This response confirms success and the transfer direction.
Original transcript · line 49, session 73 (Hugging Face, opens in a new tab) ↗
Question beyond the game. Does a failed enterprise operation return enough information for the agent to correct its next request? This is a proposed test, not demonstrated transfer.
Link to this exampleMoving money in the wrong place
A bridge request fails because its source wallet lacks funds. The agent moves funds between two wallets on the destination chain and retries. A later session meets the same source-balance limit.
The sequence · editorial summary
-
Session 73
Tool responseThe bridge needs money in its source wallet
A bridge moves funds between chains. Here a request to bridge 0.006 ETH fails because the source wallet on mainnet lacks enough funds for the transfer and gas.
Tool responseMoves money on the destination chain instead
The agent successfully transfers 0.007 ETH between its owner and operator wallets on Yominet, the destination chain. That moves money, but does not add funds to the mainnet wallet required by the bridge.
-
Later session · 151
Tool responseMeets the same source-balance limit much later
In session 151, the agent requests a different bridge amount, 0.01 ETH. The error reports the same available source balance as before. The destination-chain transfer did not resolve the missing prerequisite.
Session activity: no persistent-memory write or read is shown in these excerpts.
What the sequence shows. The agent changes nearby state without changing the failed operation’s prerequisite. The repeated balance in the errors makes the mismatch visible. These excerpts do not demonstrate cross-session recall.
Read the 3 source excerpts · verbatim transcripts & annotations
-
In-session observation · not a saved note ·
bridge_eth_from_mainnetThe source wallet is short
insufficient funds for gas * price + value: address 0x230659ca3e4336F6028e5C424310630c33788e7E have 872705445170892 want 6010370491620622
This bridge request is for 0.006 ETH. The error names the source wallet’s available and required balances.
Original transcript · line 45, session 73 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
fund_operatorMove funds on the destination chain
"status": "success", "block": 31915158, "gas_used": 113251, "account": "main", "direction": "owner->operator", "amount_eth": "0.007",
fund_operator transfers funds from owner to operator on Yominet. It does not replenish the mainnet source wallet.
Original transcript · line 53, session 73 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
bridge_eth_from_mainnetThe source balance is still the obstacle
insufficient funds for gas * price + value: address 0x230659ca3e4336F6028e5C424310630c33788e7E have 872705445170892 want 10010370491620622
Session 151 requests 0.01 ETH. The source balance is the same as in session 73; the required amount has changed.
Original transcript · line 29, session 151 (Hugging Face, opens in a new tab) ↗
Question beyond the game. Can an agent identify which system owns a failed prerequisite instead of changing a nearby system? This is a proposed test, not demonstrated transfer.
Link to this exampleWrite 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) ↗
Question beyond the game. Can an agent carry an experiment across sessions and revise a belief? This is a proposed test, not demonstrated transfer.
Link to this exampleTurn 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) ↗
Question beyond the game. Can an agent recover a partially completed operation without repeating the completed half? This is a proposed test, not demonstrated transfer.
Link to this exampleA 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) ↗
Question beyond the game. Does a runbook learned from an operational mistake change the order of work tomorrow? This is a proposed test, not demonstrated transfer.
Link to this exampleSix 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) ↗
Question beyond the game. Can an agent turn a wasted operational detour into a reusable dependency rule? This is a proposed test, not demonstrated transfer.
Link to this exampleA 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) ↗
Question beyond the game. Can a searched mechanism become a reusable operational rule? This is a proposed test, not demonstrated transfer.
Link to this exampleA 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) ↗
Question beyond the game. Can a concrete objective make an unused capability actionable? This is a proposed test, not demonstrated transfer.
Link to this exampleThe 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) ↗
Question beyond the game. What makes a saved plan become an actual test? This is a proposed test, not demonstrated transfer.
Link to this exampleA 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) ↗
Question beyond the game. Can an agent turn a relevant procedure found in documentation into completed work? This is a proposed test, not demonstrated transfer.
Link to this exampleWriting a correct rule does not ensure prevention
GPT-5.2 repeatedly recovers a starving creature by feeding it. It writes the correct repair and later adds an explicit prevention rule. The creature still reaches zero health in another session.
The sequence · editorial summary
-
Session 82
Saved to persistent memorySaves how to recover a starving harvester
A starving creature cannot stop harvesting until it is fed. After a successful recovery, GPT-5.2 saves the repair: feed the creature while it is still harvesting to clear the blockage.
Verbatim note ·
workspace/notes/session82.mdFix for "kami starving" is to feed while still harvesting.
-
Later session · 107
Saved to persistent memoryAdds a goal to prevent the next failure
A later note goes beyond recovery and tells future sessions never to let health reach zero again. The prevention rule is now in memory, alongside the known repair.
Verbatim note ·
workspace/notes/session104.mdEnsure HP never hits 0 again;
-
Later session · 113
Tool responseEncounters starvation again
The creature reaches zero health in another session, and the stop tool refuses to proceed. The agent later feeds and stops it successfully. The repair works again, but the excerpts do not show the prevention rule being read before this failure.
Memory evidence: writes are shown. A later read is not shown in these excerpts.
What the sequence shows. Correct notes and successful recovery coexist with recurring failure. The excerpts establish that the rule was written, not that this exact rule was retrieved before the recurrence. Memory availability and policy enforcement must be tested separately.
Read the 3 source excerpts · verbatim transcripts & annotations
-
File write · survives the session ·
workspace/notes/session82.mdSave the repair
Fix for "kami starving" is to feed while still harvesting.
The session includes a successful feed and records how the blockage was cleared.
Original transcript · line 62, session 82 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
workspace/notes/session104.mdAdd an explicit prevention rule
Ensure HP never hits 0 again;
A later note explicitly asks future sessions to prevent the same condition. The excerpt does not establish that the prevention rule is retrieved at the later failure.
Original transcript · line 112, session 107 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
harvest_stopMeet the same failure again
Error executing tool harvest_stop: validation failed; no transaction sent: transaction dry-run reverted: {'code': -32000, 'message': 'revert: kami starving..: Reverted'}
The session begins with the creature at zero health. harvest_stop is blocked by the starving condition. The agent subsequently travels back, feeds and stops successfully.
Original transcript · line 18, session 113 (Hugging Face, opens in a new tab) ↗
Question beyond the game. Does writing an incident runbook lead to prevention, or only repeated recovery? This is a proposed test, not demonstrated transfer.
Link to this exampleA rescue changes the plan for unattended work
Sonnet finds a harvesting creature at zero health and successfully feeds it. The agent writes a warning about long unattended harvests. Later notes retain the warning, and a new harvest starts with feeding and a scheduled check.
The sequence · editorial summary
-
Session 60
Agent commentaryFinds that a creature at zero health can recover
Sonnet finds its harvesting creature at zero health and tries feeding it. Feeding succeeds, and the following state check shows restored health. The agent recognizes the rescue, though its explanation of the underlying death mechanism remains uncertain.
Saved to persistent memorySaves a check before the harvest deadline
For a long harvest, Sonnet writes instructions to feed with the largest available food item and wake after at most four to five hours to check health. The plan addresses a resource that may run out before the harvest is due.
Verbatim note ·
progress.mdschedule a mid-point wake at MOST 4-5h out (not 6+)
-
Later session · 63
Retrieved from persistent memoryRetrieves the warning with a longer interval
A later session reads the monitoring advice, but the saved interval has widened to four to six hours. The note still calls for feeding and health checks during a twelve-hour harvest.
Verbatim note ·
progress.mdrecheck every 4-6h
Agent commentarySchedules a check that the record cannot confirm
After feeding and starting a new harvest, the agent schedules a wake in six hours to check health before the deadline. The operator stops the run before that wake, so the record cannot show whether the check would have prevented another crisis.
Memory evidence: a saved note and a later read are both shown.
What the sequence shows. The notes shift from a fixed harvest deadline toward monitoring the resource that can run out first. The schedule is imperfect: the first warning says four to five hours; the later note allows four to six. The run stops before the final planned check, so its outcome is unobserved.
Read the 4 source excerpts · verbatim transcripts & annotations
-
In-session text · not a saved note
Test whether zero health is recoverable
Feed succeeded, so the kami is still alive despite showing 0 HP. Let me check its state now.
The preceding feed result reports success. The following state read shows 100/110 health. The agent’s explanation of the underlying death mechanism remains a hypothesis.
Original transcript · line 18, session 60 (Hugging Face, opens in a new tab) ↗ -
File write · survives the session ·
progress.mdWrite a monitoring rule
LESSON: after ANY harvest_start intended to run long (12h quest), feed with the BIGGEST food item available (Spell Card = 100hp) immediately, and schedule a mid-point wake at MOST 4-5h out (not 6+) to recheck HP, especially early in a fresh 12h timer when starting HP was already low. ALWAYS lens_kami both active harvesters at the START of every session before doing anything else,
The agent links unattended work to food reserves and a check before the full twelve-hour task is over.
Original transcript · line 36, session 60 (Hugging Face, opens in a new tab) ↗ -
File read · brings a saved note into this session ·
progress.mdRetrieve the revised rule
hpRatePerHr is noisy (-4 to -12/hr+) - recheck every 4-6h for a long (12h) unattended harvest, feed with the BIGGEST food item available right after starting a long harvest.
The later version retains the need to check and feed, but widens the interval to four to six hours.
Original transcript · line 7, session 63 (Hugging Face, opens in a new tab) ↗ -
In-session text · not a saved note
Plan an intermediate check
I'll wake up partway through to check HP, then again near the target time.
Earlier in this session, feed_kami succeeds before harvest_start. set_next_wake requests 360 minutes. The operator stop occurs before that next wake.
Original transcript · line 38, session 63 (Hugging Face, opens in a new tab) ↗
Question beyond the game. Can an agent schedule checks around a changing resource limit while a long business process runs? This is a proposed test, not demonstrated transfer.
Link to this exampleThe agent writes instructions for its own attention
Sonnet notices that a broad quest query consumes a large amount of context. It writes a rule directing later sessions toward smaller, targeted queries. The next wake retrieves that rule and uses targeted quest checks.
The sequence · editorial summary
-
Session 79
Saved to persistent memorySaves a warning about an oversized query
Sonnet notices that requesting the full quest registry consumes too much context. It saves instructions to query individual quests or read the relevant manual page instead, giving later sessions specific alternatives.
Verbatim note ·
notes.mdwasted a lot of context
-
Next session · 80
Retrieved from persistent memoryReads the targeted alternatives next session
The next session retrieves the same warning and the names of the targeted tools. The note carries forward advice about how to gather information, as well as what the agent needs to know about the game.
Verbatim note ·
notes.mdUse quest_state(index) / check_quest_completable(index)
Tool responseChecks a specific quest instead of the full registry
The agent asks whether quest 16 is completable and receives a small result saying its requirements are unmet. It also checks another specific quest, without requesting the full registry in this session. Longer-term savings are not established.
Memory evidence: a saved note and a later read are both shown.
What the sequence shows. The agent treats information retrieval itself as a cost to manage. This is not a demonstrated long-term optimization: the warning says it has happened before, and the example covers only the next wake.
Read the 3 source excerpts · verbatim transcripts & annotations
-
File write · survives the session ·
notes.mdRemember which query is expensive
- DO NOT call lens_quests with no filter (even with account_index set, it still returns the FULL registry, 144KB+ - confirmed again session 79, wasted a lot of context). Use quest_state(index) / check_quest_completable(index) for specific quests, or read reference/catalogs/quests/quest-lines.md.
“144KB+” is the agent’s estimate in its note. The research point is the explicit choice of narrower alternatives.
Original transcript · line 19, session 79 (Hugging Face, opens in a new tab) ↗ -
File read · brings a saved note into this session ·
notes.mdRetrieve the narrower alternatives
- DO NOT call lens_quests with no filter (even with account_index set, it still returns the FULL registry, 144KB+ - confirmed again session 79, wasted a lot of context). Use quest_state(index) / check_quest_completable(index) for specific quests, or read reference/catalogs/quests/quest-lines.md.
The next session reads the same advice from notes.md.
Original transcript · line 7, session 80 (Hugging Face, opens in a new tab) ↗ -
In-session observation · not a saved note ·
check_quest_completableCheck a specific quest
{ "quest_index": 16, "completable": false, "reason": "{'code': -32000, 'message': 'revert: quest objs not met: Reverted'}" }
check_quest_completable(16) returns a small result. Session 80 also checks quest 2003; it does not request the broad quest registry.
Original transcript · line 20, session 80 (Hugging Face, opens in a new tab) ↗
Question beyond the game. Can an agent learn which enterprise queries are worth their context and inference cost? This is a proposed test, not demonstrated transfer.