What you will learn
- Distinguish a fixed workflow from a model-directed loop.
- Set explicit tool, step, time, and spending limits.
- Recognize when added autonomy is unnecessary.
- 01Goal + stateWhat remains to be done
- 02ChooseOne permitted next step
- 03Authorize + executeValidate arguments and limits
- 04Observe or finishUse actual results; stop on budget
Choose a workflow before choosing an agent framework
A fixed workflow has a known sequence: validate a form, search a policy, draft a reply. An agentic loop lets the model choose among permitted next steps based on observations. The distinction is about control flow, not whether the interface looks like chat.
Northstar's policy FAQ can begin as a fixed retrieval workflow. A question requiring both order data and policy evidence may benefit from a small tool-using loop. Do not make every request an open-ended planning exercise. Each extra decision creates another opportunity for delay, error, and unnecessary tool use.
Make state explicit
Keep the user's goal, permitted tools, observations, pending actions, and completion status in application state. Treat tool results as data. Record whether an operation actually succeeded instead of letting a later answer infer success from the fact that a call was attempted.
Planning can help organize complex tasks, but a plan is not authority to execute every step. A useful state machine might allow read-only lookup, policy search, and clarification while excluding cancellation entirely. If you later add cancellation, it needs separate authorization and an explicit confirmation step tied to the exact order and action.
Bound the loop
This pseudocode shows the controls around the model. The constants are teaching values, not universal defaults. Your implementation must also bound network calls and carry cancellation through the tool clients.
steps = 0
while steps < 4 and within_deadline() and within_cost_budget():
decision = choose_next_step(goal, permitted_tools, observations)
if decision.is_final:
return validate_and_render(decision.answer)
call = validate_tool_name_and_arguments(decision)
authorize(call, authenticated_user)
if repeated_unproductive_call(call, observations):
break
observations.append(execute_with_timeout(call))
steps += 1
return explain_incomplete_work_and_offer_next_step()The stopping condition should be visible to the user when it matters. “I could not retrieve the order status” is honest. “Your order is delayed” is not justified if the lookup timed out.
Evaluate the path as well as the answer
Measure task completion, unauthorized attempts blocked, unnecessary calls, tool failures, and total latency. A correct final sentence reached through an unauthorized lookup is still a failure. Test loops with empty results, repeated errors, and misleading tool text.
Multiple agents can divide genuinely separable work, but they add communication and coordination costs. A research agent and a reviewer may share the same mistaken assumption. Begin with one bounded loop and add another role only when an evaluation demonstrates a benefit. Frameworks can help manage state and tools; they do not remove the need to understand either.
PUT IT TO WORK
Your practice task
Draw a four-state workflow for a delayed-order question: identify the order, perform an authorized lookup, retrieve policy, answer or clarify. Mark the transitions a model may choose and those enforced by code. Add a timeout path and a repeated-tool-call path.
Checkpoint: compare your reasoning
A timeout should lead to an incomplete-status message, not a fabricated order result. Read-only tools can be available without granting cancellation authority. The model may choose what to request; the application decides what can execute.
References and further reading
Use these primary references for deeper study and current API details. Examples in this lesson use fictional Northstar data.