Choose a person and a small problem

IDEA 1

Start with one person and one decision

A useful scope names who has a problem and the small decision the program helps them make. “Help a club treasurer compare two fictional supply baskets” gives you a user, inputs, and a decision. “Run a business” leaves almost every requirement undefined.

Write the expected output before choosing a model. A structured comparison with totals and missing prices can be checked. A paragraph that merely sounds helpful is harder to evaluate. Use fictional or sanitized examples that you are allowed to include; extra personal data does not make the project more educational.

Turn an idea into a contract

1. Person. Name the intended learner or fictional user.
2. Decision. Specify a bounded comparison.
3. Output. Name what another program or reviewer can check.

The first prototype should answer one question with inspectable evidence.

Replace an untestable goal

// Too broad: "Make the best event."
// Testable: "Check whether this plan fits 30 seats and a $40 budget."

The second version identifies two conditions and supplied quantities. It still leaves the human responsible for deciding whether the event should happen.

Think it through: Which goal is easiest to evaluate fairly?

IDEA 2

List allowed actions before connecting tools

A project boundary is a concrete list of data and actions the program may use. Reading a fictional catalog and calculating totals are different capabilities from placing an order. Your architecture should make the allowed set visible before any action runs.

A requested action is not automatically authorized. This lab compares a proposed project's action names with a fixed allowlist. That is a scoping check, not a complete production security system. A deployed system would still enforce permissions on each actual tool call and protect credentials outside model text.

Check scope explicitly

1. Proposed actions. Read the brief's requested capabilities.
2. Allowed set. Obtain the capabilities permitted in this classroom project.
3. Scope issue. Flag purchase instead of silently expanding access.

The exercise validates a project brief; it does not perform the proposed actions.

One unsupported capability is enough

const outOfScope = actions.some(action => !allowed.includes(action));

some returns true if any requested action is outside the permitted set. You can then revise the brief before implementing tools.

Think it through: A brief requests purchases but the project permits previews only. What comes next?

IDEA 3

Choose a baseline and a stopping rule

A fixed workflow may be sufficient when steps and rules are known. A loop may help when observations determine what to inspect next. Hugging Face's framework introduction explicitly leaves room for plain code; DeepLearning.AI's public LangGraph course outline builds an agent from scratch before translating it to a framework. The lesson is to understand the behavior before adding the library.

For our original school project, keep a plain-code baseline, a call limit, and an unresolved-result fallback. The allowed one-to-four-call range is a classroom constraint, not an industry standard. The lab's adaptiveSearch flag suggests an architecture; it does not prove a model is needed. Compare the same inputs, outputs, and permission checks before deciding whether an agent loop earns its complexity.

Select the smallest useful design

1. Fixed steps. Known rules can be ordinary code.
2. Observation changes the next step. Consider a bounded loop when the task needs adaptation.
3. Stop. Name a call limit and the unresolved-result behavior.

Architecture follows the work; a label does not establish quality.

Write the comparison before choosing a library

// Original project plan:
// Baseline: read both baskets, calculate totals, return preview.
// Candidate: choose follow-up reads when prices are missing.
// Both: no purchases; same expected totals; explicit missing prices.

The adaptiveSearch flag is only a design hint. A candidate must solve the same scoped problem; framework names, diagram size, and model confidence do not substitute for the comparison.

Think it through: What makes a baseline comparison useful?

Put it into practice

Reject incomplete or overpowered briefs and suggest a simple architecture for a valid one.

1. Inspect the publishing brief and its allowed actions.
2. Run the starter: it overlooks an out-of-scope capability.
3. Insert the action-scope check and run all cases.
4. In the custom input, switch adaptiveSearch and predict the architecture.

Your next experiment: Set adaptiveSearch to false, then change maxCalls to 0. Which change selects a different design, and which invalidates the brief?

A clear small scope makes implementation, permission boundaries, and evaluation possible.

Key terms

Scope

The problem, inputs, outputs, and capabilities included in a project.

Baseline

A simpler version measured under the same task and checks.

Allowlist

An explicit set of permitted values or capabilities.

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.