Anatomy of an Agentic Loop

At 07:30 tomorrow, nobody will be touching the laptop. A schedule will fire, an agent will read a folder, write three lines, and a message will land in a Telegram chat. No hands. This short document shows you exactly what happens in those few seconds — because on Day 7, you'll build it.

Standing orders

Until now, your agents worked like consultants: you asked, they did, they stopped. A loop changes the contract. You write the instruction once — a standing order — and attach a trigger. From then on the work repeats without you: every morning, every Friday, every time a new file appears.

Every loop, no matter how fancy, is four parts:

Trigger — when it runs (a schedule or an event). · Task — what it does (one defined job, written like a skill). · Guardrails — what it may not do (which folders, what needs a human). · Report — the message that proves it ran, every single time.

Remove any one part and it stops being engineering. No trigger — it's just a prompt. No task — nothing happens. No guardrails — you've released an unsupervised intern into your file system. No report — you'll find out it died three weeks after you needed it.

One real run, opened up

This is a lightly cleaned transcript of a real loop from our lab — a “morning briefing” like the one you'll build. The yellow notes are the anatomy lesson:

[07:30:00] trigger: schedule "daily 07:30" fired

1 · TRIGGER. No human present. The schedule is the one who "asked".

[07:30:01] task: morning-briefing — loading standing order

read AGENTS.md ............ ok (23 lines)

read spec.md ............... ok (14 lines)

2 · TASK. The order says which files to read. Not "look around" — exactly these two.

write? ..................... DENIED by guardrail (read-only task)

3 · GUARDRAILS. The agent considered updating a file — the fence said no. Fences are checked, not hoped for.

compose briefing (3 parts) . ok

send telegram → home channel ✓

"Project: payment tracker, v0 works locally. Next: deploy

to Netlify. Question for you: should unpaid show sums or

just names?"

4 · REPORT. Three useful lines in a chat — and proof of life. Even an empty morning sends "nothing new today".

[07:30:19] run complete — next run: tomorrow 07:30

Nineteen seconds. The whole thing. Now read it once more and notice what's missing: no creativity, no judgment calls, no surprises. A good loop is boring on purpose — all the interesting decisions were made once, by you, when you wrote the standing order.

Why guardrails come before cleverness

A loop runs when you're asleep. That single fact changes the safety math: any mistake it can make, it can make thirty times before you wake up. So loop-builders follow three rules that will be drilled on Day 7:

Fence the territory. A loop touches only the folders named in its order. “Tidy my downloads folder” — fine. “Tidy my computer” — never. The fence is sized to the worst case, not the best.

Dry-run first. Every loop performs once in front of you — reporting what it would do — before it earns a schedule. You're not checking whether it works; you're checking whether what-it-does matches what-you-meant. Those differ more often than anyone likes.

Report always. Success, failure, or “nothing to do” — a message every run. A silent loop and a dead loop look identical from the outside, and dead loops get discovered exactly when you needed them working.

The write-rule Loops that only read (briefings, digests, reminders) are safe by construction — worst case, a useless message. Loops that write or delete get one extra rule: run them in report-only mode for a week — “tell me what you would have changed” — before letting them act. Trust is earned in reports.

Loops you'll actually meet

The pattern is everywhere once you see it. A morning briefing that reads your project and asks you one good question. A Friday collector that lists unpaid invoices from a folder of PDFs. A nightly tidy that files screenshots by month. An evening tutor that reads your support bot's unanswered questions and drafts answers for your approval — you'll build that one on Day 10. Our lab publishes seventy of these in the Loop Library; on Day 7 you'll adopt one instead of inventing from a blank page.

And one loop watches over this very course: each evening, an agent reads the cohort's Telegram posts and reports who shipped homework. Its four parts fit in four lines. Yours will too.

Check yourself

Your friend says: “I don't need loops — I can just ask the agent every morning.” What's the real difference?

The trigger. Asking every morning means the system's reliability is your memory and your mood. A loop runs because the schedule fired — on the morning you're sick, traveling, or busy, the work still happens. Loops turn habits into infrastructure.

A loop that deletes “old files” ran for a week and never sent a single message. Which rule died, and what do you do?

Report-always died — and that's the alarm. Pause the loop, check what it actually did this week (save points help), and rewrite the order so every run reports. A deleting loop with no reports isn't automation; it's a slow-motion accident.

Tomorrow you write your first standing order. Keep the transcript in mind: a good loop is four honest parts and nineteen boring seconds. The ambition goes into what you automate — never into how cleverly it runs unattended.