🕵️ The watchman making the rounds
New here? One loop (pronounced "loop", the English word for "laço") is a session — an ongoing conversation with the agent, open and active — repeating a cycle: checks something, decides whether it needs to act, acts if needed, waits a bit, and checks again. Think of a night watch making the rounds: it passes through the same checkpoint every hour, but remembers the previous round — if it saw the light on at 10 p.m. and now it's off, it knows something changed. It isn't replaced by a new guard on every round.
This is very different from the scheduled task in module 6.2, which is the opposite: there, each run is a new employee that arrives, reads the instruction, does the work, and leaves without remembering anything—because it starts a new session each time it’s triggered. The loop keeps the same session from beginning to end, and that’s exactly the live memory that makes it useful for tracking something in progress.
Caption: the loop runs through four steps — check, decide, act, wait — then starts over on its own. The entire session has a time limit, though: after ~3 days without intervention, it expires and the cycle stops.
💡 Main Concept
- •A scheduled task = a new worker on each run, with no memory between runs.
- •Loop = the same watchman on the same patrol, remembering what they saw on the previous round.
📍 Where a loop runs
The scheduled task from module 6.2 lives inside a desktop app — a program with a window and icon, installed on your computer, separate from the terminal. The loop is more flexible: it runs anywhere you can open a session with the agent and leave it open.
💻 Terminal
New here? O terminal it’s the text box where you give commands directly to the computer (covered in module 0.2). You open a session in it and ask the agent to “keep checking X”; the window needs to stay open.
🧩 VS Code
Inside the editor, with the agent extension open in a side tab — useful when the loop is following something related to code you’re editing live.
🖥️ Desktop app
The same app that hosts the scheduled task can also keep a loop session open — the difference isn’t the program, it’s the kind of task you gave it.
🔍 Inside
What changes between these places is just convenience—opening and closing the window, viewing the history. The loop’s behavior (check, decide, act, wait) is the same in any of them.
⏳ Why it expires in ~3 days
Here’s the cost of live memory: a loop session expires on its own after about 3 days, and stops immediately if you close the window where it was running. It’s not a bug — it’s the tradeoff that makes this format work. Keeping a session open with memory has a cost (it needs to keep “remembering” everything it has seen); that’s why the format is designed to last days, not months.
| Scheduled task | Loop | |
|---|---|---|
| Memory | new session on each run | keeps context in the same session |
| Duration | undefined (daily, weekly, monthly) | expires in ~3 days |
| If the PC shut down | recovers lost runs | the loop dies if the session closes |
Caption: ~3 days isn’t a visible alarm — it’s the session’s actual limit. If the subject you’re tracking hasn’t ended within that window, you need to reopen a new loop (or consider whether the case really calls for a scheduled task).
💡 Practical Tip
Treat the loop like a flashlight, not a fixed post: great for lighting up a short stretch of the path, poor as a permanent solution. If you find yourself reopening the same loop every week, that’s a sign the right answer was a scheduled task from the start.
🎯 Real-world use cases
The loop shines when the task has a beginning, middle, and end next — days, not months — and you want someone to keep an eye on it while you do something else. Three concrete examples:
Track a deploy in progress
You published a new version and want to know as soon as it finishes uploading (or if something fails) — without checking the dashboard every two minutes.
Monitor a price
A product you want to buy as soon as the price drops below a certain amount—the loop checks from time to time and lets you know when the time is right, within a window of a few days.
Keeping an eye on a task queue
A batch process (rendering videos, processing images) that will take a few hours—the loop checks its progress and lets you know when it finishes or gets stuck.
✓ Good fit for the loop
- ✓The subject has a short, visible deadline (hours to a few days)
- ✓You will leave the machine/session running during this period
- ✓What matters is reacting quickly to a change, not repeating it forever
✗ Poor fit for the loop
- ✗It’s a routine that repeats every day/week indefinitely
- ✗You need it to survive computer restarts
- ✗No one will be around to reopen the session after 3 days
⚙️ Build your first loop
Enough theory—open a session with the agent (terminal, VS Code, or the desktop app, whichever you prefer) and paste
the prompt below. It creates a simple loop: checks a status file every 30 minutes and lets you know
if it changes. Adjust whatever is between <isto voce troca>.
Create a loop that watches a status file and notifies you when it changes — the basic pattern behind nearly every monitoring loop.
A cada 30 minutos, verifique se o arquivo <caminho/do/arquivo-status.txt> mudou
desde a última vez que você olhou. Se mudou, me avise com um resumo curto do
que mudou. Se não mudou, não faça nada e espere o próximo ciclo. Continue
repetindo isso até eu te pedir para parar, ou até esta sessão expirar
naturalmente. Objetivo: acompanhar <o que você está monitorando aqui>.How to verify: change the status file manually (or let another process change it) and check whether, in the next 30-minute cycle, the agent notified you in the same session—without you having to ask again.
🔍 Inside
The interval (“every 30 minutes”) and the condition (“if it changed”) are the two parameters you’ll adjust most often. Short intervals use more tokens (the unit that measures processing cost, covered in module 0.1); long intervals may cause you to miss the right time to act.
🚫 When the loop is NOT the right tool
The most common mistake people make after discovering loops is trying to turn one into a disguised scheduled task— leaving it running “forever” and hoping the session doesn’t die. It breaks as soon as you close the window or go past ~3 days, and you lose track of it without warning.
✓ Use a loop
- ✓"Stay with it until it’s done" — short deadline, session stays open
- ✓Your machine is on, and you’ll monitor it closely
✗ Use a scheduled task
- ✗"Every day/every week, do X" — there’s no end date
- ✗Needs to survive restarts and your absence
✅ Final decision checklist
- •Is this expected to end within a few days? If so → loop.
- •Does this need to keep running even if I forget about it? If so → scheduled task (module 6.2).
- •Am I going to leave the session open all the time? If not → it’s scheduled, not a loop.
Quick check (optional): what makes a loop session die sooner than expected?