Call a tool, then check the evidence.

An answer is not an action

A predictor takes an input and produces an output. An agent operates over time: observe → decide → act → observe again. It keeps enough state to connect earlier decisions with later consequences. A model might propose a tool call, but another component must actually execute it.

Calculators, compilers, databases, search systems, and robotic controls perform different operations. The controller selects a tool and supplies arguments. The runtime checks those arguments and its own authorization rules before dispatching the operation. It returns a result or an error as an observation.

In this lab you are the controller. The calculators are local programmed functions, and the failures are simulated. There is no trained tool-selection policy or language model behind the buttons. This separation lets you inspect what a future learned controller would have to handle.

Follow one complete call

The question is 347 × 28. A structured call names the action and carries numerical inputs. The runtime permits calculation, checks the argument types, and executes multiplication. A successful response contains 9,716, a copy of the request, and a receipt revision. The final arithmetic check decomposes the product: 347 × 20 = 6,940 and 347 × 8 = 2,776; their sum is 9,716.

That number becomes evidence in the current history. It is not a weight update. Training would require a separate procedure that constructs a learning objective, computes or estimates an update, and retains changed parameters. Reusing an observation as context and learning from it through gradients are different operations.

Check more than the format

Check	What it can establish	What it does not establish
JSON and argument schema	The request has the supported fields and input types	That the task is useful or authorized
Runtime permission	This action is allowed in this environment	That it will succeed or answer the question
Response schema	The result has the expected fields and types	That it belongs to this request or is true
Receipt and provenance	Which request and revision produced the evidence	That an external source is complete or accurate
Task-specific verification	The particular property being checked	Every other property or a general reliability guarantee

The wrong-operation preset adds 347 and 28. It is well formed and returns correct arithmetic for the request, yet does not answer the assigned multiplication question. The old-receipt scenario returns arithmetic from another request. Its format is valid, but its provenance does not match. Arithmetic does not expire; a cached observation can simply be attached to the wrong task. In changing domains, timestamps and source freshness matter too.

Even a current response can be incomplete. An empty search result, for example, does not prove that the requested fact does not exist. Interpret observations within what the tool actually measured or searched.

Let the failure determine the next action

Retry can help with a transient failure, such as the first-call timeout here. Repair the arguments when the schema rejects them. Switch to a compatible tool if one repeatedly returns malformed results. Inspect the request, source, or execution history when the evidence is unclear. Stop when the task is complete, permission is missing, or the attempt allowance is exhausted.

This lab caps each trial at three attempts, including invalid calls. It keeps the request, tool, checks, and observation for each attempt. A real controller needs an execution history for the same reason: “the calculation was requested” is a hypothesis about what should happen; “a matching result was received” is an observation about what did happen.

A timeout does not always mean an operation had no effect. Retrying a read-only calculation is different from retrying a payment or a file deletion that may already have completed. Systems with external effects need status checks and mechanisms that prevent duplicate effects before they retry. The denied-action preset performs no deletion: the runtime blocks it independently of the controller’s proposal.

Design a debugging loop

The source exercise asks for an observation–action sequence to debug a failed Python test. Before opening the worked answer, describe the first action, the evidence it returns, and one recovery branch.

Worked debugging sequence and failure branch

1. Run the relevant test within the permitted environment. Preserve the command, exit status, and output.
2. If the test runs and reports an incorrect value, inspect the failing assertion and relevant code. Form a specific hypothesis before proposing a change.
3. If the test cannot start because a dependency is missing, treat that as an environment failure, not evidence that the implementation is wrong. Inspect the declared setup or report the missing capability before retrying.
4. After an authorized change, rerun the failing test and relevant regression checks. Passing only the original test does not establish that unrelated behavior stayed correct.
5. Record the result and stop at the agreed scope or resource limit. Keep observations, hypotheses, and changes distinct.

This is a design exercise; the website does not execute Python or modify files.

Tools expand what a system can do. Reliable use still depends on choosing a relevant operation, enforcing boundaries outside the model, and interpreting feedback correctly.