🔁 The operational loop: the disciplined brain
This is the course’s key module. A disciplined agent doesn’t rush to the keyboard—it ground yourself in reality, reason, act in batches, stop to read what came back and only then decides the next step. This cycle has a name: GROUND → REASON → ACT → OBSERVE → RE-EVALUATE → VERIFY → NARRATE. Here, step by step, you’ll understand the brain that separates an agent that thinks from one that only “gropes around quickly.”
Detailed content
Why a loop, not a trick
The internet is full of "prompt tricks": the magic phrase, the latest jailbreak, the template that "turns AI into a genius." They work for an afternoon and break the next day. What really changes the game isn’t a trick—it’s a work habit. A cycle the agent runs on every difficult turn, always the same, always in order. That’s what separates an agent that think of one that only acts fast.
🧠 The idea in one sentence
O Operational loop is the agent’s disciplined brain: a seven-step cycle — ground yourself, reason, act, observe, reassess, verify, narrate — run every non-trivial turn It isn’t a phrase you paste in; it’s a way of working you establish.
The sentence that sums it all up: "speed comes from doing the right thing once, not from skipping the reasoning." A trick gives you a shortcut that sometimes works; the loop gives you a method that always checks.
✗ The trick (fragile)
- ✗Depends on a specific phrase that “unlocks” the model
- ✗Works in one case and breaks in a neighboring case
- ✗Rush to the keyboard: act without grounding or checking
- ✗When something goes wrong, you don’t know why—it was magic
✓ The loop (robust)
- ✓It’s a cycle of habits, the same for every task
- ✓Generalizes: works for a case you didn’t anticipate
- ✓Ground first, act next, check every time
- ✓When something fails, you know which step to look at
Why this is the key module
All the blocks in Track 2 build how the agent speaks. This builds how the agent works. The block <loop_operacional> is what brings an ordinary agent closest to cutting-edge discipline — it’s the secret sauce all by itself. Master this, and the rest becomes fine-tuning.
GROUND — anchor in the actual state
The cycle opens with the simplest and most overlooked rule: never change what you don’t understand. Before proposing a solution, before editing a single line, the agent establishes the real state of the world. It runs the git status, do the grep, list the directory, read the file that matters. Grounding means replacing "it’s probably like this" with "I just saw it".
🌍 Recognition before mutation
Every task starts with establish what actually exists, not by imagining what might exist. The disciplined agent starts with a git status, a precise grep and a read of the only file that matters — before from writing a single character.
There’s a second grain of sand here: read the exact section right before changing it. Context from five steps ago is stale. A fresh reread prevents a mismatched edit, a duplicate block, and a change that had already been made.
✓ Ground it for real
- ✓Check the state (git status, list dir) before proposing
- ✓Runs a precise grep to find the thing
- ✓Read the file that matters in this session
- ✓Reread the exact lines just before editing them
✗ Feel around in the dark
- ✗Proposes a fix based on an assumption
- ✗Edits a file without having seen its current contents
- ✗Edits "from memory" based on what the file probably contains
- ✗Uses old context and applies a patch that doesn't fit
How it sounds in the system prompt
"Establish the actual state before changing anything: git status, grep, list the directory, read the file that matters. Never change what you don't understand." One line — and it changes the agent's entire stance, from "guess and run" to "look and act".
REASON + ACT — think first, act in batches
Once the groundwork is laid, two steps follow closely. REASON: before the first tool, state the goal, hypothesis, and plan—even if only in one or two lines. Naming what you expect to find changes what you do next. ACT: take the next deliberate step and group what’s independent — but never pretend something with dependencies is parallel.
REASON — objective + hypothesis + plan, before the 1st tool
Reasoning isn’t an extra cost. It’s the work.
"The footer appears twice. It’s probably duplicated in the layout. I’ll grep for the footer import and then read the layout." Two sentences, and the agent has already stopped firing tools before knowing what it’s testing.
ACT — deliberate step, batches of independent tasks
Use leverage: group similar tasks, parallelize independent ones.
Read all three files at once. Run the independent checks in parallel. Serial execution of independent work is wasted wall-clock time. The caveat: if step B needs the output of step A, they're not parallel—pretending they are leads to canceled work and confusion.
The anti-pattern to avoid
Triggering a tool call before saying, even just to yourself, what you're testing. An agent that acts without reasoning isn't being fast—it's piling up steps it'll have to undo.
OBSERVE + RE-EVALUATE — the step everyone skips
This is the heart of the module, and the habit that more is ignored. After a tool returns, stop and read what came back — really. Then decide the next step based on what the result actually showed, not on the plan you had before you had the data. In the image above, it’s the cyan handle: ACT → OBSERVE → RE-EVALUATE, repeated in a loop until the goal is reached.
👁️ The plan is a draft; the result is the truth
The observe-then-decide loop is the difference between an agent that thinks and one that just acts quickly. Run it after every cycle. There’s only one rule governing this step: update the plan based on the result — not the result based on the plan.
It looks like this: a search returns three results you didn’t expect. You pause, review the theory, and adjust the next action — instead of continuing to force the old plan downhill.
✓ Observe and re-evaluate
- ✓Stop and read the entire response before the next step
- ✓Decide based on what the result showed, not the plan
- ✓When the data is surprising, revise the theory on the spot
- ✓Repeat ACT..RE-EVALUATE until the goal is reached
✗ Skip the step
- ✗Executes a preplanned sequence as if the results couldn’t change it
- ✗Glance at the output and immediately trigger the next action
- ✗Fit the result into the plan instead of the other way around
- ✗Keeps pushing even when the data contradicts the theory
Why this handle is the canonical piece
It’s the one habit that, when missing, makes “good plans turn into wrong results.” Most bad agents don’t fail because they reason poorly—they fail because they not read what came back and follow the old script. Observing again and reassessing is what closes that gap.
VERIFY + NARRATE — real check and accurate report
The last two steps close the loop honestly. VERIFY: every edit is a hypothesis; a check that passes is the evidence. Run the test, build, or lint real of the project — not a ls not one echo. NARRATE: say what you’ll do and why, confirm phase transitions. Don’t disappear for twenty calls and show up only at the end.
✅ From “seems right” to “tests pass, here's the output”
Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging.
In EN: report results accurately—if tests failed, say so and show the output; if you skipped a step, say so; if something is done and verified, state it plainly. "It probably works" isn’t done; "tests pass, here’s the output" is done.
⚠️ Here, do better than the source
The model this mindset was distilled from verifies in a inconsistent. You should verify always. Two anti-patterns to cut:
- ✗Declare a change ready because it "seems right," or because an unrelated command exited with code zero
- ✗Disappear for twenty tool calls and reappear only at the end, without narrating the transitions
Trust is built through accurate reporting
Not with an optimistic account. Narrating what you’re doing—including the housekeeping, like “I’m creating a branch” or “I’m grounding this”—is what keeps a long-running task auditable and lets the human correct course early.
Calibrate effort to the task
One last discipline, and it keeps the loop from turning into bureaucracy: scale the effort to the task. A one-line fix doesn’t need a war room. A fifty-step migration without a plan or tracking is how work derails without anyone noticing. The cycle is always the same; the weight from each step is what changes with the size of the task.
🪶 Light task — lean loop
a one-line fix, a direct answer
- •Get grounded quickly: one grep, one read
- •One-line reasoning is enough
- •Act, verify with a real check, report
- •Without a formal plan or task list
🏗️ Heavy task — loop with a plan
a migration, a multi-step build
- •Short phased plan, with approval
- •Living task list, updated along the way
- •Return to the plan at each phase boundary
- •Narrate the transitions — keep them auditable
<loop_operacional> Rode este ciclo a cada turno não-trivial. Escale o esforço à tarefa — um fix de uma linha não precisa de sala de guerra. GROUND (aterrar) Estabeleça o estado real antes de mudar nada: git status, grep, listar dir, ler o arquivo que importa. Nunca mude o que você não entendeu. REASON (raciocinar) Antes da 1ª ferramenta, diga objetivo + hipótese + plano (mesmo 1-2 linhas). Nomear o que você espera muda o que você faz. ACT (agir) Dê o próximo passo deliberado. Agrupe o que é independente; não finja paralelo o que tem dependência. OBSERVE (observar) Pare e LEIA o que voltou. De verdade. Pular este passo é como bons planos viram resultados errados. RE-EVALUATE Atualize o plano a partir do resultado, não o contrário. O plano é rascunho; o resultado é a verdade. (Repita ACT..RE-EVALUATE até a meta.) VERIFY (verificar) Toda edição é hipótese; um check que passa é a evidência. Rode o teste/build/lint REAL do projeto, não um `ls`/`echo`. Verifique SEMPRE — aqui seja melhor que a fonte. NARRATE (narrar) Diga o que vai fazer e por quê; confirme transições de fase. Não suma por 20 chamadas e apareça só no fim. </loop_operacional>
🛠️ Hands-on: your deliverable
Before moving on, install the loop in one of your agents. In 15 minutes, you’ll have an agent that thinks instead of fumbling around.
- 1 Take an agent of yours that performs tasks in steps (uses tools, edits files). Paste the block <loop_operacional> in the system prompt, exactly as above.
- 2 Give it a nontrivial task and see whether it ground yourself before acting: does it check the state (list, read) before editing—or just start changing things?
- 3 If the focus shifted to cyan handle: after each tool, does it stop and read the result, or push on with the old plan? This is the step that reveals the most about its discipline.
- 4 At the end, check the VERIFY + NARRATE: did it run a real check (not a ls) and reported plainly? Note the weakest step — that’s where you reinforce the line.
📝 Module Summary
- ✓O Operational loop is a work habit, not a trick: the agent’s disciplined brain
- ✓GROUND: ground yourself in the actual state and reread the exact area before changing anything
- ✓REASON + ACT: state the goal/hypothesis/plan before the first tool; group independent work, don't pretend it's parallel
- ✓OBSERVE + RE-EVALUATE: the cyan handle—read what came back and update the plan based on it. The step everyone skips
- ✓VERIFY + NARRATE: a real check (not a ls) and faithful reporting — "tests pass, here’s the output" means it’s done
- ✓Calibrate the effort to the task: same cycle, different weight — a one-line fix doesn’t need a war room
➡️ Next Module
2.6 — 🛠️ Building a Skill and an Agent. You have the disciplined brain in your pocket. Now let’s give it hands and memory: build a reusable skill and a complete agent, with the operational loop running inside.