What Should Botie Do After a Tool Replies?

Botie searches for an inspection interval and finds a manual for an older pump. The excerpt is readable and the source is real, but it does not settle the technician’s question. A useful next step might be another search using the exact model number.

This is where selecting a next action can help. The model receives the search result and proposes what to do next. We still need a program that validates the proposal, records what happened, and stops when further attempts are no longer justified.

Try a successful final answer, a request for another tool at the limit, and a permanent tool failure. Build the decision from comparisons and branches.

continue

The next model request needs the task and the observations gathered so far. The application also needs control state: which tools are allowed, how many attempts have been made, and whether an earlier operation failed. These serve different purposes.

Store tool-call IDs with their results so parallel or delayed responses can be matched to the right proposal. Keep error results distinct from successful results. A timeout is evidence that a response was not received in time; it does not necessarily prove that a side effect never happened.

The previous lesson’s context selection decides what the model sees. The controller’s budgets and permissions remain authoritative even if older messages are summarised.

At each turn, the model may propose a tool call or a final response. The application validates the proposal. If it is a tool call, the server checks the tool name and arguments, checks permission, then executes and records its result. A later model request receives that observation.

This cycle is what makes a tool-using agent different from simply displaying model text. The software decides what actually executes. A proposal containing a function name must never be evaluated as arbitrary code. Look up the name in a bounded registry of approved implementations.

An unknown tool name should produce a controlled failure or repair opportunity. It should not become a shell command.

Our controller accepts a validated action of finish or tool. A finish action can return a checked final response, including an honest statement that evidence was unavailable. A tool action may continue only while the tool-attempt count is below its limit and the last status is ok. Otherwise control passes to a handoff response.

The workshop uses comparisons and Choose from a check to make this decision visible. It has no feedback wire: the real loop lives in the host program, which calls the controller again after the next observation. The Python exercise replays that host loop using a supplied list of events.

If action is finish: return answer
Otherwise, if used < limit and status is ok: return continue
Otherwise: return handoff

This order permits a final response after the last allowed tool attempt. It does not permit another tool just because the model says it is almost done.

A tool-attempt budget counts calls that were attempted, including calls that failed. Counting only successes allows an unreliable tool to be retried indefinitely. Increment the attempt counter when the call is issued, and persist it if execution can resume after a restart.

A tool limit does not bound every expense. One tool may take a long time, and the model may consume tokens between tool calls. A deployed system normally needs additional limits on elapsed time, model requests and token or monetary usage. Name each counter and decide what happens at its boundary.

This workshop’s used and limit refer only to tool attempts. We will not describe it as a complete cost limiter.

observations = ["ok", "timeout", "ok"]
attempts = 0
for status in observations:
    attempts += 1
    print(attempts, status)

1 ok
2 timeout
3 ok

A temporary connection failure may justify a retry with a limit and delay. A permanent permission denial will not become authorised because the model repeats it. A schema error may need corrected arguments. Keep these categories distinguishable in the tool result.

Our workshop controller treats permanent_error as a stop for further tools. It can still return an already prepared and checked final response explaining the limitation. The Python replay uses a more immediate policy: it hands off as soon as that error arrives, before accepting another proposal. These are deliberately different application choices; neither may execute another tool after the denial.

If a production service retries a side effect after an uncertain outcome, it must reuse the original idempotency identity and follow the tool contract. Otherwise an apparently helpful retry can duplicate an inspection.

Neither example implements timed retries. Repeated calls that return no new information can also justify a stop, but a progress detector needs a defined comparison of inputs and outcomes.

When the model requests finish, validate its response schema and evidence before showing it as a successful answer. It may correctly report that the available manuals are insufficient. That is different from claiming the maintenance question was resolved.

Record why execution ended: answered, missing evidence, denied action, exhausted budget or a service failure. A single completed flag loses those distinctions. Evaluations should distinguish successfully answering a question from merely reaching a terminal state.

In the workshop, answer means return the supplied final-response branch. The fixture does not include its text or verify factual correctness.

If the loop cannot continue, tell the technician what remains unresolved and which relevant sources were checked. Where appropriate, suggest the missing asset number or manual version that would let work resume. Avoid claiming that an unconfirmed tool action succeeded.

A human review path needs the actual proposed action and its evidence. A generic “approve agent” button provides too little information. When review changes a request, revalidate its payload and permissions before execution, just as in the tool-contract lesson.

The handoff is part of the task’s designed behaviour. It should be understandable even when the underlying service error was technical.

Scripted events let us test control logic cheaply and consistently. Include a normal path, a failure and a boundary where no further tool may run. The fixtures can prove that the counter and branching rules behave as specified on those inputs.

They cannot establish that a model selects useful tools, understands observations, or writes supported answers. Those require representative model runs and evaluation. Keeping these tests separate makes a failure easier to locate: deterministic control code, model behaviour, or the external service.

The following exercise returns both the terminal reason and attempted-tool count. Change a replay to predict where the host loop stops before running it.