Observation 1: it never equips anything

The bot fights goblins bare-handed with a bronze sword in its inventory. Across twenty-plus runs it essentially never called equipItem(). The cause was sensory: nothing in the world digest reported equipment state, so no prompt ever said "you are holding nothing." An API the model has never used and never sees evidence about effectively does not exist.

This motivated a three-way experiment to locate where the intervention belongs:

• Unused-API nudge (U): each turn, show one randomly chosen never-used API with a hint ("you have never used bot.equipItem()..."). Prompt-level.
• Equipment visibility (Z): add a "## Equipment worn: NOTHING - equippable items sitting unused in inventory: bronze sword" line to the digest. Sense-level.
• Auto-equip (P): a wrapper that silently equips the best weapon before any attack. Actuator-level.

Given the ledger (sensed truth wins, prompt directives lose), my registered prediction was P > Z > U. The result did not follow the prediction:

The original Z run was not a clean read on equipment semantics. Partway through, the model collapsed into writing Python instead of TypeScript ("print is not defined", if rat: syntax), and the history window sustained the derailment for the rest of the episode. The rerun was clean and produced the most informative null result of the round. The bot called equipItem() eight times (bronze axe, bronze dagger), the first equips observed anywhere in the project, and the score still did not separate from baseline. That splits the hypothesis in two: visibility was the missing ingredient for the behavior, and the behavior was not a missing ingredient for the score. The most likely explanation is that equipment was never the binding constraint. At rat-and-goblin tier, bare-handed combat trains the same skills only slightly slower, so a perfect equip policy has little XP to add. Prompt-level nudges are now 0-for-4 across rounds, which keeps the sense/actuator hierarchy intact even in a null round. If exploration is worth forcing, the next design is epsilon-greedy at the actuator level: occasionally execute an unexplored action rather than suggesting it.

Observation 2: the 3D-to-1D bottleneck

A language model has no visual capacity. The whole game world reaches it as text, and my translation was lossier than I realized. Before this round, the digest gave NPCs no coordinates at all, just names and distances. A report like "Goblin, 7 tiles" carries no direction. The model's most common visible failure was walking into fences.

Three flags targeted this:

• Compass bearings (J): annotate every entity with egocentric bearings: "Shop keeper 12t N (3208,3248)". Cheap, purely sensory.
• ASCII minimap (V): an 11x11 character grid centered on the player: trees as T, NPCs as N, ground items as $. The legend carries a caveat: walls and water are NOT shown, because the SDK exposes no collision data.
• Learned obstacle map (I): since the SDK can't sense walls, learn them. A wrapper watches every walkTo: if the bot stops more than a tile short of its destination, that spot is recorded and future prompts list nearby known blockages. The map starts empty and fills in from experience. By the ledger's logic, memory earned from the world should work where seeded memory failed.

Results, accumulated across several rounds:

Two results did not fit the existing pattern.

First, J and V were individually tolerable but jointly catastrophic in round one (+100). This was the second observed instance of observation features interfering (world-state deltas + memory blackboard was the first), and I concluded that prompt real estate is a budget. The next round, the same J+V pair inside IJV posted +2515, at the time the highest 20-turn episode recorded. One of those two episodes had to be misleading. With n=1 per cell there was no way to know which, so a replicate ran under the exact original protocol: JV scored +0 with 13 error turns and zero skills trained. A later round added a third JV episode and replicated both single flags. JV proper is now three-for-three collapses (+100, +0, +465). J alone replicated at +1488 and V alone at +1860; each flag individually lands in the normal band across two episodes. "Jointly toxic" therefore stands for the bare pair, on the strongest evidence of any negative result in the ledger.

IJV remains unexplained. Its two episodes (+2515 and +1475) show no collapse, even though the obstacle-map flag never fired in either (below). Nominally they are JV episodes plus an inert flag. Whatever the I flag changes in the prompt or the minimap rendering when its map is empty apparently neutralizes the interference. I do not have a mechanism for this. Five episodes with no range overlap (JV tops out at +465, IJV bottoms out at +1475) make it the most reproducible anomaly in the project. The obvious next experiment is a diff of the two conditions' actual prompts.

Second, the obstacle-map flag never actually engaged: zero stalls were recorded in any of its three episodes. The mechanism only matters when the bot walks into blocked paths, and these episodes happened to settle into open-ground woodcutting loops. So the I rows above carry no obstacle-map signal, and the earned-memory hypothesis remains untested rather than supported or refuted. (Its interrupt variant, which aborts the turn on a stall instead of annotating it, was tested and hurt; that result is in the previous post.)

