Choose autonomy only where it helps

Begin with a concrete job

An agent is useful when the next useful step depends on observations that were unavailable at the start. Imagine a documentation helper: it might search one topic, discover an unfamiliar term, search again, and finally assemble an answer. A fixed workflow is preferable when the required sequence is already known, such as validate a form, calculate a value, and format a receipt. Neither label guarantees quality. The engineering question is whether adaptive choice improves a measured outcome enough to justify extra latency, uncertainty, and testing. Write the job as a contract before building anything. State the input, the deliverable, the evidence required, and the actions outside scope. Our course project answers questions from fictional local documents and prepares a draft. It never sends real messages. A useful success definition is a correct draft whose claims point to permitted documents, completed within a bounded number of steps.

Use the smallest decision surface

A system can combine deterministic and adaptive parts. Code might always validate a request first, allow the model to choose among three read-only research tools, and always run a citation check last. This hybrid preserves flexibility where information is missing while keeping routine requirements explicit. Avoid giving the model choices that can be computed reliably: a known missing field should trigger validation, not a creative discussion about whether the field matters. Create a decision inventory. For each branch, ask what evidence selects it, what the consequences are, and whether ordinary code can decide. Searching another source may be low risk; publishing a statement has a different consequence. A generated recommendation is data entering your program, not permission to execute. The application remains responsible for deciding which recommendations are valid and authorized, even when the model sounds certain.

Compare against an honest baseline

Build a baseline that performs the job with minimal moving parts. For the documentation helper, begin with keyword lookup and a fixed answer template. Assemble cases that include a direct answer, missing information, ambiguity, and an irrelevant request. Record correctness, unsupported claims, tool count, and completion time. When a more adaptive design performs better, identify which cases improved and which got worse. A higher average score can conceal serious regressions on sensitive or unusual requests. The worked example below routes known cases using a small dictionary. It is intentionally not an intelligent language model. Its purpose is to make the input and output boundary visible before replacing one decision component. Change only the routing implementation later and retain the same test cases. This lets you attribute differences to the changed component rather than to an entirely redesigned application.

Translate the design into an inspectable run

Represent a run with an identifier, current status, observations, and a final outcome. Useful terminal outcomes include completed, insufficient evidence, rejected, and failed. A pause for user clarification is different from a failure. Do not collapse them into a single empty answer: the user and the operator need to know whether another input can make progress. Define what the application reports when its evidence is incomplete instead of rewarding a polished guess. Run the example with Python and compare its three lines with the expected output. Then inspect why each branch was selected. If the spelling of a case changes, the program chooses the fallback; that is a fixture limitation, not evidence that the architecture is broken. LangGraph's official workflow guide and the Agents SDK introduction offer framework terminology. Our offline baseline teaches the decisions underneath those frameworks without depending on an account or changing package interface.

A baseline with explicit uncertainty

This is a runnable decision-boundary exercise, not a model-powered agent. The unknown case has a visible clarification result instead of a fabricated answer.

def route(case):
    known = {"reset password": "retrieve", "format receipt": "workflow"}
    return known.get(case, "clarify")

for case in ["reset password", "format receipt", "something unusual"]:
    print(f"{case} -> {route(case)}")
assert route("something unusual") == "clarify"

Ready to try it yourself?

ChatGPT sign-in takes you to OpenAI and back to CodeTrail. It keeps your learning account separate from other learners.