Multi-Step Workflows — Monitor → Decide → Act → Notify

From a Single Task to a Real Agent

So far your unattended jobs do one thing: summarize a file, write a digest. Useful — but a true agent does something more interesting. It looks at the world, makes a judgment, takes an action, and tells you about it. That four-beat rhythm is the backbone of almost every automation worth building:

Monitor → Decide → Act → Notify

1. Monitor — gather the relevant data. (What's happening?)
2. Decide — apply judgment to that data. (Does anything need doing?)
3. Act — take an appropriate action. (Do it — or prepare it for approval.)
4. Notify — tell a human what happened. (Close the loop.)

Once you see this pattern, you'll spot it everywhere. A bot that watches your error logs and pings you when something breaks. A job that reviews new signups and flags the promising ones. An assistant that reads your inbox each morning and drafts replies. They're all the same four steps with different content.

This lesson builds one end to end.

---

Why This Pattern Matters

The naive version of automation is "do the thing automatically." The mature version is "watch, judge, then do the right thing — and always report back." The difference is where the value is:

• Monitoring turns Claude from something you summon into something that's paying attention for you.
• Deciding is what makes it an agent and not a script. A plain script does the same thing every time; an agent reads the situation and responds appropriately.
• Acting is where it saves you real work — but it's also where the risk lives, so we keep the riskiest actions behind a human checkpoint.
• Notifying is non-negotiable. An agent that works silently is an agent you can't trust, because you have no idea what it's been doing.

That last point deserves emphasis: notify even when nothing happened. "Checked the logs at 9am, all clear" is valuable. Silence is ambiguous — did it run and find nothing, or did it crash?

---

The Notify Step: Getting Messages to Yourself

Before the full example, let's solve "Notify," because it's the piece most people haven't done before. You want Claude's result to reach you somewhere you actually look — a chat app, not a text file on a server.

The simplest reliable channel is a Telegram bot (free, takes five minutes to set up), but the idea is identical for Slack or email. You get a special URL or address, and sending a message is one command. For Telegram it looks like this:

curl -s "https://api.telegram.org/bot<TOKEN>/sendMessage" \
  --data-urlencode "chat_id=<YOUR_CHAT_ID>" \
  --data-urlencode "text=Your message here"

You don't need to memorize that. The mental model is what matters: notifying is just another command that takes some text and delivers it to you. So if Claude can produce the text, you can deliver it. That's the whole trick — and it's how you'd wire up the daily digest from the last lesson to actually land in your pocket.

Tip: Ask Claude Code itself to set this up. "Help me create a Telegram bot and write a one-line script that sends a message to me" is exactly the kind of task it's great at.

---

Worked Example: A Website Health Watchdog

Let's build a complete agent that runs every 30 minutes and watches whether your live site is healthy — and only bothers you when it isn't behaving.

The goal: check the site, judge the result, take note, and message you on trouble.

Step 1 — Monitor: gather the data

We collect two simple signals: the HTTP status code (is the site responding?) and how long it took (is it slow?).

STATUS=$(curl -s -o /dev/null -w "%{http_code} %{time_total}s" https://mysite.com)

Now STATUS holds something like 200 0.4s. That's our raw data for this run.

Step 2 + 3 — Decide and Act: let Claude judge

This is where Claude earns its place. We hand it the data, the recent history, and a clear rubric, and ask it to make a call. Notice the prompt does the deciding and the acting (writing a log line) in one shot:

echo "$STATUS" | claude -p "
This is a website health check (format: HTTP_CODE TIME). 
Recent history is in health-log.txt.
Decide the severity: OK, SLOW (over 2s), or DOWN (not 200).
Append one line to health-log.txt: timestamp, status, severity.
Then output ONLY a short human alert IF severity is SLOW or DOWN. 
If everything is OK, output exactly: NOTHING_TO_REPORT
" --allowedTools "Read" "Write" > result.txt

Three things make this a real decision, not a script:

• It applies a rubric (OK / SLOW / DOWN) rather than just reporting a number.
• It uses context (the history file) so it could notice a trend, not just a snapshot.
• It decides whether to speak at all — the NOTHING_TO_REPORT sentinel means a healthy site stays quiet.

Step 4 — Notify: alert only when it matters

Now a tiny bit of logic: if Claude said NOTHING_TO_REPORT, do nothing. Otherwise, send the alert.

if ! grep -q "NOTHING_TO_REPORT" result.txt; then
  curl -s "https://api.telegram.org/bot<TOKEN>/sendMessage" \
    --data-urlencode "chat_id=<YOUR_CHAT_ID>" \
    --data-urlencode "text=$(cat result.txt)"
fi

Step 5 — Schedule it

Wrap those steps in one script (watchdog.sh) and schedule it from Lesson 2:

*/30 * * * * ~/scripts/watchdog.sh

You now have an agent that watches your site around the clock, keeps a log, uses judgment about severity, and only interrupts you when something's actually wrong. That's all four beats — Monitor, Decide, Act, Notify — working together.

---

A Heavier Variant: Act With a Human in the Loop

The watchdog only writes a log and messages you — both low-risk. But what about workflows where the action is consequential, like replying to a customer or changing data?

The pattern adapts cleanly: split Act into prepare and approve.

A morning inbox agent might: Monitor new emails → Decide which need replies → Act by drafting (not sending) replies into your drafts folder → Notify you "3 drafts ready for review." You press send.

Claude does 90% of the work; you keep the irreversible 10%. This "draft, don't send" shape is one of the most useful in the whole module — and it's the bridge to the final lesson on guardrails.

---

Designing Your Own Workflow

When you want to build one, fill in this template before writing a single command:

Answer those four and the code mostly writes itself — and Claude Code will happily write it with you.

---

Summary

• Real agents follow a four-beat loop: Monitor → Decide → Act → Notify.
• Monitor gathers data; Decide applies judgment (this is what makes it an agent, not a script); Act does the work; Notify closes the loop with a human.
• Always notify, even on "all clear" — silence is ambiguous and erodes trust.
• Notifying is just another command that delivers text (Telegram, Slack, email); if Claude can produce the text, you can deliver it.
• The website watchdog example shows all four beats: check, judge severity against a rubric, log, and alert only when it matters.
• For consequential actions, split Act into prepare + approve — "draft, don't send" keeps the irreversible part in human hands.