💭 in your head · nothing to type
In u3 you built a URL → insights prompt and ran it by hand. In u4 you laid out the ladder: conditions, a schedule, notifications.
Today we climb two rungs at once: a condition and a schedule. Think of where your "read it later" links pile up. Bookmarks, saved messages, open tabs?
How many of them did you actually get through last week?
💭 in your head · nothing to type
Picture a morning mail conveyor: the belt moves by itself overnight, and a finished stack of digests waits at the end.
Which decision should the conveyor be able to make without you?
Trigger: schedule, every day at 8:00
Input: inbox.txt — links you dropped in during the day
Condition: link already in done.txt → skip it
Action: the agent reads the page and writes a breakdown per prompt.md
Output: digest-YYYY-MM-DD.md, the link → done.txt
You add a link to inbox.txt as one line. In the morning a finished file is waiting for you.
The script will run every day over the same inbox.txt. Without a condition it would re-process every old link each morning. That is exactly the u1 case: duplicates and hitting rate limits.
done.txt is the pipeline's memory of what is already done. A repeat run changes nothing and spends no quota. This property has a name: idempotency.
In module 08 you will see it in a real production pipeline. There an email gets a label after processing, so it is never picked up twice (08, "Orchestration: the Gmail agent as a case"). Your idea is the same, only a line in a file replaces the label.
A second rule comes from the same place: a link goes into done.txt only after a successful run. If a run fails, the link stays in the queue and the script retries tomorrow.