😶 The problem of amnesia
Remember module 6.2: a scheduled task opens a session new with each trigger — a new employee every day, with no memory of the day before. This is great for reliability (no one carries a misunderstanding from one run to the next), but creates a real problem: what if the task need know what it’s already done? "Send a summary of only the new stories since yesterday" doesn’t work if the agent doesn’t know what it sent yesterday.
The obvious temptation is to ask the agent to “remember” everything—but it doesn’t retain anything between runs on its own; each session starts and ends blank. The solution isn’t to give the session memory (that’s the loop from module 6.3, and it expires quickly)—it’s to give memory to the disk: a small file that persists from one run to the next, which the task reads at the start and rewrites at the end.
💡 Main Concept
- •A session doesn't remember on its own — it needs a place outside itself to store what's essential.
- •This is a simple file on disk, not the agent’s "mind."
📄 The status file
New here? One status file is a small text file dedicated to a single scheduled task, storing only what matters for next time: the last date checked, the last item processed, a counter — never the entire history. It's the task's "record card," not its diary.
In practice: at the start of each run, the scheduled task opens this file and reads what's in it. It decides what to do based on that. At the end, rewrites the entire file with the updated information — overwriting it, not adding to what was already there. That’s why it never grows: today’s content replaces yesterday’s.
🔍 Inside
- What to store: only the minimum needed to decide the next step (a date, an ID, a number).
- What NOT to store: the complete text of everything already done, the history of every run, things "that might be useful someday".
ultima_verificacao: 2026-08-04T07:00:00
ultimo_id_processado: 4821
proxima_acao: nenhuma pendencia📈 Why not an endless log
The other temptation is to go adding one line per run — a log (chronological record of everything that happened). It seems safer (“nothing gets lost”), but in practice it becomes a problem: the file grows nonstop, becomes expensive and slow to reread every time it runs, and after a few months nobody—not even the agent—can find what matters among thousands of lines.
Caption: the pink line keeps rising — the log gains a line with every run and never gets shorter. The cyan line stays flat and low — the status file is rewritten, not appended to, so it always stays the same small size.
✓ Status file
- ✓Size always stays small—rewritten, not added up
- ✓Fast and inexpensive to read on every run
- ✓Easy for even you to understand at a glance
✗ Endless log
- ✗Grows forever, with no natural limit
- ✗Each run gets slower and more expensive to reread
- ✗After months, it becomes noise — no one can find what matters
🔄 The status file cycle, step by step
This is the module’s central diagram: how one run connects to the next, with no live session and no log — just a small file passing the baton forward.
Caption: six steps in a circle—start, read the status, decide, execute, rewrite the status, finish—and the dotted arrow shows the next scheduled run returning to step 1, now reading the status the previous run left ready.
🔍 Inside
The step most people forget is step 5 (rewrite). If the task runs but doesn’t update the status, the next run will read old information and repeat work that’s already been done — it’s the most common error in topic 6.
⚙️ Build your learning routine
Let’s create a scheduled task that uses exactly the cycle from topic 4. Ask the agent to configure
both parts: the task itself and the status file it reads and rewrites. Adjust anything between <isto voce troca>.
Create a scheduled task that reads a status file at the start, makes a decision based on it, runs, and rewrites the status at the end — with no ever-growing log.
Crie uma tarefa agendada que roda <todo dia às 7h> e faz o seguinte:
1. Leia o arquivo <caminho/do/status.txt>. Se ele ainda não existir, crie um
com valores iniciais vazios.
2. Com base no que estiver nesse arquivo, decida o que precisa ser feito
agora: <descreva a regra de decisão, ex: "só processar itens novos
desde a última_verificacao">.
3. Execute <a tarefa em si, ex: "verificar novidades e me enviar um
resumo">.
4. No final, reescreva o arquivo <status.txt> inteiro (não acrescente
linhas) com os valores atualizados: data desta execução e o que for
necessário pra próxima decisão.
Nunca deixe o arquivo de status crescer — ele deve ter sempre o mesmo
tamanho pequeno, com só os campos essenciais.How to verify: after the first run, open the status file and check whether the values changed. Run (or wait for) the next run and confirm that it acted differently from the first one — a sign that it actually read and used what the previous run wrote.
💡 Practical Tip
Start with a very simple file format (a few lines, like “key: value”). An overly complicated format is another way to hide a bug—the simpler the status, the easier it is for you to check that it’s correct without relying only on the agent.
⚠️ Common errors
Three ways to ruin a routine that learns—all easy to avoid once you know what to look for:
Caption: each bar represents the work done in that run. They get shorter because the routine, guided by status, focuses only on what’s new — it doesn’t reprocess what it already did.
✗ Don't do this
- ✗Forget to rewrite the status at the end (the task never "moves forward")
- ✗Let the file grow (turn into a hidden log inside the “status”)
- ✗Saving too much information “just in case”
✓ Do
- ✓Make rewriting the status the final required step of the task
- ✓Overwrite the entire file, never append lines
- ✓Save only what you need to make the next decision
✅ Checklist before publishing the routine
- •Does the task read the status file BEFORE deciding what to do?
- •Does it always rewrite (not append to) the file at the end?
- •Does the file store only the essentials, not a complete history?
Quick check (optional): Why doesn’t the status file grow over time?