🧩 Why break the workflow into small tasks
New here? One task (task) is an isolated piece of work inside an automation — for example, “find the new email” is one task, “write to the database” is another. Think of an assembly line: if the painting step fails, you don’t take apart the whole car and start over from scratch — you just fix the paint job.
On your laptop, when a script breaks halfway through, you see the error on screen, press a key, and run it again. In the cloud, no one is watching. If the entire automation is “one block” and any part fails, either everything runs again from the beginning (wasting time and sometimes repeating an action that already succeeded), or everything gets stuck and waits for you to notice. Neither is good.
💡 Main Concept
Good automation consists of small, independent tasks. If one fails, only that one repeats—the rest of the work that already succeeded stays intact.
- •Single block: if anything fails, redo everything (or block everything).
- •Small tasks: if one fails, only that one retries — the others don’t even notice.
🔁 What a retry looks like in practice
New here? Retry (in English, retry) is the platform trying again on its own to complete a task that failed—you don’t need to press any buttons. It’s like calling someone back when the call drops: you don’t give up after the first try; you try again in a few seconds.
Most automation failures aren’t cases where "everything is broken" — they’re temporary: the external service was overloaded for two seconds, the internet hiccupped, or the server took a little longer than expected. An automatic retry resolves most of these issues without anyone noticing.
Caption: an isolated failure is almost always resolved on the 2nd or 3rd attempt, without human intervention. You only get an alert when the attempts run out.
🔍 Inside
- Attempts with increasing wait times: the platform doesn’t retry right away — it waits a little longer after each attempt to give the problem time to pass.
- Attempt limit: after a set number (usually 3), the platform gives up and marks the task as failed, notifying you.
📥📤 Fetching data isn’t writing data
Here’s the real reason to break work into small tasks: search a piece of data (read an email, look up a spreadsheet) can be repeated as often as needed without any problem—reading it again changes nothing. But record data (sending an email, creating a charge, saving a new record) is different: if the retry repeats this part, you could end up sending the email twice, or duplicating the same record in the database.
That’s why the practical rule is: separate “fetching” from “writing” into different tasks. If the writing task fails after the fetching task has already succeeded, the retry repeats only the write — without fetching (and risking duplicating) the data again.
✓ Tasks kept separate
- ✓Task 1 fetches the new request. Task 2 records the confirmation. If 2 fails, only it retries.
- ✓Repeating the recording is safe because it already knows exactly which request to confirm.
- ✓No duplicate emails, no duplicate charges.
✗ Everything in a single task
- ✗A single task fetches the request and records the confirmation in the same step.
- ✗If it fails after saving (for example, while recording that it finished), the retry repeats everything—including the save that already happened.
- ✗Result: duplicate email or charge, with no one noticing right away.
💡 Practical Tip
When requesting an automation from Claude Code, explicitly say, “separate the search step from the write step, in different tasks.” It’s a simple phrase that prevents many duplication problems.
🚦 The queue: who waits their turn
New here? One queue is a list of tasks waiting their turn to run, like a bank line: each one is handled in order, one at a time (or a few in parallel, depending on the setup), without needing you to watch. If 50 requests arrive at once, they enter the queue and are processed without freezing the whole system.
The queue works together with retries: when a task fails, instead of disappearing, it can go back to the end of the queue to try again later. Together, these mechanisms give an automation the resilience to run 24 hours a day without someone having to keep nudging it.
The event happens
A new request arrives, a scheduled time comes around—the task enters the queue.
The platform takes one at a time
Without overloading the system—if 50 arrive at once, it processes them at the pace it can handle.
It worked, remove it from the queue
It's recorded as complete in the execution dashboard (module 4.7).
If it fails, put it back in the queue (with a retry)
Wait a bit, then try again — up to the topic 2 attempt limit.
📋 Why plan mode matters more here
Back in module 0.5, you learned the plan mode: asking Claude Code to show you the steps before acting, so you can review them before any real changes are made. In local tasks, a bug leaves behind a messy file that you can fix in seconds. In production, a bug in an automation that runs on its own can lead to duplicate data or a real action done wrong — an email sent twice to a customer, a duplicate charge on someone's card.
So, when asking the agent to write or change an automation that will run in production — especially if it writes data or sends things out — always use plan mode. Read the plan carefully, paying special attention to the question: “Does this separate fetching from writing? Is it safe to retry if it fails midway?”
✓ Before publishing an automation
- ✓Asked for the plan and read it before approving the change
- ✓Confirmed that searching and writing are in separate tasks
- ✓Tested in dev (module 4.3) before touching production
✗ Publishing on impulse
- ✗Accepted the change without looking at the plan
- ✗Didn’t ask what happens if the task fails partway through
- ✗Went straight to production without going through dev
⚠️ Attention
Reinforcing the “New here?” pattern: idempotency is the technical term for a task that can be repeated several times without changing the result (repeating "search" is idempotent; repeating "write" may not be). You don't need to memorize the term — just remember the practical rule: separate searching from writing.
✅ Checklist before publishing an automation
Before writing the actual code (that comes in module 4.6, the Build module of this track), it helps to have a question ready to ask Claude Code—in plain text, without needing to understand programming.
Objective: ask the agent to review the automation design before writing the code, applying what this module taught.
Antes de escrever o código desta automação, me mostre o plano dividido em
tarefas pequenas (tasks). Para cada task, diga: (1) ela só busca dado, ou
também grava/envia algo pra fora? (2) se ela falhar no meio e a plataforma
tentar de novo automaticamente, existe risco de duplicar um e-mail, uma
cobrança ou um registro? Se existir, ajuste o plano separando busca de
gravação antes de eu aprovar.How to verify: the answer must list separate tasks with clear names (e.g., “find new orders,” “record confirmation”) and explain, for each task that records something, why it’s safe to repeat without creating duplicates. If the answer only says “yes, everything looks good” without explaining why, ask again for more detail.
🎯 Main Concept
- •Small tasks → isolated failure → small mess.
- •Retry handles “try again”; separating fetch from write handles “no duplicates.”
- •A queue ensures nothing gets lost, even when many things arrive at once.
Quick check (optional): Why separate “fetch data” from “write data” into different tasks?