Decide → act → observe

IDEA 1

A requested action has not happened yet

A decision loop separates choosing an action from executing it. A model could request a tool by name with arguments. The controller checks that request and calls an allowed function; it should not execute arbitrary generated code.

ReAct studied interleaving model-generated reasoning with actions and environment observations. The useful controller idea here is to let new evidence affect the next action. Our choose function is authored: it requests readRoom before an observation and finishes afterward. You can inspect that control flow, but this is not the paper's model or a view into private model reasoning.

Dispatch one requested action

1. Decide. The simulated choice requests a room read.
2. Validate. The controller recognizes one allowed tool name.
3. Act. Only now does the function run.

Authored decision simulator; executed tool events appear only after a run.

Do not execute a name blindly

if (action.name !== "readRoom") {
  return { status: "blocked", room: null };
}

The check prevents an authored or real model request from expanding the controller's capabilities. Dispatch remains application code.

Think it through: What should the controller do with an unknown tool name?

IDEA 2

Store the tool observation

State is data the controller carries from one decision to the next. After a read, storing the result gives the next decision evidence that was previously absent. If you forget the update, the controller may request the same read again.

Use a separate observed flag because null can itself be a completed observation: the tool ran but found no room. ‘Not read yet’ and ‘read, but missing’ should not share the same state representation.

Beyond chat: Google DeepMind studies agents such as SIMA 2 acting in virtual 3D worlds. Its research also reports limits in memory, long tasks, and precise actions. The environment and available actions change, but the builder still needs observations and checks. This room exercise neither runs SIMA 2 nor demonstrates its performance.

The state update changes the next move

1. Before. No read has completed.
2. Observation. The requested ID is missing, so the tool returns null.
3. After. A missing room is still a completed read.

The example separates the fact of execution from the returned value.

Keep both pieces of state

const room = tools.readRoom(action.id);
state = { observed: true, room };

room stores the evidence. observed records that the operation completed, preventing null from being confused with an unstarted call.

Think it through: The lookup returns null. Should observed become true?

IDEA 3

Finish or stop at the limit

A loop needs a success stop and a resource stop. Our success condition is a finish action after an observation. maxTurns bounds how many decision turns can run even if the simulator repeatedly asks for a read.

A trace records visible requests, results, and errors. It is not a transcript of a model's private internal reasoning. If the limit is reached, report that state explicitly and retain any verified observation instead of labeling the run complete.

Two ways to stop

1. Turn 1. Read the room and update state.
2. Turn 2. The simulator returns finish using the observation.
3. Limit. If finish never arrives within the budget, report limit.

A classroom turn includes one decision and, if requested, one tool call.

A finite controller

for (let turn = 0; turn < input.maxTurns; turn++) {
  // choose, validate, act, store
}
return { status: "limit", room: state.room };

The counter increases every turn. Even a repeated request cannot extend this declared loop forever. The runtime also has an independent execution limit.

Think it through: The simulator keeps requesting reads after two allowed turns. What is honest?

Put it into practice

Make the decision simulator finish after one read, while preserving a finite stop for repeated requests.

1. Run the normal case and observe the repeated reads in the starter.
2. Find the state update placeholder immediately after readRoom.
3. Insert both observed and room into state.
4. Run the repeated-request case; it should stop at its limit even after the repair.

Your next experiment: Set maxTurns to 1. Why can a read succeed while the loop still reports limit?

Feed observations back, distinguish missing from unread, and stop even when decisions repeat.

Key terms

State

Data carried through a run so later steps can use earlier observations.

Turn

One controller decision and any tool action it dispatches in this exercise.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.