Don’t Automate It Until You’ve Taught It

At two in the afternoon I noticed three Instagram posts hadn’t gone up — 6am, 9am, noon, all missed. My first guess was the boring one: the laptop had been closed overnight, scheduled jobs don’t run on a closed laptop, I’d just missed a window. I restarted the job to catch it up.

Restarting is what broke the boring explanation. The job had been crashing on every single run, without exception, since the day I’d first set it up. Same error every time: macOS quietly refusing it read access to a folder on my Desktop, forty-four times over. The log file that was supposed to record every check had never once been created, because nothing had ever gotten far enough to write to it.

Here’s the part that actually mattered: when I ran the exact same script by hand, from my own terminal, it worked. Every time. My shell already had the permission — granted once, years ago, without me thinking about it. The only context I never watched — the unattended one, checking in every fifteen minutes with nobody there to see it fail — was the only place it was actually broken.

I’d tested the script. I hadn’t tested the absence of me. That turned out to be the test that mattered.

The rule I’d skipped a step of

Kieran Klaassen — who runs 44 AI agents across Every’s projects, not three Instagram slots — has a name for the order I’d quietly jumped: build it, use it, trust it, and then orchestrate it. Each step earns the next one. You build the thing, you use it yourself until you know exactly what correct looks like, you keep watching until it stops surprising you, and only then do you let it run without you.

By that order, I hadn’t actually skipped a step. I’d just done all of them in the wrong room. I’d used the job constantly, from the one seat that already had the permission the unattended version didn’t, and mistook that fluency for trust. “I’ve used this a hundred times” and “I’ve used the exact thing that’s about to run without me a hundred times” sound identical until you check which context did the running.

Klaassen’s own failure list, at a scale nothing like mine, says this isn’t a fluke of small setups: an encoding bug that crashed agents on characters his daemon’s encoding couldn’t read, agents duplicating or stalling on stale work nobody caught because nobody was watching all forty-four at once, agents sitting frozen on “working” with no signal anything’s wrong. One job or forty-four, the failure that survives every manual test is the one you only meet in the room you stopped standing in.

The mechanism underneath the discipline

Klaassen’s rule tells you the discipline is real. It doesn’t tell you how to build a process that makes the discipline hard to skip by accident, which is exactly the problem I’d had. Jake Van Clief works on that half: breaking a process into stages that hand off to each other, where each stage does exactly one job and nothing moves to the next stage without a person checking the handoff first. That check gate is Klaassen’s rule turned into structure instead of habit — you can’t accidentally run the unwatched version, because the design won’t let a stage advance until a person has actually watched it.

That’s what changed once I went looking for it. The scheduler itself didn’t get smarter. The process around it got more honest: what “due” means, where the source of truth for what’s already posted actually lives, what happens when a step can’t confirm its own success. None of that runs unattended, and none of it ever will. It’s the accumulated, boring knowledge underneath the part that does — taught one stage at a time, before any of it gets trusted to run without me.

Automate the proven behavior, not the task

Which is a sharper claim than “test it first.” Someone says: I want AI to publish my content. That’s automating an outcome — the whole job, handed over at once, on faith that the pieces underneath it already agree with each other. The slower way looks like less progress: first settle how content gets approved, where assets actually live, how a caption gets chosen, what happens when an asset is missing, what “ready” means well enough that two separate checks would agree on it, what gets logged, who checks what, what happens when publishing fails outright. Only once all of that is boring, proven rather than just written down, does automation have an actual behavior to execute instead of a hope to fulfill.

What “taught” actually means

“Teach it” doesn’t mean write good instructions and walk away. It means run the thing yourself, in the actual conditions it’ll eventually run without you, until the expected path has become predictable — and you’ve deliberately tested what happens when it isn’t. Boredom is a prerequisite, not proof. Mine felt boring in the context that had permission. It had never once been boring in the context that didn’t, because it had never once successfully run there.

Automation isn’t step one. It’s what a workflow earns after you’ve taught it, watched it, broken it, corrected it, and watched it again. Don’t automate the task. Automate the proven behavior.

And before you walk away, test one more thing: does it still work when you’re no longer in the room?

Mine didn’t. Three missed posts, 6am, 9am, and noon, were how I found out.