The pattern, revised

The original framing of this post's observations was: every problem here is an embodiment problem, not an intelligence problem. The model isn't failing to reason about equipment or walls; it has never been told they exist. That framing survives, but the results qualify it. The early sensing and actuator flags (world-state deltas, combat kill-wait, ground-item visibility, the precondition guard) produced large, repeatable wins because they fixed constraints that were actually binding. The round-13-15 additions mostly did not separate from baseline, because the constraints they fixed - equipment, bearings - turned out not to be what was limiting XP at this stage of the game. Building the sensory layer is still the job; knowing which sense is the bottleneck is the part I underestimated.

Open problems: the money half of the standing goal is untouched (coins are zero in nearly every episode recorded); episode variance still swallows single-run conclusions, and the replicate queue keeps growing; and the strongest configuration in the project is a fast, shallow coder model that was nearly dismissed early on. Five episodes in, its mean sits around +3420, and its worst run (a mid-episode death) still roughly matched the best qwen3.5:4b episode (details in the previous post).

Freezing the world during inference

The first post introduced the mechanism: a tick-control endpoint (/api/tick-control?action=pause|resume|rate|status) pauses the engine while the model thinks and resumes it while the generated code executes, so the agent plays in strict lockstep. What that post skipped is the methodological payoff. Pausing separates two questions that are usually conflated:

• 1. Can the model make good decisions given accurate state?
• 2. Can it keep up with a real-time environment?

Freezing the world isolates question 1. Every experiment in this series answers that question, not question 2. Latency stops being a confound and becomes a separately measurable quantity (wall minutes per episode).

Tick rate as an experimental knob

The engine's tick rate (default 600ms per game tick) controls how fast the world runs during the execution phase. The run protocol takes a per-condition tickMs argument, so tick rate became just another flag to sweep:

Reading the chart: each dot is one episode's throughput (XP per wall-minute) at that tick rate; the dashed line traces the group means. The shape is the finding: an inverted U where both extremes lose, and the 150-200ms peak delivers roughly two and a half times the throughput of the default 600ms setting.

Measured as throughput, the curve is an inverted U peaking around 150-200ms: roughly 136-139 XP per wall-minute versus 55 at the default 600ms. Interpretation:

• Too slow (600-1200ms): wall time is dominated by watching actions complete. Decision quality is unchanged; throughput suffers.
• Too fast (100ms): actions and their consequences resolve faster than the feedback loop can represent them, and error turns spike.
• 300ms produced the highest run in the sweep (+1902) but failed to replicate (+769 on rerun), a caution about drawing conclusions from single episodes.

I settled on 200ms as the default based on the error profile rather than the raw throughput ranking: 150ms edges it slightly on XP per minute (139 vs 136), but at the cost of ten error turns versus one. A plausible explanation is that 200ms sits at the slow edge of the throughput plateau, where the world still advances quickly but every action's result has fully resolved before the next decision is made. The model then never reasons from a half-finished state.

Do small models need structured tool calls?

The agent's native interface is "write a TypeScript snippet against the bot SDK." The prevailing assumption in agent design is that structured tool calling is the right way to have models act. An A/B test: same base stack, same 20 turns, one condition using the OpenAI-style tools parameter with a fallback parser, one condition just asking for a fenced code block.

qwen2.5-coder:7b with tool calling: +470 XP, 11 error turns. qwen2.5-coder:7b with plain code blocks: +710 XP, 0 error turns.

phi4-mini was more extreme: with tool calling enabled it refused to play at all. With code blocks it scored +585 XP with 1 error turn.

Based on the error-rate collapse (11 to 0 for coder-7b, refusal to near-flawless for phi4-mini), I dropped the tools parameter for the small-model conditions: at this scale, tool-calling APIs behave like a compatibility layer, not a capability. A plausible mechanism is training distribution: these models saw far more code than tool-call JSON. Asking for code matches what they know. The tool-call envelope is a format they have seen far less often, and the mismatch surfaces as wasted turns.

This does not remove the need for validation; it relocates it. The strictness a tool-call schema would have provided moved into the execution environment instead: the precondition guards from the flag-ledger post veto bad actions after parsing, rather than constraining the model's output format before it.

One incident from the same round is worth recording: a synchronous busy-wait in generated code froze the Bun event loop, taking down the websocket and with it the bot's connection. The fix (an execution timeout plus async-only wait helpers) doesn't show in any results table, but it is the difference between a bad turn and a dead agent. Model-written code needs real sandboxing.

