My scheduled Claude Code routine failed three weeks running: what agentic workflows need that a written lesson doesn't give them

I run a set of scheduled Claude Code routines. Small autonomous jobs that wake up on a cron, pull data, compare it against a baseline, and write me a report — SEO impact checks, consent audits across four storefronts, expense reconciliation, a weekly content run. They are genuinely useful and they are the main reason a one-person operation can cover the ground I cover.

One of them has now failed three weeks in a row, in exactly the same way, for a reason I had already diagnosed and written down. Twice.

What the routine was supposed to do

At the start of August I rolled out a large content change on a directory site — around a hundred local pages and fourteen regional hubs. To find out whether it worked, I had Claude Code build a weekly routine: pull Search Console data via the API, compare an equal-length window before and after the rollout, flag queries that appear for the first time, write the result to a CSV so a time series builds up.

It needs one credential to read that data: a Google service-account key. Creating it takes about ten minutes in a cloud console, and it has to be done by a human, signed in, with two-factor on their own machine.

First run: no key, nothing measured. Noted it.

Second run: same. This time I wrote the lesson properly — a routine with a manual precondition needs a reminder with a deadline. Good sentence. Filed in my notes.

Third run last week: same. Except the third run was the one that mattered. The first two would have been premature anyway — the after-window was too short to say anything honest. By the third, the measurable window was three weeks against an equal three weeks before. That was the first date in the calendar where the routine could have produced a real answer, and the answer it produced was "still no key."

Three weeks of a weekly time series simply do not exist now. You cannot back-fill a comparison you didn't take.

The design flaw: an agent that can't do the thing it depends on

Here is the part I'd want anyone building agentic workflows to take away, because it is not really about Search Console.

That routine runs in the cloud on a schedule. It has no browser session, no access to my Mac, no local MCP servers, no signed-in Google account, no way to complete two-factor authentication. And its critical path runs straight through a step requiring all four.

So I had built an automation that was structurally incapable of unblocking itself, scheduled it to try weekly, and configured it to politely report its own failure. Every Friday it did exactly what I told it to. Every Friday that was worthless.

An agent needs to know what its execution context can actually do. Mine was scheduled in an environment where the one thing it needed was impossible — and nothing in its design made that a stopping condition.

This is the same shape as the mistake I made a few weeks earlier with a check that needed a browser it was never going to get. Which is the uncomfortable bit: I had already published the lesson and still repeated it.

The right fix isn't a cleverer prompt. It's moving that routine to a scheduled task on the Mac, where the browser and the local files and the signed-in session exist and the key never has to travel anywhere. Cloud scheduling is excellent for anything that needs an API token and a network connection. It is the wrong home for anything with a human in its critical path.

The bigger flaw: a written lesson is not a mechanism

I did everything the post-incident playbook asks for. I noticed the failure. I diagnosed it correctly. I articulated the fix in clear language. And none of it had any mechanism attached, so the system carried on exactly as before.

Google's site reliability people have written the sharpest line on this: the surest way to ensure an action item never gets completed is to leave it without an owner. Their checklist wants every action worded to be actionable, specific and bounded — a verb, a scope, a way to know when it's done. "Investigate monitoring for this scenario" is not an action item. "Add alerting when this service returns more than one per cent errors" is. Their whole blameless postmortem culture exists so that writing something down produces a change to the system rather than a description of one.

As Nassim Nicholas Taleb writes in Skin in the Game: you will never fully convince someone that he is wrong; only reality can. I had written this lesson down twice, and it took a missed measurement to make it real.

My note failed every one of those tests. No owner, no date, no definition of done, living in a file that only gets read when someone goes looking. It was a description of a fix, not a fix.

And this is precisely where AI tooling makes things quietly worse. Notes are free now. I can have Claude produce a thoughtful, well-structured retrospective on any incident in about ninety seconds, and it will be good — better organised than what I'd have written by hand. What has not got cheaper is the part where something in the world changes as a result. If anything, the fluency is a trap: a well-written lesson feels like the work is done. It generates the sensation of having closed the loop without closing it.

I've written before about how someone has to own the learning, mostly about teams. Running solo with a fleet of agents does not exempt you. I was both the person who wrote the lesson and the person meant to act on it, and the handoff between those two still failed — because there was no handoff, just a hope that future-me would read past-me's note at the right moment.

What I actually changed

Two concrete things, or this post is the same failure in a nicer font.

The routine now has an abort condition with teeth. After the second consecutive run blocked on the same missing precondition, it no longer just reports — it creates a task, with a due date, in Todoist, where my actual work lives. The report is the observation. The task is the carrier. If a routine can detect that it is blocked on a human, it can also file the work for that human.

The routine moved to where it can run. Local scheduled task on the Mac, browser and credentials available, key never leaves the machine.

And one design question I now ask before scheduling anything agentic: what does this need that its own environment cannot provide? Not "will this work today" — that's a test you pass by accident. Ask it once at design time and you save yourself three empty weeks of a report that was never going to say anything.

The lesson was right the first time. It just wasn't attached to anything that could act on it.

Sources & further reading

External
Lunney, Lueder & Beyer — Postmortem Action Items: Plan the Work and Work the Plan (USENIX ;login:)
Google SRE Book — Postmortem Culture: Learning from Failure
Google SRE Workbook — Eliminating Toil

Related posts
I scheduled a weekly check that could never run
Someone has to own the learning
The same task, three days running