The difference between this module and the previous one is who triggers it the agent. Before, it was you. Now there are two different triggers: one clock (cron, on a schedule) and a doorbell (webhook, triggered by an event). Both run in the cloud — without you present.

Illustrative diagram — same cloud platform (the “coordinator” in cyan), two triggers: the clock wakes the first; an external request wakes the second.

What it is

The first agent is a scheduled task that runs on its own every morning: through a trigger cron, it takes a fixed topic, searches the web for content with Firecrawl, synthesize with AI and write a structured row to the Google Sheets — without you present. The entire task fits in a single file, morning-research.ts, with the topic at the top (easy to change and version).

Do you have access to the Firecrawl MCP server?
If not, configure it—the key is in my .env file.

Quero construir uma tarefa agendada que rode totalmente sozinha toda manhã.
Ela pega um tópico fixo (<tópico>), busca na web com Firecrawl,
sintetiza os achados e grava uma linha no Google Sheets.
Sem perguntas no meio da execução, trate erros sem quebrar e
registre log em cada passo. Me ajude a planejar isso.

Why learn

This is the first agent that "lives on its own"—it closes the agentic gap between running locally and being in production. Note that you embed error handling and logging from the very first prompt: a hosted agent doesn't have you nearby to fix things right away, so it needs to be robust from the start.

Key concepts

What it is

In the cloud, there’s no login window for the agent to click. Instead, it uses a refresh token: a long-lived credential that automatically renews access (access token). For Google, you need four values in the .env and in the dashboard: client ID, client secret, refresh token e o sheet ID.

O método pelo OAuth Playground deu "Access blocked: this app's request is invalid".
Gere um script de terminal que use meu client ID e secret do .env para imprimir
uma URL de autorização. Vou abrir no navegador, autorizar, e o terminal vai
imprimir o refresh token. Aí eu colo no .env e nas env vars do painel.

Why learn

The refresh token is the classic friction point when hosting agents—and the “official” path (OAuth Playground) sometimes simply fails. Get to know the terminal fallback unblocks the deploy when you need it most, instead of leaving you stuck on an error screen.

Key concepts

What it is

After the deploy, you triggers a manual test in the dashboard (you can’t wait for the scheduled time) and reads traces in real time. Production errors have a reality of their own: in this project, Firecrawl returned success: false but with results — but under the ownership web instead of data. The actual response format differed from what the code assumed.

Illustrative diagram — the human debugging loop: trace → error → AI → fix → redeploy → rerun. The key step is copying the error complete with context.

O run falhou em produção. Aqui está o erro completo do trace:
<cole o erro do passo que ficou vermelho>

O Firecrawl retornou resultados, mas numa propriedade "web" em vez de "data",
e success veio false. O formato da resposta do SDK difere do que assumimos.
Corrija o parsing e me diga o comando de redeploy.

Why learn

Production is where theory meets reality: response formats change, timeouts happen, env vars disappear. The core skill isn’t “never make mistakes,” it’s the human debugging loop — read the trace, copy the full error (not your summary), return it with context, and redeploy.

Key concepts

What it is

The second agent is triggered by event, not by the clock. It receives an payload JSON via webhook (with the fields: company name, sector, objective, challenge), generates a report in .docx and saves it to the Google Drive. The AI builds the report sections (executive summary, industry context, challenges) from just these four fields.

Quero uma tarefa disparada por webhook (via um form / HTTP request).
Ela recebe um payload JSON com os campos:
<nome da empresa, setor, objetivo, desafio>
Gera um relatório .docx e salva no Google Drive.
Sem perguntas no meio, trate erros sem quebrar, registre log em cada passo.
Me ajude a planejar.

Suba o dev server e teste a tarefa de relatório com este payload:
{ "company": "<Acme>", "industry": "<Construção>",
  "goal": "<dobrar leads>", "challenge": "<ciclo de venda longo>" }

Why learn