Scoring by wall time instead of turns

The tool-call results surfaced a distinction I had not been measuring: per-decision quality vs per-minute throughput. qwen3.5:4b makes the best individual decisions but thinks slowly; the codeblock coder models make shallower decisions much faster. Twenty-turn episodes structurally favor the slow, careful models; the fast models' advantage is capped at exactly 20 decisions.

The fix required no new code. Setting the turn limit above what the wall-clock deadline permits makes the deadline the binding constraint. Every condition then gets exactly 15 wall-minutes, and the metric becomes XP per fixed time. Results, all at 200ms tick with the tuned decoding knobs (maxTokens 1024, temperature 0, history window 6, precondition guard on):

Reading the chart: every bar is one 15-minute episode on the same stack (precondition guard, 200ms ticks, tuned decoding knobs); only the model and prompt format vary. Green bars are qwen2.5-coder:7b with code-block prompting, gray bars everything else. Compare within the greens for coder-7b's own spread, and greens against the first four grays for the model comparison: coder-7b's worst episode (the one where it died mid-run) still roughly matches qwen3.5:4b's best.

Two findings.

First, coder-7b's +5035 is the highest episode score recorded in the project. Across five episodes the configuration's mean is about +3420, roughly 2.9x the tuned qwen3.5:4b configuration's clean-episode mean of about +1200. Given equal time, fast shallow decisions win in this world, where most correct actions are simple. Run 2 scored +1881 and is not a clean read: the bot died mid-episode, lost its axe, and spent much of the remaining time attempting to chop with empty hands (73 consecutive precondition-guard vetoes in the transcript). Even that episode roughly matched the 4b configuration's best run. Runs 3-5 came back clean at +2820, +3680, and +3675. That band puts +5035 at the high end of the distribution and the death at the low end, and it establishes coder-7b with code blocks as the base configuration. (qwen3.5:4b accounting: run 3's +1545 is excluded from the mean because a bot-name collision resumed an old account rather than a fresh one. Its fresh-account replacement, run 4, scored +586. The 4b configuration's own episodes therefore span 586-1903; variance spares no configuration.) The death in run 2 also exposed a gap the 20-turn protocol could not: episodes are now long enough for rare catastrophic events to matter, and the agent has no recovery behavior. The death has not recurred in three later runs, so its base rate appears low but nonzero.

Second, phi4-mini collapsed under the format change: 160 decisions in 15 minutes but only +660 XP. Its earlier throughput number came from a short 20-turn episode. Given more time, it made very fast decisions with almost no productive action per turn. Fixed-wall-time scoring exposed both facts; the 20-turn protocol had hidden them.

Event-triggered thinking: a negative result

The polling loop (think, execute a fixed window, think again) spends inference whether or not anything decision-relevant happened. The alternative is interrupts: wake the model only when an event invalidates its plan. The flag ledger already hinted this could work. Combat kill-wait, one of the strongest flags, is a negative trigger: it suppresses thinking during combat until resolution. That suggests plan-invalidating events are valuable wake conditions and mere activity is not.

I implemented two triggers: a one-shot low-HP crossing (with hysteresis, so it fires once per dip rather than repeatedly; the low-HP safety-warning flag already showed persistent advice backfires) and a walk-stall detector (if the bot stops short of its destination, execution aborts with INTERRUPT: walkTo stopped at (x,z), N tiles short - path may be blocked). The interrupt ends the turn early, keeps the world paused, and hands the model the named reason as ground truth.

Result, against a same-protocol control:

The mechanism worked as designed: interrupts fired correctly and decision density more than doubled. The outcome still got worse. The transcript shows why: after two early walk-stall interrupts, the bot abandoned travel entirely and spent the rest of the episode killing rats next to its starting point. The interrupt message was true, but it functioned like the failed safety-warning flag: accurate information that redirected behavior for the worse. The model treated one blocked path as a reason to stop traveling at all.

My pre-registered prediction (more decision turns at equal or better XP) was half right: decision turns rose, XP fell. If this gets another iteration, the refinements are mechanical: require a repeated stall before interrupting, and phrase the reason as an actionable option ("try openDoor() or route around") rather than a diagnosis. But one episode per condition is thin evidence, and the honest summary is that the interrupt mechanism is validated and the first trigger tuning is not.

Remaining surface

