📣 Why giving notice matters
New here? One notification, in the context of automation, is any message the task sends you to tell you what it did—finished successfully, found a problem, or needs your attention. It’s the digital equivalent of an employee knocking on your door and saying, “I finished what you asked me to do. Take a look at the result.”
A scheduled task runs on its own, usually while you're doing something else — sleeping, in a meeting, away from your computer. Without a notification, you'll only find out something went wrong when you notice the problem yourself, which could take days. With a notification, you'll know right away — and can act quickly.
💡 Main Concept
Unsupervised task + no notification = a problem that only shows up when it’s too late.
- •A quiet success still deserves a record—you want to confirm that it ran.
- •An unreported failure is the worst-case scenario: the problem accumulates without anyone knowing.
📬 Notification methods and when to use each
There’s no single “right” way to notify you — it depends on how urgent the information is and where you tend to pay attention. The three most common options:
Good for daily/weekly summaries that aren’t urgent — you read them when you open your inbox. Ideal for "routine that finished normally."
Message (phone, chat, sound)
Good for urgent things — an error that needs attention now, not a few hours from now. It reaches you wherever you are, not just your inbox.
Summary file (log)
Good when you don’t need to be notified right away but want to check later — a file that accumulates "ran at 7 a.m., processed 12 items, no errors."
💡 Practical Tip
Start simple: a summary file already covers many cases. Move to email or messaging only when the task involves something that requires you to act quickly if it goes wrong.
🚫 The central point of this track: never grant delete permission
New here? Permission, here, is what you authorize the agent to do on its own—as covered in module 0.6. That matters even more for a scheduled task: since it runs without anyone watching, any risky permission can become a risk that goes unnoticed for days.
Caption: inside the cyan circle is what the task CAN do on its own — read files and write to a specific place. Outside, crossed out in red, is “delete” — a permission a task without human supervision should NEVER receive.
⚠️ Attention—the most costly mistake on this learning path
Imagine a task set up to “clean up old files” running on its own every day, with no one reviewing it. A poorly defined criterion — or a simple bug in the script — could delete something important, and since no one is watching, you only find out days later, when it’s too late to recover it. That’s why: automatic task, without direct human supervision, NEVER gets permission to delete. Full stop.
🔧 Setting up restrictive permissions in practice
The practical rule is simple: give the minimum required for the task to do the work, and nothing more. In most cases, this means reading files (to look up information) and, at most, writing to a specific, well-defined location (an output folder, a log file). More consequential actions — deleting, overwriting outside that folder, running commands with broad effects — are out of scope by default.
✓ Secure permission
- ✓Read files from a specific folder
- ✓Write/create files in a dedicated output folder
- ✓Send a notification (email, message)
✗ Risky permission
- ✗Delete files or folders, even if they’re “old”
- ✗Overwrite any file outside the designated output folder
- ✗Run generic commands without scope restrictions
🔍 Inside
- Scope: restrict the ACTION (read/write) and the LOCATION (this folder only) — both axes together.
- Safe default: if you’re unsure whether a permission is safe, don’t grant it—start restrictive and expand later, with supervision.
⌨️ Copy-run: scheduled task with notifications and restrictive permissions
Objective: ask the agent to configure (or review) an existing scheduled task by adding a result notification and specifying restrictive permissions — without deleting anything.
Quero revisar a tarefa agendada "<nome da tarefa, ex: backup diário de notas>" para deixá-la segura para rodar sem supervisão. 1. Liste exatamente quais permissões essa tarefa tem hoje (ler, escrever, apagar, rodar comandos). 2. Restrinja para o mínimo necessário: leitura da pasta "<pasta de origem>" e escrita apenas em "<pasta de saída específica>". CONFIRME explicitamente que NÃO há permissão de apagar/deletar em lugar nenhum. 3. Configure uma notificação ao final da execução: "<escolha: e-mail / mensagem / arquivo de log>" com um resumo do que foi feito (sucesso, quantidade processada, ou erro encontrado). 4. Me mostre um resumo final: o que a tarefa PODE fazer, o que está BLOQUEADO, e como ela avisa quando termina.
How to verify: ask the agent to list the granted permissions in writing and check, item by item, that "erase/delete" doesn't appear in any of them; run the task once and confirm that the notification actually arrived.
✅ Final safety checklist before letting it run on its own
Before enabling any time-based automation—a scheduled task or loop—and leaving it running unattended, go through this list. It brings together what the entire track has taught about time, determinism, and safety.
Is the task repetitive and well-defined?
If so, consider turning it into a deterministic script (module 6.5)—it’s faster and cheaper.
Is a notification configured?
You need to know when it finishes, successfully or with an error — without waiting to notice on your own.
Is permission to delete excluded?
Confirm in writing, item by item—this is the one you must not skip.
Have you tested it manually at least once?
Before leaving it to run on its own, run it yourself once and check the result.
✓ Ready to run on its own
- ✓Minimum permissions, no deleting, clearly defined scope
- ✓Notification tested and working
- ✓Ran it manually at least once successfully
✗ Don't leave it running on its own yet
- ✗You don’t check the exact permissions granted
- ✗Without any way to notify you when it finishes or fails
- ✗Never ran it manually to check its behavior
Quick check (optional): What permission should an unsupervised automated task NEVER receive?