🔄 The actual execution cycle

New here? O execution cycle it’s the sequence the agent repeats several times within a session: read the workflow step, choose a tool, run it, review the result, and decide what to do next. It isn’t a single step—it’s a loop (loop, repetition: the same sequence running over and over) that continues until the task is complete.

In module 1.1, you saw the kitchen analogy: recipe (workflow), cook (agent), utensils (tools). It was static there, like a photo of the finished dish. This module is the movie — the cook reading the next step, picking up the right knife, cutting, tasting the result, and only then turning the page. It’s this “read → decide → act → taste → repeat” that turns a static recipe into real work — a finished report, a sent newsletter, an organized batch of invoices.

Each complete loop iteration is called a iteration. A simple task takes 3 or 4; organizing a month's worth of receipts can take dozens — the agent decides on each pass whether it's done.

Caption: this timeline shows ONE iteration of the loop — one complete cycle. Step 5 points back to step 1 (not shown here) because the cycle starts over until the workflow is finished.

Each time the cycle starts over, the agent needs to know "where I am in the recipe." In a Claude Code session, this usually happens within a single conversation: the conversation history acts as short-term memory, remembering what has already been done. In a workflow saved to a file (which we’ll practice in module 1.5), the current step can be explicit in the text itself or inferred from what’s already on disk — for example, if the file "relatorio-semana.md" already exists, step 4 is complete.

New here? Context it’s everything the agent “sees” when making a decision: the conversation so far, the files it has already read, CLAUDE.md, and the results of tools it has already run. Think of context as the cook’s worktable—only what’s on it is available at that moment; an ingredient in a closed cabinet (a file never opened) simply doesn’t exist to the cook. This context has a cost, measured in tokens — chunks of text the model processes each turn. The more stuff "on the table," the more tokens are spent just looking at everything before deciding.

Example: in a “reply to customer emails” workflow, the agent reads the next email at each iteration (the “where am I”), decides whether to reply with a template or escalate to a human, executes, and observes whether the email was sent successfully. The “state” is simply how many emails have been processed.

This is the "smartest" part of the cycle: given the current step and the list of available tools, the agent chooses the one that best solves it. If the step is "sum by category," it may choose to run a calculation script instead of trying to add everything manually. If the step is "publish on the site," it chooses the deploy tool (covered in Track 4), not an email tool.

This choice depends directly on which tools have been made available to the agent — that’s why Tracks 2 (MCP) and 3 (Skills) in this course teach you how to add and connect tools: the clearer the menu of options, the better the choice.

Another example: in a “weekly sales report,” the step “add up revenue by salesperson” has two candidate tools — a script that adds it up, or manual formulas. A well-configured agent chooses the script, which is faster and deterministic — if it’s available. If not, it adapts, which brings us to the most common mistake.

After running it, the agent doesn’t blindly move on to the next step — it reads what the tool returned. A command can return an error, an empty file, a number outside the expected range, or exactly what it should. Reading the result triggers self-correction, covered in more depth in module 1.3.

Caption: the loop runs from left to right at each workflow step; the dotted return arrow shows self-correction — the agent repeating a step that didn’t go as expected.

"Observing" isn't optional or automatic — it's an active decision to stop and read what came back before continuing. In the newsletter example (module 1.5), after "send email" the agent checks whether it got "success" or an error code. With invoices, after moving a file it checks whether the file is actually in the folder — it doesn't assume it worked just because the command "ran without crashing".

This check has three possible outcomes: (1) it matches expectations, so move on; (2) there’s a clear error, so the agent tries to fix it or lets you know; or (3) the result is ambiguous — neither right nor clearly wrong — and that’s where the deeper judgment covered in module 1.3 on self-correction comes in.

1. Leia a pasta atual e liste os arquivos .txt que existem.
2. Para cada arquivo .txt encontrado, conte quantas linhas ele tem.
3. Crie um arquivo resumo.md com o nome de cada arquivo e sua contagem de linhas.
4. Confira se resumo.md foi criado e se o número de linhas listadas bate com os arquivos originais.

The cycle repeats step by step until the workflow is finished. On each pass, the agent also decides whether it needs to repeat the current step (for example, if a command failed for a temporary reason) or stop and ask you for help (for example, if a password only you have is missing). This second case—stopping and letting you know—is just as important as execution: a good agent knows when not to proceed on its own.

New here? This decision point — deciding whether to continue, repeat, or stop based on the observed result — is what we call reasoning of the agent. Without it, the cycle would just be a blind sequence of commands, unable to react to surprises.

In the email example: a healthy loop retries “send” only if the failure is temporary, and stops after 2-3 attempts, escalating to you. A stuck loop repeats the same error dozens of times without getting a new result.

The cycle ends in one of three ways: (1) the workflow reached the last step and everything checked out—success; (2) the agent identified that something only you can provide is missing and stopped to ask; or (3) it got stuck repeating and it’s time for you to step in. Recognizing which of the three is happening is the central topic of module 1.4.

Let’s reinforce the difference between endings 2 and 3 — they look similar at first, and both end without the finished result. In ending 2 (pause for a decision), the agent knows what’s missing and asks a specific question, such as "I need the Gmail API key — where can I find it?" In ending 3 (stuck), it doesn’t know what else to try and repeats something that has already proven not to work — the solution is for you to adjust the workflow, not answer.

In the invoice example: success means all invoices are in the right folders with a summary by category; pausing for a decision means the agent finds an invoice with no clear category and asks where it belongs; getting stuck means repeatedly trying to open a corrupted PDF without success — time for you to inspect the file manually.