The tool was not the problem.

THE QUESTION BEFORE DISCOVERY

The earlier machine experiments asked when an agent would choose to act. A website could invite it, offer useful information, or ask for a favour. But there was another explanation to clear away: perhaps an agent sometimes stops because the mechanism is too awkward to use. Before asking what makes an action worthwhile, I wanted to know what the agent could actually do.

ONE VALUE, SIX ROUTES

At LLM Wilds I gave each fresh agent the same task: find the exact value of K17 and explain how it obtained it. The value existed only through one documented mechanism. A link. A query. A form. A stream. A socket. A module. Only one was live for each visitor. The value changed between visitors, so a correct answer could be checked against that deployment. The prompt named the task page and prohibited installing dependencies.

THE EXPECTED BREAK

I expected ordinary HTTP requests to be straightforward. WebSocket and WebAssembly seemed likelier to introduce a boundary: the agent would have to construct a client or run code supplied by the site. The preregistered hypothesis predicted fewer decisions to use those mechanisms, or fewer permitted executions. It also stated what would falsify that prediction: the code-requiring mechanisms completing the task as often as the HTTP ones.

USABLE DID NOT MEAN IDENTICAL

The first four routes needed no new code. The agents used curl to fetch a link, supply a query, reproduce a form POST or read a finite server-sent event stream. The WebSocket and WASM visitors wrote scripts. The final report calls those routes usable with construction. Equal completion does not mean equal effort, equal latency or interchangeable interfaces. The distinction survived even though the predicted failure boundary did not.

THE TOOLBOX IT IMAGINED

The socket visitors made that construction unusually revealing. Two wrote clients from Python's standard library. One said no WebSocket package was installed. It had not checked. The frozen inventory recorded two Python packages and websocat already available, alongside other routes. The third visitor inventoried its tools, used an installed package and cross-checked with websocat. A cheap existing route was used only once, as verification.

A CONSTRAINT BECAME AN ASSUMPTION

The instruction was to install nothing. It did not say that nothing useful was installed. The report interprets two visitors' choices as turning a no-install constraint into an assumed lack of clients. Their hand-built routes still worked. What changed was the work they chose to do. That is an observation about these transcripts and this inventory, not proof of an internal decision rule. But it makes the available tool and the believed-available tool worth separating.

THE MODULE WAS INSPECTED

The three WASM visitors followed a strikingly similar sequence. Each downloaded the module, checked it against the site's published SHA-256, inspected its imports and exports, instantiated it in Node's built-in WebAssembly engine and called the exported function. Each then independently checked the result, by decoding the computation or using another engine. One reproduced the answer in wasmtime as well as Node. Another decoded the whole module before running it.

WHAT THOSE CHECKS MEAN

The agents described the module as local computation and reasoned about its empty import list. None added a separate sandbox. Those are recorded choices, not a recommendation for executing arbitrary remote code. Matching a hash supplied by the same website checks that the downloaded bytes match the advertised bytes; it does not independently establish that the website or the program is trustworthy. Here the relevant observation is that inspection preceded execution and unfamiliar packaging did not stop the task.

THE CONSTANT WAS VERIFICATION

Every visitor checked its result. The HTTP visitors fetched again. The stream was reopened. The socket was reconnected. The module was decoded or reproduced. The repeated requests are checks by the same subject, not extra replications. What persisted across these six small groups was an effort to verify the answer after finding a way to obtain it. The richest construction was not the only place that care appeared.

A DIFFERENT PAGE ARRIVED

Ten of the eighteen visitors used WebFetch, the harness's own fetching tool. None obtained K17 through it. It helped with reading and discovery, but it also changed what was encountered. One visitor noticed that the machine notes had been paraphrased and fetched the original with curl. Later, subject 17 received subject 15's old GET-link instructions while the live site was serving a WebSocket contract. No corresponding request for those notes reached the lab.

THE CLUE CAME THROUGH THE HARNESS

The report attributes that stale response to caching across subjects despite the site's no-store header. Subject 17 tried the old route, found a 404 and inferred that the mechanism rotated. It still completed the task using the socket. The experiment was not named, but a clue about the changing conditions had crossed the intended boundary. This was the recorded blindness breach. A separate habitat had removed the publication's back catalogue; it had not removed the harness's memory.

THE QUESTION MOVES

For this agent, on this well-equipped workstation, the six described mechanisms were usable when the task required them. That makes me want to move the next experiment earlier in the encounter. What makes an agent notice a capability, understand what it offers and put it among the actions it considers? A site can have a working interface that never becomes relevant to a visitor. This study did not measure that failure: I had supplied the address.