ReAct and deterministic tool calling

The slide splits one turn of the loop into two boxes. On the left the model proposes, and everything there is sampled. On the right the runtime decides, and everything there is deterministic. The line between them is where your guarantees live.

ReAct

ReAct (Yao et al., 2022, published at ICLR 2023) interleaves reasoning with actions and observations: the model thinks, chooses an action, reads the result, thinks again. On the ALFWorld and WebShop benchmarks it beat imitation and reinforcement learning baselines by 34 and 10 absolute success-rate points. On HotpotQA a frequent failure was the model repeating earlier thoughts and actions in a loop, which is why every loop needs an iteration cap.

Tool calling

Provider APIs call this tool or function calling. You describe each tool with a name, a description and a JSON schema for its arguments. The model returns a tool name and arguments, and at that point nothing has run. Your runtime validates the arguments against the schema, authorises the call for this user, executes it with a timeout, and returns the result or a structured error as the next observation. Provider-hosted tools such as web search run server-side, outside your gate, so treat them as a different class.

The schema on the slide is a contract. refund_order takes an order ID and a reason from a fixed list of three, and nothing else. Strict mode guarantees that the arguments match the schema, barring truncation or refusal. It does not guarantee the right call. A well-formed order ID can still be the wrong order.

Runtime rules

• Known step? Call the business API from code, or force the tool where the API supports it. Do not ask the model to choose what you already know.
• Key idempotency on the business operation, not on the model’s call ID. A retry gets a new call ID.
• Return errors as observations the model can act on, with the exact validation message.
• Cap iterations.

Where it goes wrong

Parallel tool calls. The model requests three lookups, the runtime returns two results, and the provider rejects the next request. Return one result or one error per call ID, every time.