A model is one part of the system

IDEA 1

Follow an input to a model response

A language model receives context and generates a response. Context can contain your request, instructions, and information supplied by the application. A response may be ordinary text or a structured request to use a tool.

Generating ‘Room Cedar is available’ does not itself inspect a calendar. To support that statement, a system needs an observation from an appropriate source. Our classroom examples use authored responses and fictional records; they do not contact a live model.

Words and evidence have different paths

1. Request. The learner asks about a club room.
2. Response. A model can generate a sentence from the context it receives.
3. Evidence check. Look for an actual room lookup and its result before accepting the claim.

Authored classroom illustration: a plausible sentence alone contains no record of a lookup.

A sentence is a string

const response = "I checked Cedar.";
const observation = null;

The first line stores text. The second explicitly says this example has no observation. Assigning a string does not execute the action described inside it.

Think it through: What proves a room lookup happened in this lab?

IDEA 2

Separate instructions from program actions

An instruction describes desired behavior. A controller is application code that decides which operations are allowed to run. A tool is a callable function that reads information or changes something within its permitted scope.

Suppose a response requests readRoom with an ID. The controller must recognize the allowed tool and execute it. Until execution, this is a request. A person or an executable policy can stop the request at that boundary; a tool's name is not permission.

Where the request becomes an action

1. Instruction. Ask the helper to check the room before answering.
2. Controller. Recognize the one permitted operation; reject other names.
3. Tool. Execute the allowed function and capture its result.

This lesson permits only reading a fictional room record.

A request object does not call a function

const request = { tool: "readRoom", id: "cedar" };
// Later, allowed controller code executes:
const observation = tools.readRoom(request.id);

Creating request stores two fields. Only the function-call expression on the last line invokes the tool. Our lab traces that executed call.

Think it through: A response requests deleteRoom, but the controller allows only readRoom. What should happen?

IDEA 3

Spot what makes a loop agentic

A fixed workflow follows a route chosen by its programmer: read a record, format a summary, finish. A model-directed agent loop lets a model choose a next step using the goal and observations, while application code controls execution and limits. Anthropic uses this distinction to help builders choose an appropriate design.

Start with the smallest design that meets the task. Adding two club expenses needs arithmetic. Turning approved event details into a draft might need one model call. Investigating an incomplete event plan might justify several decisions and tool reads. Compare the extra work with the benefit before adding autonomy.

A loop is not automatically AI. A JavaScript for-loop over rooms is ordinary program logic. Our runnable request is authored input, so you can inspect one controller turn before building a longer loop. The practice shows the parts; it does not run a live model.

Observe before choosing the next move

1. Choose. A real agent's model might propose a read. Here the request is authored.
2. Observe. The tool returns the record, not a promise of success.
3. Decide again. An agent could inspect another room or report no match, subject to a limit.

Illustrative sequence; the runnable exercise implements one permitted controller turn.

Fixed route versus a decision loop

// Fixed route: the programmer chooses each step.
const room = tools.readRoom("cedar");
return { available: room.available };

This code follows one fixed route even though it uses a tool. Tool access is useful, but model-directed choice of subsequent steps is a separate feature.

Think it through: Which behavior needs an observation fed into the next decision?

Put it into practice

Dispatch only readRoom and return the exact observation, or a clear blocked/missing result.

1. Run the starter: the allowed request currently stops with no observation.
2. Find the placeholder after the allowed-tool check.
3. Insert the snippet that actually calls readRoom and returns its result.
4. Run all cases. The blocked request must make zero tool calls.

Your next experiment: Change available to false. Why should the status still be observed?

A model proposes; the surrounding program controls actions and records what actually happened.

Key terms

Controller

Application code that dispatches allowed actions, records results, and enforces stopping rules.

Observation

Information returned by an executed tool; it still needs interpretation and checking.

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.