Reliability, cost, and retirement.

Observability: a log line, an artifact header, a next-run expectation CORE

In the first four lessons of Module 6 you built automations that produce. Lesson 6.5 is about the automations running reliably over time, which is a different discipline. Reliability’s first rail is observability — the practice of leaving enough evidence of each run that you can tell, in thirty seconds, whether your automations are healthy.

The Module 6 observability minimum is three things, per task:

• A log line per run. Successful, failed, or no-op — every run writes one line to the task’s log file. ISO-8601 timestamp, task name, status (success, no-trigger, error), artifact path (if any), cost in dollars, a one-sentence message. A log you can tail -n 30 and understand. If your task cannot explain what it did in one line, the task is too big or the log is lazy.
• An artifact header. Every artifact a task produces opens with a header block: run timestamp, task name, run ID, the idempotency key that names it, what the agent searched, how many items it read, how much it cost, which section-5 health notes apply. You saw this in Lessons 6.2 and 6.3 piece-by-piece; Lesson 6.5 formalizes it. An artifact without a header is not reviewable at 6 AM — you cannot distinguish a current run from a stale file.
• A next-run expectation. Printed inside the artifact footer or the log entry: Next run expected at 2026-04-23T06:30 local. Knowing the expected next run lets you notice when a run is missing, which is the silent failure mode the log by itself will never tell you about. A log that stops growing is indistinguishable from a healthy quiet week unless you know when the next line should have appeared.

That’s the floor. You do not have to build a dashboard. You do not have to wire metrics into a time-series database. You do have to write the log line, add the header, and print the next-run expectation. If you do those three things for every task in your register, you have the basic observability most student automations skip.

One more note: the log file itself needs housekeeping. A log that grows forever is a log nobody reads. Every task’s log is truncated or rotated when it exceeds a size — the recipe uses a simple “keep last 30 days” rule by default. Lesson 6.5’s retirement ritual audits log files along with register rows.

Retries and the failure-mode hierarchy CORE

Scheduled tasks fail. They fail because the network was flaky, because an API key rotated, because a scope was revoked, because the model provider had a five-minute incident, because the laptop was asleep, because the prompt returned something the agent could not parse. The question is not how to avoid failures — you cannot — but how your task behaves when they happen.

The failure-mode hierarchy tells you which failures to treat which way:

• Transient failures — retry once. Network hiccups, a 429 rate-limit, a brief model-provider outage. The right response is one retry with a short backoff (30–60 seconds), then either success or escalation to the next tier. The recipe’s wrapper scripts handle this for you in the scriptable path; Cowork’s scheduled tasks retry similarly. Do not retry forever — three retries is still conservative; an hour of retries is an outage.
• Input failures — fail loud, do not retry. The scope the agent was told to read is gone (label deleted, file moved, credentials revoked). Retrying will produce the same failure. The task should log the error, write no artifact, and either send itself a self-addressed alert or just let last success go stale in the register so the next review catches it.
• Output failures — fail loud, preserve partial output. The task produced something, but not the right shape (four sections instead of five, missing evidence links). The right response is to write what was produced to an attempted path — brief-2026-04-22.attempt.md — log the shape-mismatch, and not replace the last-good artifact with the broken one. The student sees the attempt on the next review and decides what to do; they do not wake up to a corrupted file in place of yesterday’s usable one.
• Catastrophic failures — stop the task. Credentials have been revoked, the underlying model has been deprecated, the scope no longer exists. One retry and then stop — the task pauses until a human audits it. This is the same shape as a past-due review date: a paused task is better than a task silently producing nothing.

The rule of thumb: retry transient, fail loud on input/output, stop on catastrophic. Your scripts and Cowork both support this; the discipline is writing the prompt and the wrapper so the failure modes actually land where the hierarchy says.

One frequent trap: students who catch-and-swallow errors because “I don’t want the task to crash.” A task that silently succeeds on failure is the worst possible outcome — it looks healthy in the register, it has a fresh last run, and it is quietly producing nothing useful. Loud failures are a feature; make them louder, not quieter.

Cost is a rate, not a session CORE

You already set a cost ceiling per task in the register. Lesson 6.5 makes you compute the rate and check it against reality.

Per-run cost is the dollars a single firing of the task spent. Get this from your model provider’s billing page or the cost figure the task logs in its artifact header. For the tasks you built:

• Morning brief: typically $0.03–$0.15 per run depending on inbox volume and model. Once per day.
• Weekly report: typically $0.15–$0.60 per run depending on commit volume and topic scope. Once per week.
• Research refresh: typically $0.05–$0.25 per run. Once per week, baseline + scheduled.
• Watcher: typically $0.005–$0.03 per run (most runs produce nothing, so cost is the classification pass). Multiple runs per day.

Monthly cost is per-run × runs per month. Do the math for each task. Add them up. Compare to the total-automation ceiling you wrote in your Automation Posture statement in Lesson 6.1.

The example looks small. The reason the course still puts a ceiling on every task is that students routinely add a second watcher, then a third, then start running the research refresh daily instead of weekly, then add a second morning brief scoped to a different topic — and three months later they are paying $60/month for automations they have stopped reading. The ceiling forces the math to happen before the bill arrives, not after.

The rate-vs-session difference matters. A $3 chat session is a decision the student made once and paid for once. A $3-a-month automation is a decision the student made once and will pay for in perpetuity until they retire it. $3 a month for ten years is $360 if the task runs that long. Automations age into real money if they are not retired when they stop earning. This is one of the main reasons the retirement ritual is compulsory, not optional.

The five retirement signals CORE

Every scheduled task eventually stops being worth running. The signals that a task has reached that point are five — named and specific so you can recognize any of them without waiting to find out the hard way:

1. Named event. The retirement trigger in the register fired. The court case was decided; the deadline passed; the project ended; the competition concluded. When a named event fires, retirement is automatic, not optional. This is the easy case.
2. Stale last-success. Last run is current (scheduler is firing) but last success has gone stale past your own threshold. For briefs and reports this typically means you have stopped reading them. For watchers this is the alert-fatigue signal from Lesson 6.4. Retire or redesign; do not keep a task running into a void.
3. Silent drift. The task still produces artifacts, but the artifacts no longer answer the question the task was built for. A morning brief whose three things has degenerated to three newsletters is drifting. A research refresh whose diff contract matches less and less of the real news-shape of the topic is drifting. Drift catches you at a review date if you look; it does not announce itself.
4. Ceiling breach. The task’s monthly cost exceeded the ceiling and you cannot explain why. Either the underlying data volume grew (inbox tripled, commit history exploded) or the prompt grew, or the model was upgraded with a different price point. Pause, audit, resume — or retire.
5. Human-attention bankruptcy. You have too many tasks. Not because any single task is wrong, but because the aggregate demand on your review time exceeds what you actually have. The rule of thumb: if your total automation suite demands more weekly review time than you wrote into your Automation Posture as your budget, it is over-built. Retire the lowest-leverage task.

The retirement ritual in the worksheet asks you to check every register entry against all five signals. Expect to retire at least one task during Lesson 6.5, even if everything is working. A module where nothing gets retired is a module where the discipline did not land.

Revoking schedule-bound credentials CORE

Module 5 installed the revocation ritual for email/calendar permissions: when a task is done, access is withdrawn, not left running. Module 6 extends the ritual to the specific case of scheduled tasks.

When you retire a scheduled task, three things happen, in order:

1. Disable the scheduler entry. Remove the cron line, unload the launchd plist, disable the Windows Task Scheduler entry, or delete the Cowork scheduled task. Do this first — the task does not fire tomorrow.
2. Revoke the credentials the task was using. This is the step most students skip. The OAuth scope the task held, the API key that was specific to the task, the MCP permission that was granted — each is withdrawn. If the credential is shared across tasks, reduce the scope to match what the remaining tasks actually need.
3. Archive the artifacts and the log. Move the task’s folder to ~/ai-architect-academy/automation/retired/<task-name>-YYYY-MM-DD/. Leave the register row in place with status Retired <date> and a one-sentence post-mortem; do not delete the row. Future-you will want to remember what this task did and why it retired.

Students rebuild tasks they previously retired far more often than they expect. The archive path is small and makes restarting trivial. Deleting the task entirely is the anti-pattern.

The specific credential-revocation question — “does this task have a token I should kill?” — is a good instinct to bring into every retirement. For Cowork-tab scheduled tasks the credentials are session-scoped and retire with the task; for Optional Advanced (CLI + OS scheduler) tasks the credentials may live in ~/.ai-directed/credentials/✓ and outlast the cron entry unless you revoke them.