Call a tool, then check the evidence.

This is the same reference used in Technical mode. Expand it whenever you need the exact numbers, assumptions or further explanation.

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

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.

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.