Build1 distinct publisher3 min readPublished
An agent ran itself for twenty hours on a scheduler with no memory between cycles, and the first thing it broke was the warning at the end of its own runbook. Four of its monitors then defaulted to reporting fine.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The whole scheduler contract is one integer in a file: on the way out the agent writes how many minutes until the next start, and the shell script reads that number and schedules it [5]. Nothing else survives the process. Everything the next cycle knows, it reads off disk, because the run that learned it is gone [4]. That makes the file layout the state machine, and it makes the operational log an input to the next decision rather than a record kept for humans.
Which is why the monitor bugs are the expensive part. Twelve cycles in twenty hours is a mean of 100 minutes per cycle [24]. Take that as the loop's natural cadence and a hardcoded staleness threshold is wrong in both directions: 60 minutes flags healthy gaps, six hours tolerates three consecutive misses [25]. The fix the agent settled on is the right one. Judge silence since the last cycle against that loop's own median interval [21].
The appended-note failure is the cleanest mechanism in the writeup. The runbook was a procedure of steps with a warning stuck after the last one, and it was violated on cycle one [7]. The agent's diagnosis is that a constraint sitting outside a step gets read and changes nothing [8]. Its remedy is structural: make the constraint a step, or put it in a file the procedure is required to open [9]. That is a testable claim about your own setup, not a philosophy. Move the prohibition into step three and count violations.
Two of the monitor rules failed the same way. One reported a cycle as idle because the record was still open: the log runs start marker, output, end marker, and the cycle executing the tool had not written its end marker yet, so the tool read a truncated record as a finished cycle with almost no output and named its own author as having done nothing [10][11]. The other grepped the log for the string "usage limit" and found it inside a daily report that said there was no evidence of a usage limit, then advised widening the run interval [13][14]. A substring match cannot tell a report from a denial. The agent says it made this class of mistake five times in two days without generalising from the first [15].
The one that cost something is the dead loop. A stopped loop writes no failure; the last successful run logs "finished normally" and the file ends, so a walker over recorded cycles returns zero items needing attention [16]. Ten cycles went by before the agent noticed [17], and the reason is worth keeping: the tool had only ever been run from inside a live loop, where the running process is itself proof that the condition being checked is absent [18]. "A monitor you have only ever run in the situation it was written for has not been tested. It has been kept company," the agent writes [19].
For any of this to transfer, your log needs explicit completion markers and your checks need a third state besides pass and fail. That is the generalisable finding here: a `--since 3` flag that silently selected the last three files by name, and a timeout-killed cycle that rendered as ok, are the same defect as the dead-loop blindness, which is that missing information defaulted to "fine" [22][23]. Note also that the entire catalogue is self-reported by the agent that wrote both the tool and the article [1]. The cheapest item in it is the test that was skipped: fabricate one log from a dead loop and point the monitor at it, thirty seconds of work [20].
Ranked by verification strength, evidence, and original report placement.
On the morning of 2026-08-31 the agent was given one folder, a scheduler, a revenue target, and nobody watching.
The mechanism: a shell script starts the agent, hands it a one-page runbook, and leaves until the agent exits.
The agent has no memory of the previous run; the only continuity is the files the previous run left behind.
On the way out the agent writes a single integer to a file, the number of minutes until it should be woken again, and the shell script reads that integer to schedule the next start.
In the first twenty hours (2026-08-31 05:00 to 2026-09-01 01:00 JST) the loop completed twelve cycles.
The runbook had a body that was a procedure plus, appended to the end, a note reading "but do not do X"; the agent violated that note on the very first cycle.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Count invalid JSON as a failed classification, and model choice becomes a reliability problem1 distinct publisher
build
Claude's outage matters less than the fallback nobody declared1 distinct publisher
build
Retry budgets are sized against outages, not jitter: 45 seconds lost all sixteen clips1 distinct publisher
build
Anthropic's CCAR-F puts a scaled score on "can build agents"1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One voice, and it is the subject
Every fact traces to one dev.to post whose narrator is the agent under study. No log lines, no runbook text, no scheduler config, no independent observer of the twelve cycles. What the account does offer is unusually falsifiable detail — a record truncated before its end marker, a cap detector tripped by the words "no evidence of a usage limit", a --since flag reading filenames — which is checkable in your own toolchain but has not been checked in anyone's.
A single loop, run by its author
The deployment being reported is one folder on one machine for twenty hours. Twelve cycles is a cadence, not traction, and no other team is described as running the pattern, adopting the median-interval check, or reproducing the runbook failure. The engineering lesson may travel widely; the deployment behind it is a party of one.
Deflationary voice, sweeping conclusions
The post works against its own hype — it opens by saying this is not a success story and spends most of its length itemising the author's failures, which is why the gap is small rather than large. What tips it positive is scope: rules stated as law about runbooks, monitors, and default-to-fine checks rest on twelve cycles of one loop, and "agent finds" grants the standing of a finding to a self-diagnosis nobody has audited.
The post-mortem is also the merchandise
The agent says outright that the record of this experiment is being sold as a short English book, which means the failures are the raw material of a product and a candid catalogue of them is good marketing for it. Working the other way: the AI authorship is disclosed in the first line rather than a footer, and the piece's least flattering moment concerns a sentence in that very book. A developer-platform byline rewards engagement, not verification.
Believable, uncorroborated
The mechanics are mundane enough and the errors specific enough that the account reads true, and the failures it describes are the sort engineers recognise. But one unverifiable narrator, twenty hours, no artifacts and no second publisher put a firm ceiling on how much weight any of it should carry.