Part 2: The Loop | Garage Education

Chapter 5: Writing the agent loop by hand

Sat, 10 Oct 2026 00:00:00 +0000

The loop has four steps. Send the messages to the model. If the reply has no tool calls, return its text. Otherwise run each tool, add the results to the messages, and repeat.

Figure 5.1. The four steps, with the step cap from the code below. The other stop rules come in Chapter 6.

Turn off automatic tool execution, so the code runs each tool itself.

ToolCallingChatOptions options = ToolCallingChatOptions.builder()
 .toolCallbacks(ToolCallbacks.from(logTools))
 .internalToolExecutionEnabled(false)
 .build();

for (int step = 1; step <= MAX_STEPS; step++) {
 ChatResponse response = model.call(new Prompt(messages, options));
 AssistantMessage reply = response.getResult().getOutput();
 messages.add(reply);
 if (!reply.hasToolCalls()) {
 return new RunResult(reply.getText(), StopReason.FINAL_ANSWER, step);
 }
 // run each tool call, add ToolResponseMessage to messages
}

Figure 5.2. A two-step run. Because internalToolExecutionEnabled(false) is set, your loop runs the tool, not Spring AI. Each step resends the full message list.

Verify: Confirm the class names and builder methods for your Spring AI version. They change between releases.

Chapter 6: Termination

Sat, 10 Oct 2026 00:00:00 +0000

A run ends in one of these ways: a final answer, a step limit, a token budget, a timeout, or loop detection. Every run returns a RunResult with the reason, so failures are easy to read.

Figure 6.1. Each way a run ends maps to one StopReason. The chapter does not fix an order for the checks; this order is one reasonable choice. APPROVAL_TIMEOUT and REJECTED come from the approval path in Chapter 9.

public record RunResult(String answer, StopReason reason, int steps) {
 public enum StopReason { FINAL_ANSWER, STEP_LIMIT, TOKEN_BUDGET, TIMEOUT, LOOP_DETECTED, APPROVAL_TIMEOUT, REJECTED }
}

Chapter 7: Guardrails

Sat, 10 Oct 2026 00:00:00 +0000

Put guardrails in code, not in the prompt.

Argument checks. Reject a minutes value outside 1 to 1440 before the tool runs. Return the error text to the model.
Allowlist. Each agent has a fixed set of tool names. Reject any other name.
Loop detection. Count each tool name plus arguments. Stop when one key repeats three times.

Figure 7.1. The three guardrails, in front of every tool. Each one is a line of Java, so the model cannot talk its way past it.

Chapter 8: Graphs

Sat, 10 Oct 2026 00:00:00 +0000

A graph makes the flow explicit. Each stage is a node. Each move between stages is an edge. Keep the control flow in plain Java, so every edge has a unit test. A graph database is a different tool, used for relationships between services. Chapter 8b covers it.

Figure 8.1. An illustrative watcher graph, assembled from the eval cases in Chapter 20, the triage skill in Chapter 14, and the approval in Chapter 9. Each arrow is one edge to unit-test. The course does not fix the stage order, and it does not define the low and medium path.

The graph above is a teaching sketch, not the course’s specification. What the watcher does with low and medium severity is NEEDS INPUT: the low and medium severity path, for example post without approval or record only.

Chapter 9: Human-in-the-loop

Sat, 10 Oct 2026 00:00:00 +0000

A critical alert waits for a person. The workflow sets its state to awaiting approval and waits for an approval signal or a one-hour timer. Temporal stores the wait, so a restart does not lose it. Chapter 24 shows the code. Keep an audit row in PostgreSQL for each decision.

Figure 9.1. The approval path for a critical alert. A rejection writes the audit row and stops with REJECTED. How the person is notified is not covered here.