Solutions — Reflection on the Agent Loop

Lesson 01 · Worked solutions · reference answers + why-this-not-that commentary

These are reference answers for the three reflection tasks in Lesson 01 homework. For Tasks 1 and 2 there is essentially one defensible answer per scenario and the commentary explains why. For Task 3 the numbers below are a defensible example — yours will differ and that is fine. What matters is that you wrote down explicit numbers and explicit escape hatches at all.

How to read these solutions

Each task below restates the scenarios, gives the model answer, and ends with a Common mistake callout. The common-mistake notes are the most useful part — they are the errors readers actually make on these prompts, gathered across reviews. If your answer matched a common mistake, read the surrounding commentary carefully.

Solution 1 — Agent, pipeline, or chatbot?

Solution to Task 1

(a) GitHub Copilot's chat panel → chatbot.

There is no loop and no tool use — one LLM call produces one response and the exchange ends. None of the four stop conditions apply except the trivial one ("the model finished its response", i.e. stop_reason: "end_turn" on a single call). The chat panel has no tools because it is not an agent — the model cannot take an action in the world; it can only emit text.

(b) Post-quantum research assistant → agent.

This is the textbook case: LLM-driven control flow, multi-step, tool use, and the next step depends on what the previous step returned. The agent decides on each iteration whether to search again, fetch another PDF, or stop and write the summary. All four stop conditions matter: natural exit (end_turn when the agent decides it has enough material), turn cap (10–50 steps means you must bound it), cost cap (each PDF fetch and read costs real tokens), and user interrupt (long runs need a kill switch). Tool set: web_search, fetch_url, read_pdf, optionally save_note for incremental scratchpad memory.

(c) Document summarisation Lambda → pipeline.

The control flow is hard-coded in Python: OCR → LLM call → write to S3 → exit. The LLM is one node in a fixed graph; it never decides what to do next. No stop conditions are needed beyond the LLM's single-call end_turn. The Lambda could grow into an agent later — adding "and ask the LLM to summarise, then self-grade the summary, and retry if the grade is below 4" would introduce a feedback loop and push it into agent territory — but as written it is a pipeline.

Common mistake

Classifying (a) as an agent because "Copilot is an agent" in marketing copy. The product brand is "Copilot"; the chat-panel feature in isolation is a one-shot completion, not an agent loop. If Copilot were autonomously opening files, running tests, and proposing pull requests across multiple turns, that behaviour would be an agent — but the chat panel by itself is a chatbot. Always classify the behaviour, not the product name.

Solution 2 — Picking the planning style

Solution to Task 2

(a) Travel planner → Plan-and-Execute.

Once the 3–4 clarifying questions are answered, the booking actions (flights, hotel, dinner reservations) are independent and known up front. Planning the full sequence first and then executing it is more predictable, cheaper, and easier to test than re-deciding what to do every turn.

(b) Debugging assistant → ReAct.

You literally cannot decide which variable or stack frame to inspect next without seeing the output of the previous inspection — the work is observation-driven by nature. ReAct's think → act → observe cycle is exactly what this scenario needs.

(c) Code-modernisation bot → ReWOO.

The 12 refactors are independent of each other. You can plan all twelve in one LLM call (which files, which refactor each), then execute them in parallel (or in any order). The agent does not need to reason between refactors because nothing it learns from refactoring file 3 changes what it should do to file 7.

Common mistake

Picking ReAct for (a) because "the agent might need to think between bookings". It works, but it is wasteful: once you have the user's constraints, you do not need an LLM thought step before each booking call. The bookings are decision-independent. Reserve ReAct for problems where the next step genuinely depends on the previous observation — if you can write the plan on paper before running it, use Plan-and-Execute or ReWOO instead.

Solution 3 — A defensible stop-condition budget

Solution to Task 3

Below is a sample budget for the customer-support triage agent. Your numbers will differ — that is expected and fine. Compare the structure of the reasoning, not the specific numbers.

(a) Turn cap: 10 turns.

Justification: a healthy triage run looks like classify (1) → account lookup (1) → recent tickets (1) → recent orders (1) → analyse (1) → resolve or hand off (1). That is six turns in the happy path. Doubling it to 10 gives headroom for one retry per tool and one re-classification, but no more. Past 10 turns the agent is almost always confused — better to escalate to a human than to keep looping.

(b) Cost cap: $0.10 per ticket (Haiku-class model).

Justification: with a Haiku-class model at roughly $0.0008/1K input tokens and $0.004/1K output tokens, an average ticket of 4 turns × ~1K total tokens lands near $0.003. A $0.10 cap gives ~30× headroom for the long tail and is still a number you can defend to a CFO at 1M tickets/month ($100K/month worst case, vs ~$3K expected).

(c) Three escape hatches. (Any three of these are reasonable.)

NEEDS_HUMAN: missing_customer_data — the account lookup returned nothing or returned a customer with no order history; the agent cannot triage without context.
NEEDS_HUMAN: ambiguous_request — after one clarification attempt the ticket text still does not fit any of the four categories.
NEEDS_HUMAN: refund_over_threshold — the proposed resolution involves a refund or credit above a policy limit (e.g. $50); the agent must hand off rather than auto-approve.

Other reasonable answers: tool failure the LLM cannot interpret, emotional-language detection (frustrated / threatening tone), legal or compliance keywords detected, VIP customer tier.

Common mistake

Writing down only a turn cap and no cost cap. A pathologically large context window means a single turn can be much more expensive than the average turn — one 10×-context turn can blow your budget even though the turn count is fine. Cost-based caps catch the runaway-cost failure mode that turn caps miss. The two caps do different jobs and you need both. (A second common mistake: listing "the agent crashes" or "the runtime times out" as escape hatches. Those are failure modes, not escape hatches — an escape hatch is an intentional, structured signal the agent emits saying "I am stuck, escalate me".)

What you should take away

All three tasks point at the same underlying skill: distinguishing LLM-driven control flow from hard-coded control flow, then picking the cheapest planning style and the tightest budget that still lets the agent succeed. Tasks 1 and 2 are pattern recognition. Task 3 is the one you will do for real, every time you ship an agent — production agents need explicit numbers, not vibes.

Preview: Lesson 02

Lesson 02 turns these mental models into ~80 lines of Python. You will feel the four stop conditions in code — the natural stop_reason == "end_turn" is free, but the turn cap, cost cap, and user interrupt are three lines of Python you have to wire yourself. Same loop, no framework. Once you have built it once, every framework in Modules 2–5 will look like a wrapper over the thing you already understand.

← Back to homework · On to Lesson 02 →