Build the smallest complete loop

IDEA 1

Make the baseline work end to end

An end-to-end prototype takes an input, performs the necessary steps, and returns the specified output. It can be small. This lesson searches a fictional book catalog, reads the first matching record, and produces a sourced preview. The ranking rule is simply catalog order, so this is a workflow rather than a model-driven recommendation.

Keeping the first path simple helps locate failures. If search returns nothing, report no_match. If it returns an ID, read that record before writing a claim about it. A polished interface cannot compensate for a missing connection between the request and the underlying evidence.

One complete path

1. Input. A learner supplies a topic word.
2. Search. Return matching IDs in catalog order.
3. Read. Inspect the selected record before producing its note.
4. Preview. Return the ID and exact supporting note.

The catalog and search are authored fixtures; no library website or language model is contacted.

Handle absence explicitly

if (matches.length === 0) {
  return { status: "no_match", bookId: null, evidence: null };
}

The empty state is an intended result. It prevents an undefined lookup or a fabricated book recommendation.

Think it through: The catalog contains no match. Which output fits the contract?

IDEA 2

Retrieval finds candidates, not guaranteed answers

LlamaIndex separates querying into retrieval, optional postprocessing, and response synthesis. Retrieval may select top-ranked semantic matches: material judged similar in meaning. Postprocessing can filter or reorder them, and synthesis forms a response from the remaining context. Similarity can help find a differently worded passage, but it is not a truth or permission check.

Our lab uses a smaller baseline: case-insensitive substring search on topic, then the first catalog match. It runs no embeddings or model synthesis. Return the selected book ID with its exact note so a reviewer can inspect the connection. If later using semantic retrieval, still test missing and misleading results, retain source identity, and allow an unsupported answer to stop.

Translate the stages without inventing evidence

1. Retrieve. Collect potentially relevant records; ranking is not a verdict.
2. Postprocess. Filter or reorder candidates using explicit criteria.
3. Synthesize. Form an answer whose claims can be traced to the supplied material.
4. Our baseline. Keep a fixture ID and its exact note attached.

The first three steps describe a retrieval framework. The browser baseline reads a literal catalog match instead.

A related result can still miss the question

// Query: "When does our library close on Friday?"
// Candidate: "Libraries often stay open after school."
// Related topic, but no supported Friday closing time.

This invented example distinguishes relevance from answer support. A high rank cannot supply the missing time. Our catalog exercise returns a note and ID without claiming to answer facts absent from the fixture.

Think it through: A highly ranked passage discusses libraries but gives no Friday hours. What can the agent conclude about the closing time?

IDEA 3

Put approval before the action

Producing a draft and saving it are separate steps. This lab's savePreview tool only returns a simulated saved status; it writes no real file or account data. Even this small boundary is useful to practice: without a trusted approval flag, the workflow should stop at a preview.

In a real system, approval should come from the authenticated application and be tied to the specific action and version. A sentence inside a retrieved book note cannot grant it. The classroom input exposes an approved flag so you can test both paths without building an authentication service in the editor.

Preview, review, then act

1. Prepare. Construct the evidence-backed draft.
2. Gate. Stop unless the application says approved.
3. Simulated save. Call the allowed action only on the approved branch.

The trace should contain no savePreview call for an unapproved request.

A boundary you can test

if (!input.approved) return { status: "preview", ...draft };
const saved = tools.savePreview(draft);

The early return prevents the action call. Merely adding an unapproved label after calling the tool would be too late.

Think it through: Where must the approval check go?

Put it into practice

Create a catalog-backed preview and save it only in the approved simulation branch.

1. Run the unapproved case and inspect whether the starter calls savePreview.
2. Insert the early approval gate.
3. Run all cases, including the empty catalog result.
4. Change a fixture note and observe how the evidence field follows the tool output.

Your next experiment: Add a second matching record. The baseline chooses the first catalog match; how would you document a different ranking rule?

Make one complete path observable before expanding the prototype: input, tool evidence, result, and a tested stop.

Key terms

End to end

A working path from the intended input through processing to the specified output.

Early return

Ending a function before later statements can execute.

Evidence contract

The fields that connect a result with the observations supporting it.

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.