Several temporal parameters remain untested: dynamic tick rate (fast during travel and gathering, slow near combat; the endpoint supports live changes, nothing schedules them yet), variable execution windows per action type, and partial pausing (freezing only the agent's local chunk, which matters if multiple bots ever share the server).

Next post covers the embodiment experiments: equipment, spatial perception, and what a model that cannot see does with a map.

Watching cannot answer that. Episode variance is enormous: the same configuration scored +815, +1730, and +1764 XP across three replicates, and the strongest configuration in the project later spanned +1881 to +5035 across five. A single run that appears to prove a feature works is noise.

Reading the chart: each dot is one complete episode, colored by model. Every group ran on qwen3.5:4b (green) except the rightmost, which ran on qwen2.5-coder:7b (blue). Each gray bar is a group mean. The two panels are different protocols (the left panel ran fixed 20-turn episodes, the right panel fixed 15-minute wall-time episodes), so scores compare within a panel but not across panels. Two takeaways: nearly every group spans a 2x-or-worse band between its best and worst episode, which is why single runs prove nothing; and CEF+JV is the one exception, three episodes all collapsed near zero. When replicates agree that tightly, the effect is real. (The flag letters and the right panel's configurations are covered in this post and the following two.)

The harness

Every feature is a boolean flag in an experiment.json config: blackboard, deltas, killwait, ground, places, and eventually about twenty more. Each flag gates one change to the prompt, the executor, a wrapper around the bot API, or the game engine itself. The run protocol takes a per-condition tick rate, and the world-pause lockstep is part of the harness, so server-side parameters are swept the same way as prompt features. A run gets a label encoding its active flags (condition "CEF" = deltas + killwait + ground-items).

A shell protocol (run-experiment.sh) makes each condition a clean episode:

• 1. create a fresh bot account and speedrun the tutorial (using the provided "Skip Tutorial" functionality)
• 2. record the XP baseline (always 980 after tutorial)
• 3. run exactly 20 decision turns
• 4. append {label, xpGained, coins, errorTurns, wallMinutes, ...} to results.jsonl

Twenty turns is short, but it is the compromise that makes volume possible: a condition takes 10-60 minutes wall clock, so an overnight batch covers 3-5 conditions. Batches chain themselves: each round's script polls the previous round's output file for a completion marker, then starts.

The metrics:

• xpGained: the primary score, since the standing goal is "train every skill"
• coins: the money half of the goal (almost always zero in practice; still an open problem)
• errorTurns: turns where the model's code threw; a proxy for how badly the setup is confusing it
• wallMinutes: because a feature that doubles quality but triples latency is a loss

Early rounds tested flags in combination (A, B, C, AB, AC, BC, ABC) because features interact. The world-state deltas flag alone was worth +755 vs a +232 baseline; stacking it with the memory blackboard destroyed it (+31). After the first rounds established a solid base stack (CEF), later rounds became champion vs challenger: test each new flag as CEF + one thing.

The single most important discipline turned out to be pre-registering a prediction before each round and writing down the result either way. Roughly half of my confident predictions were wrong, and the wrong ones were where all the learning was.

What won

Numbers are XP gained over 20 turns; the untreated baseline averaged roughly +900-1400 with large variance.

• World-state deltas (C): show the model changes in world state instead of a full dump every turn. +755 alone vs +232 baseline; the foundation of every later stack.
• Combat kill-wait (E): after attackNpc, automatically block until combat resolves instead of letting the model act on mid-fight state. CE hit +1715.
• Ground-item visibility (F): include what's lying on the ground in the digest. CEF hit +1764 and became the standard base.
• Precondition guard (N): intercept doomed actions before they execute, so chopTree() with no axe returns "you need an axe" instead of a game-engine error. +1860 with 2 error turns, the highest-scoring single flag tested.
• Faster engine ticks (T): peak throughput at a 150-200ms tick rate, about 136 XP/min vs 55 at the default 600ms (details in the next post).

What lost

• Memory blackboard (A): a persistent shared memory the model writes notes to. +10. It filled the context with incorrect self-generated notes, which the model then treated as fact.
• Bigger model (B): qwen3.5:9b scored worse than 4b (+355 vs ~+1400 on the same stack) while taking twice the wall time. The extra parameters did not improve grounding and doubled the wall time.
• Objective hints (D): telling the model what to pursue ("you should train fishing next"). CD +140 vs C +755.
• Location gazetteer (G): a seeded list of known world locations. +285. It walked to distant landmarks instead of using what was in front of it.
• Untrained-skill reminders (O): listing which skills are at zero. +140 with 13 error turns, the lowest score of any flag tested.
• Low-HP safety warnings (S): "your HP is low, be careful". +320. One run ended at 5 HP; the warnings appeared to draw the model toward combat rather than away from it.

Reading the chart: each bar is a 20-turn episode's XP with that flag in play (the sensing flags stack cumulatively: C, then CE, then CEF). Green marks flags that sense the world or enforce action semantics; gray marks flags that inject advice into the prompt; the dark bar is the untreated baseline. The worst green flag more than tripled the baseline; the best gray flag reached +320. That clean split is the finding.

The pattern

Every winner is ground truth the system sensed or action semantics the system enforced. Every loser is knowledge or direction a human seeded into the prompt.

Flags that describe what is (world-state deltas, ground items, honest action results) improved scores. Flags that tell the model what to think or want (objectives, warnings, gazetteers, its own past notes) made them worse. A 4B model does not reliably arbitrate between a directive and its senses; the directive gets applied at the wrong moment and functions as noise.

The precondition guard is the clearest case: rather than describing axe requirements in the prompt, let the model try, and make the failure message true and immediate. It is mechanical, costs no context, and outscored every prompt-level instruction tested.

The summary: better senses and better actuators, not better advice.

Next post covers the engine-side experiments: freezing the world, sweeping the tick rate, and letting fast models compete on wall time.

Everything runs locally. The game engine serves on localhost, a gateway bridges the bot client over a websocket, and a small Bun server I call the "agent server" sits in the middle. Each decision turn, the agent server snapshots the world state (nearby NPCs, trees, ground items, inventory, skills) and renders it into a text prompt. A local Ollama model (mostly qwen3.5:4b in the early rounds, later a 7B coder model) responds with a snippet of TypeScript against a bot SDK: bot.walkTo(x, z), bot.chopTree(), bot.attackNpc(/rat/i), and so on. The snippet runs, the world advances, and the loop repeats.

Everything runs at zero marginal cost, which changes what experiments are feasible: a failed 20-turn episode costs nothing but wall-clock time, so weak hypotheses are worth testing.

Pausing the world during inference

A 4B model on consumer hardware takes tens of seconds to produce each decision. The game is real-time, so the world keeps advancing during that delay. By the time the generated code runs, the state the model reasoned about is stale: the rat has moved, the fire has burned out.

Since I own the server, I fixed this at the source: the game world pauses while the model thinks. A tick-control endpoint (/api/tick-control?action=pause|resume) freezes the engine's tick loop during inference and resumes it during execution. The agent plays in lockstep, like a turn-based game.

This changes the question under test. Whether a small model can play an MMO in real time has a known answer: no. The open question is whether it can make sensible decisions given accurate state. A later post covers the engine-side experiments this enabled, including treating the tick rate itself as an experimental variable.

What the model actually sees

No pixels. The model gets a structured text digest:

• its position and stats
• nearby objects and NPCs with distances
• inventory and recent skill XP changes
• the result message from its last action

And it responds with code. That's the whole interface. Everything else in this series (the UI, the experiment framework, the dozens of feature flags) is about tuning what goes into that digest and what happens to the code that comes out.

Making it watchable

The first version of this project was logs scrolling in a terminal. Logs confirm the loop runs. They do not explain behavior, such as why the bot walked into a fence for ten minutes. So before any real experiments, I built a single-page UI that shows everything at once:

• The game itself, embedded as an iframe. The bot client is a real browser game client, so the agent's character is visible in the same view a human player would have.
• A chat log of the conversation: every prompt turn, every model reply, every execution result.
• A script panel showing the exact TypeScript the model wrote this turn, with a toggle between the raw model output and the cleaned code that actually executed.
• A pause indicator. Under lockstep the world freezes every time the model thinks. Without a badge saying "paused: thinking", a frozen game is indistinguishable from a crashed one.
• A send box, for injecting a message into the agent's context mid-run.

None of this is elaborate: one HTML file, no framework, a websocket. Its value was methodological: failure modes that aren't observable don't generate hypotheses. Most of the feature flags tested in later posts trace back to something first noticed in this UI:

• Watching it repeatedly try chopTree() with no axe led to the precondition-guard wrapper, which went on to post the highest score of any single flag tested (+1860 XP vs a ~+1400 baseline mean).
• Watching it never equip the sword sitting in its inventory led to a round of equipment experiments.
• Watching it stall against invisible walls led to the spatial-perception and learned-obstacle-map work.

Next post: the experiment framework, and which features actually helped.