This agent teaches you how to trigger event-based: it responds to an external request, not a clock. It’s the pattern that connects any source (form, another system, a button) to an agent that produces an artifact—and testing locally first is the discipline that keeps you from debugging two problems (your form and your task) at the same time.

Key concepts

What it is

A webhook is a “digital doorbell”: a URL that listens for data; when someone “rings” it (makes a request), it wakes up the task and passes the payload along. Since the URL can be shared (it can go on a website or in an email), you protect it with a header Authorization: Bearer + your secret key.

Method:        POST
URL:           <url-do-webhook-da-tarefa>   (inclui o ID/nome da tarefa, ex.: webhook-report)
Authentication: None        (a auth vai pelo header)
Send Headers:  ON
  Name:  Authorization
  Value: Bearer <sua-chave-secreta>   ← "Bearer" + ESPAÇO + chave (do painel → API Keys → secret)
Send Body:     ON  →  JSON
  campo:  payload  →  { company, industry, goal, challenge }

Why learn

The webhook URL is public by nature—anyone who discovers it can “ring the doorbell” and use your resources. The Bearer is the basic lock: without the right key, the request is rejected. It’s the first line of security for any agent that accepts external triggers.

Key concepts

What it is

To give the agent a human face, you build a no-code form that, when sent, makes the request to the webhook with the payload. In n8n, it's just two nodes: one Form Submission (the four fields + submit button), and the HTTP Request from the previous topic. The form tool is interchangeable—any tool that accepts a webhook/API will work.

1. Form Submission trigger: 4 campos de texto (empresa, setor, objetivo, desafio) + enviar.
2. HTTP Request: configurado como no tópico 5 (POST + Bearer + body payload).
3. Mapeie cada campo do form para o payload.
4. Execute o nó do form com dados de teste e confira o run no painel.
5. Para o teste final: PUBLIQUE o form em produção e use a URL de produção.

Why learn

The form connects a real person to the agent without you having to write a frontend yet — that comes in module 5.3. It’s the fastest way to give an automation an interface and prove the end-to-end workflow with a real submission.

Key concepts

What it is

Instead of deploying manually for every change, you connect the repository GitHub to the hosting platform: each push triggers the deploy automatically. That way, the code in the repository is the source of truth, and iterating with AI publishes the latest version. The manual step is a repository secret that gives GitHub permission to deploy.

[prompt] Configure the flow so that when I iterate with you, the code
is sent to GitHub and GitHub automatically deploys it to the platform.
Confirm that .env is in .gitignore and create a secure .env.example.

[manual step on GitHub]
Settings → Security → Secrets and Variables → Actions →
Repository Secrets → New Repository Secret
  Name:  TRIGGER_ACCESS_TOKEN
  Value: 

Why learn

Manual deployment is an easy step to forget and get wrong. Automating it means that "what’s in the repository is what’s live" — and that iterating takes only a conversation with the AI and a push. It’s the habit that separates a prototype from a maintained system. (Track 6 covers GitHub and Trigger.dev in more depth.)

Key concepts

What it is

Since the agent runs without you, the dashboard it’s how you know it’s healthy. Learn to read: the list of runs (runs), the trace for each one (each row is one step), the schedules (the active cron job + the next scheduled time) and the separation dev vs. prod. Also check the actual row that appeared in Sheets.

[ ] Em Schedules, a tarefa morning-research aparece com o cron (ex.: 0 8 * * *)
    e o próximo horário (amanhã, 8h).
[ ] O último run está verde; o trace mostra cada passo.
[ ] A linha apareceu no Google Sheets / o .docx no Drive.
[ ] A tarefa está em PROD, não só em dev.

[prompt] Adicione retries com backoff exponencial (até 3, começando em 30s)
para falhas transitórias, e configure um alerta por <e-mail/Slack> quando
um run ou deploy falhar.

Why learn

Observability is what makes a hosted agent reliable: when you're not there, runs, traces, schedules, and alerts are your eyes. A common mistake is to leave the task only in dev and assume it's live—always confirm the environment. And alerts close the loop: you only act when something actually fails.