Run with real libraries and model limits

IDEA 1

Separate the library, model, and runtime

A framework organizes software; model weights are learned numerical parameters; a runtime executes a program. Hugging Face's public Agents Course compares smolagents, LlamaIndex, and LangGraph, while OpenAI provides an Agents SDK. These are not interchangeable model names. Choose a library for a concrete job, such as organizing a graph or connecting retrieved evidence, then configure a compatible model separately.

The optional reference here uses LangGraph for the loop, ChatOllama for calls to a local Ollama server, and downloaded Qwen weights for inference. Our browser lab instead runs plain JavaScript with an authored reply. Installing a graph package alone does not download weights or start inference. The components have separate licenses, hardware needs, and data destinations.

Four different jobs

1. Graph. LangGraph chooses the next node according to the program's connections.
2. Model server. Ollama runs downloaded weights on the learner's own machine.
3. Tool. An ordinary function returns fictional room facts.
4. Controller. Validate requests, bound turns, and expose observations.

The actual SDK files are reference downloads. The browser VM does not import them.

A library is not a model

import { StateGraph } from "@langchain/langgraph";
// This import supplies graph APIs, not model weights.

This is a reference-file import for a separately installed local project. It cannot be pasted into the browser solve function to create a live model.

Think it through: You installed a graph framework. What can you conclude?

IDEA 2

Test the real tool before adding a model

A tool can be tested without a language model. Give the function a known input and compare its output to an expected result. In the downloadable graph, state carries the messages and observations; nodes perform work; edges control the next step. A scripted reply tests whether a tool request reaches the tool and its observation returns to the model node.

Those offline tests establish wiring for their cases, not Qwen's generation quality. A live model may request wrong arguments, skip a tool, repeat a request, or produce a wrong answer. Keep validation and stop limits when switching to inference. First inspect which layer failed: the tool's facts, the graph's path, or the model's choice. Changing all three at once makes a comparison hard to interpret.

Two kinds of tests

1. Tool test. Check deterministic room facts first.
2. Wiring test. A scripted reply asks for the real tool and receives its result.
3. Live trial. A configured local model chooses actions that still need checks.

The same tool can participate in an offline wiring test and a separate live-model run.

Read the fixture

// A: 18 seats, available
// B: 24 seats, unavailable
// C: 32 seats, available
// For 24 students, only C qualifies.

An offline test can establish the expected tool result for this fixture. It cannot establish that a live model will correctly use that result.

Think it through: The offline scripted graph tests pass. What remains untested by those tests?

IDEA 3

Report execution honestly

A trace records requests and observations. Record execution mode and configuration alongside it: our modelReply is an authored fixture even when its text claims otherwise. In a local trial, compare the final recommendation with tool facts and retain failures. The supplied reference bounds time and calls; it does not promise correct answers or completion on every device.

Also name what survives a restart. LangGraph checkpoints save state within a thread; a store supports data across threads. An in-memory checkpointer disappears when its process ends. Neither a graph import nor the browser's saved code draft establishes durable agent memory. The downloadable kit does not promise cross-run conversation persistence. Adding that would require an explicit storage and access design.

Verify the answer and its label

1. Environment. The lab identifies itself as scripted.
2. Reply. An authored answer proposes a room ID.
3. Verification. Read independent room data and check availability and size.

Use trusted environment information for the execution label, not a generated claim.

Preserve the actual mode

return { execution: info.execution, roomId, verified };
// Do not copy reply.claimedMode into the execution label.

The environment identifies how the run works. The candidate answer still needs independent checking.

Think it through: A scripted reply claims it called a live model. Which label belongs in the report?

Put it into practice

Verify a proposed room against the fixture and report the actual scripted execution mode.

1. Run the starter on the too-small proposal.
2. Insert the availability-and-capacity verification.
3. Compare the three outputs with the room evidence and inspect the scripted label.
4. Use the optional source files below only in a separate local project; they are not browser imports.

Your next experiment: Mark C unavailable. Does the proposed answer still earn verification?

Name the framework, runtime, model, and execution mode separately; test the tool and still verify the answer.

Key terms

Model weights

Learned numerical parameters used by a model during inference.

Runtime

The environment that executes a program or model.

Scripted reply

An authored response used to exercise program behavior without a live model.

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.