Practice — Approval, Memory, and Stop Conditions

Let's think about this for a second

This one steps up a level from the first practice lesson — you'll have to weigh risky actions, secret handling, and retry loops all at once. In a real project, it's never just "can this tool be called?" You have to decide, simultaneously, whether it should be called, when a human needs to step in, and how many times to retry if it fails. Each task gives you a scenario and asks you to write your own rule — don't just answer yes/no, write down the reasoning behind it. Get through this round and you'll be able to take on projects like the build-a-study-helper-agent lesson with real confidence.

Exercises

Task 1 (Approval): Say the agent has decided to call a "delete old notes" tool — write down what info the preview should show (file count, a sample list, etc.), and explain why there shouldn't be an "Allow all" button. Task 2 (Memory): If a Study Helper Agent wants to save a student's email address in memory, set three rules for what should be stored versus what should be masked in the logs. Task 3 (Plan-then-act + Stop): For the goal "Research topic X on the web and write a report," rough out a 4-step plan, and decide how many retries to allow and which error types should stop everything immediately and hand off to a human. Task 4 (Debug): In the code snippet below, the retry loop keeps retrying every error with no limit — find the bug and fix it.

Can you spell out a preview + confirm step for every risky tool call?
Can you separate data worth keeping in memory from data that should be masked in logs?
Can you fix the retry limit and hard-stop condition in the code?

Code Example

javascript

// Task 4 — ဒီ retry loop ထဲက bug ကို ရှာပြီး ပြင်ပါ
async function callToolWithRetry(toolName, input) {
  while (true) {
    try {
      return await callTool(toolName, input);
    } catch (err) {
      console.log("Tool failed, retrying...", err.message);
      // BUG: retry count မရှိဘူး၊ error type ကိုလည်း မခွဲခြားထားဘူး
      // TODO 1: retry count လျှော့ပြီး ကန့်သတ် (ဥပမာ- max 3 ကြိမ်)
      // TODO 2: auth/permission error ဆို ချက်ချင်းရပ်ပြီး human ဆီ ပို့ပါ
      // TODO 3: retry တစ်ခါချင်းစီကြားမှာ backoff (delay) ထည့်ပါ
    }
  }
}

You should see

In five minutes, you'll be able to draft an approval preview list, a memory/log split rule, a 4-step plan with retry/stop rules, and a fixed version of the retry loop code.

5-minute try

Do Task 3 with a 5-minute timer, then ask yourself "why" one more time about whatever retry limit you picked — if your answer is just "it felt right," go back and weigh it against the cost/time trade-off instead.

A quick word of caution

Before putting Task 4's retry code into production for real, account for rate limits and cost — too many retries can drive up your API bill and overload other services.