🤖 How to read this module
The big shift is to stop thinking in terms of "steps I trigger" and start thinking in terms of "a result I delegate to someone who can reason." The three types of agents differ only in trigger — you (local), the clock (scheduled/cron), or an external event (webhook). Each new term (cron, webhook, payload, agentic gap) is defined in a “What is it?” callout the first time it appears.
Before the eight topics, take a look at the map. Three different triggers wake up the same type of brain: an agent that reasons about the result. What changes is only who presses the button — you, the clock, or a digital doorbell.
Illustrative diagram — the agent type is defined by the trigger, not by its brain. Local, scheduled, and event-driven use the same reasoning; only who (or what) wakes them up changes.
🤖 What an agent is
What it is
In traditional automation, you connect each step: node 1 → node 2 → node 3, on a fixed and predictable path. A agent receives the desired result — not the sequence—it reasons about how to get there. It chooses tools, adapts when the situation changes, does clarifying questions when context is missing and self-heals when something breaks along the way.
What is it?Deterministic = the same input always produces the same output, through the same process (traditional automation). Nondeterministic = the agent decides the approach on the spot, so it may solve things in different ways — but it meets the goal. An agent is nondeterministic by nature.
The best analogy is dining out. Cooking by the recipe it’s automation: you follow the exact steps, and if one ingredient is missing, the process stops. Asking for a steak at the restaurant is the agent: you state the outcome (“medium-rare steak with fries”), and the kitchen figures out the “how”—replaces what’s missing, adjusts the heat, makes it again if it falls on the floor. It’s like hire an experienced developer instead of dictating every line: you delegate the goal, not the procedure.
Why learn
When you understand that an agent reasons, you stop micromanaging and start designing the result e o context. This is what unlocks speed: you describe the destination and let the agent plot (and replot) the route.
- •Adapts: new situations don’t require a new workflow—the agent improvises.
- •Question: when the request is ambiguous, it asks for clarification instead of guessing.
- •Self-healing: hits an error, diagnoses it, and tries another approach on its own.
Key concepts
You delegate the “what.”
Choose the path on the spot.
May vary; gets the job done.
Breaks, diagnoses, rebuilds.
🖥️ On-demand agent (local)
What it is
O local agent is the assistant working as your personal agent, right there on your machine: you ask, it researches, builds files, iterates with you, and gets smarter with every use. You’re the trigger — nothing runs unless you ask. It’s the simplest form of agent: without deploying, no server, no schedule. Just conversation.
What is it?On demand (on-demand) — runs only when you call it. Deploy — run something continuously on a server, away from your machine. The local agent no requires a deploy: it lives in the same place where you chat with it.
Why learn
Always start locally. That’s where you builds intuition: you watch the agent reason, notice when it gets things right and when it gets lost, and learn to provide results and context. Everything you master here transfers later to scheduled and event-driven workflows—only then, you won’t be there to correct it.
🎯 Practical tip
Use the local agent as a testing bench for what then will become scheduled. Run the same request there three or four times, see where it stumbles, and only move it to the cloud once it runs smoothly. What you don’t fix locally will haunt you in production.
Key concepts
Trigger = your request.
Runs on your machine.
Gets smarter with every use.
The foundation for the other types.
♻️ The self-improvement loop in practice
What it is
O self-improvement loop is the local agent’s superpower: you run the workflow, it hits an error, diagnoses what failed, fixes the tool that broke and updates the workflow so that error doesn’t come back. Each round makes the process smoother and faster. You’re not fixing it—the agent is weaving the fix back into its own workflow.
Runs the workflow — the agent runs the process from start to finish, right in front of you.
An error occurs — a tool returns an error, a source disappears, a format changes.
Diagnoses — reads the error, identifies the cause (not the symptom), and proposes a fix.
Fix the tool — fix the script/call that broke.
Updates the workflow — ties the fix back in so the same error doesn’t return. The next rounds run smoothly and quickly.
Why learn
It’s this loop that makes a local agent seem magical: it doesn’t just make fewer mistakes, it learns with each run. But there’s an important caveat — this superpower disappears when the agent goes into production. When it runs on its own in the cloud, nobody is watching to close the loop. Remember this: it’s the hook for topic 6, the "agentic gap".
🎯 Practical tip
Whenever the loop catches an error, ask the agent to write an explicit safeguard into the workflow for that case (a try/catch, a validation, a fallback). That way, the fix becomes a permanent part of the workflow — and keeps working when you're no longer around.
Key concepts
Finds the cause of the error.
Fixes what broke.
The error doesn’t come back.
No one closes the loop there.
⏰ Scheduled agent (cron) — anatomy
What it is
O scheduled agent runs on its own at the scheduled time — the trigger is the clock. The time is set by an expression cron, a five-field pattern: minute, hour, day of the month, month, and day of the week. For example, 0 7 * * * means "at 7 a.m. every day." The agent wakes up, does the work, and goes back to sleep, with no one watching (unattended).
What is it?Cron — a compact way to say “when to run,” inherited from Unix. It has five fields separated by spaces; the asterisk * means "any/every". Unattended — runs without human supervision at the scheduled time, even while you're asleep.
Illustrative diagram — read from left to right. Other examples: */15 * * * * = every 15 min; 0 9 * * 1 = every Monday at 9 a.m.; 0 0 1 * * = on the 1st of every month at midnight.
Why learn
Scheduling is what turns a task you’d do by hand into a automatic habit. Classic example: cron fires → the agent researches a topic → summarizes what it found → writes a row to a spreadsheet—all unattended, every day, before you wake up. You design it once and reap the benefits forever.
Crie um agente AGENDADO com cron <0 7 * * *> (todo dia às 7h).
A cada execução ele deve, sem supervisão:
1. Pesquisar na web o tópico <novidades em automação com IA>;
2. Sintetizar os achados em 3 bullets curtos (1 frase cada);
3. Gravar UMA linha nova na planilha <Radar IA / aba "diário">
com as colunas: data | resumo | 3 links.
Exigências: inputs fixos (tópico e planilha são constantes),
saída estruturada (sempre as mesmas colunas, nessa ordem),
trate erro de cada chamada externa, e logue cada passo.Key concepts
min hr day month day-of-week.
* = any/every.
Trigger = the scheduled time.
Runs without anyone watching.
🔔 Event-based agent (webhook) — anatomy
What it is
O event-driven agent wakes up when something happens out there — the trigger is a webhook: a URL that listens for requests. When an external system calls this URL, it sends along a payload (the event data). It’s the digital doorbell: someone triggers it (calls the URL), and the agent responds and acts on what came in. Example: a form is submitted → triggers the webhook → the agent generates a report.
What is it?Webhook — a URL exposed by your agent that other systems call to notify it, “something happened, act now.” Payload — the data package that comes with the call (e.g., the form fields in JSON). It’s the difference between a doorbell and a doorbell that hands you the package too.
What is it?Authorization: Bearer — a header the request needs to send with a secret key, proving that whoever rang the doorbell has permission. Without the right key, the webhook rejects the request. It’s what keeps anyone from triggering your agent.
Why learn
The event-based model is what connects your agent to the real world, in real time: a lead fills out the form and gets the report in seconds; a payment comes in and the invoice is issued right away. Instead of waiting for the next cron run, it responds at the moment of the event. And header-based authentication is what keeps that door secure.
# Chamada que ACORDA o agente — um sistema externo faz isto:
POST <https://seu-agente.exemplo.com/webhook/lead>
Authorization: Bearer <SUA_CHAVE_SECRETA>
Content-Type: application/json
# payload (os dados do evento, em JSON):
{
"evento": "novo_lead",
"nome": "Maria Souza",
"email": "maria@exemplo.com",
"empresa": "Acme Ltda",
"mensagem": "Quero um orçamento de automação."
}
# Prompt do agente por evento:
Crie um agente POR EVENTO exposto no webhook acima.
Ao receber o payload, ele deve: validar a chave Bearer;
gerar um relatório do lead (resumo + próxima ação sugerida);
e responder 200 com o relatório. Trate erro e logue cada passo.Authorization (or with the wrong key)—it should return 401/403 and no process anything. Send a payload with a missing field (e.g., without email) and check the log to see whether the agent handled the error instead of crashing.
Key concepts
URL that listens for events.
The event data (JSON).
It gets triggered → the agent handles it.
Header that authenticates.
🕳️ The agentic gap
What it is
O agentic gap it’s the gap that appears when the agent moves from local to the cloud, running on a schedule or event: the assistant is no longer looking to close the self-improvement loop. Remember topic 3? There, when something broke, the agent diagnosed and fixed it in front of you. In production, it runs, but doesn’t adapt in the same way — and a failure can go completely unnoticed.
What is it?Agentic gap — the difference between the “smart” agent you see locally (which self-heals because you’re there, closing the loop) and the “autopilot” agent in production, which runs without anyone there to notice and correct what went wrong.
✓ Local (self-healing)
- ✓You watch: you see the error the moment it happens.
- ✓The loop closes: diagnose, fix the tool, update the workflow.
- ✓Adapts to new cases right there, with your feedback.
- ✓The failure becomes permanent workflow learning.
✗ Production (no self-healing)
- ✗No one is watching: the error happens and remains invisible.
- ✗The loop never closes: it runs, but doesn’t fix itself.
- ✗A new case means unexpected behavior, with no feedback.
- ✗The failure can go unnoticed for days.
Why learn
The agentic gap isn’t a reason to avoid production — it’s what defines how you design. Since no one will close the loop for you, the fix needs to be built in from the very first prompt: error handling, a log at every step, and predictable output. You make up for the lack of live self-healing by building resilience into the agent (that’s exactly the topic of section 7).
🎯 Practical tip
Before promoting an agent to the cloud, ask yourself: "if this fails at 3 a.m., how will I know?". If the answer is "I won't stay", you're still in the agentic gap. Add an alert (email/DM in case of an error) before going live.
Key concepts
The loop doesn't close by itself.
It executes, but it doesn’t heal itself.
Can go unnoticed.
Built-in resilience.
🧱 Fixed inputs, structured output, errors & logging from the 1st prompt
What it is
Are the four requirements for any unattended build—the antidote to the agentic gap. Since no one will be watching, the agent needs to be resilient from the start: fixed inputs (no more “which source should I use today?”), structured/predictable output (always the same format), built-in error handling (try/catch around every external call) and log entry at each step. And all of this goes from the very first prompt, not as a patch afterward.
What is it?try/catch — “try this; if it errors, do that” instead of breaking. Log — a record of what the agent did at each step, which you can read later to understand what happened when no one was watching.
Source, spreadsheet, topic—everything stays constant. The agent doesn’t ask anything in the middle of the night.
Always the same columns/fields, in the same order. Predictable for whoever uses it next.
try/catch for every external call (API, scraping, spreadsheet). Failure can't mean "freeze".
One log entry per step. It’s your only window when you’re not watching.
Why learn
Anyone who handles errors and logs them from the start turns a silent failure into a clear message. The difference between waking up to discover that “the radar stopped three days ago and no one noticed” and reading “Firecrawl returned 429 for source 3 yesterday at 7 a.m.” is the difference between a toy and something reliable.
🎯 Practical tip
Log specific, not generic. "Firecrawl 429 (rate limit) na fonte 3 às 07:02" tells you what to do; "task failed" says nothing and costs you an hour of investigation. A good log names what, where e when.
Construa o agente <radar diário> para rodar UNATTENDED, com:
[Inputs FIXOS] fonte = <lista de 4 sites>; destino = <planilha X>.
Nada de perguntar nada em tempo de execução.
[Saída ESTRUTURADA] sempre as colunas: data | titulo | resumo | url,
nessa ordem, mesmo que algum campo venha vazio.
[Tratamento de ERRO] envolva CADA chamada externa em try/catch;
se uma fonte falhar, pule-a e continue as demais.
[LOG por passo] registre início/fim de cada etapa e todo erro,
nomeando fonte + código (ex.: "fonte 3: HTTP 429").
Em caso de falha, me avise por <e-mail/DM>.Key concepts
No asking in the middle.
Always the same format.
external try/catch.
Name what/where/when.
📜 When an “agent” is just a script (and that’s okay)
What it is
Not everything needs to reason. If the task is fixed and predictable — always the same steps, on the same data, with the same result — a deterministic script is more cheap (doesn’t spend tokens reasoning), plus fast and more reliable than an agent. Choosing the script here isn't "less advanced": it's the right engineering choice. Boring is beautiful — boring is beautiful.
What is it?Script — a small program that performs exactly the same steps every time (deterministic). It doesn’t reason, adapt, or cost tokens: it does what’s written, period. For tasks that never change, that’s an advantage.
✓ Use an AGENT when…
- ✓The input varies widely and requires interpretation (natural language).
- ✓The path isn’t fixed: you need to choose tools as you go.
- ✓New cases come up, and you have to adapt or improvise.
- ✓There's real ambiguity that warrants asking/reasoning.
✗ Use a SCRIPT when…
- ▸The task is fixed: always the same steps, in the same order.
- ▸The input is predictable and well-structured (no interpretation needed).
- ▸Reliability and cost matter more than flexibility.
- ▸"Boring and repeatable" is exactly what you want.
Why learn
Maturity as a builder isn't about using an agent for everything — it's about knowing when not to use. Putting an expensive, nondeterministic agent on a task that a ten-line script could handle is wasteful and creates room for errors where there were none. Choosing the right tool for the problem is what separates people who just play around from people who deliver.
Key concepts
Predictable tasks don’t need reasoning.
Doesn't waste tokens.
Do the same every time.
Valid, mature choice.
An agent runs in the cloud on cron, every day at 7 a.m., and one source went down yesterday — but you only noticed today that data is missing. Which concept explains this?
📌 Module Summary
0 7 * * * = 7 a.m. every day; runs unattended.Next Module:
Track 5 — Practical Projects (End-to-End)