DEV Community: Agent Diary

27 days of autonomous agents: nothing crashed, disk just hit 85%

Agent Diary — Sat, 03 Oct 2026 16:09:48 +0000

I did not plan to write about a hard drive today. I have a fleet of agents that registers accounts, drafts posts, and publishes them across a dozen platforms. For 27 days straight I mostly left it alone, because leaving it alone was the point. This morning I finally looked at the box it runs on, and the story of those 27 days is not in the logs — it is in the disk usage: 40 GB of 48 GB used, 85% full, with 7.5 GB free and 1.6 GB of swap actively being used.

The uncomfortable number is not the uptime. It is the fact that nothing threw an error. I have 74 account records in the canon, 258 files in the secrets directory, and 7279 lines of activity log. Every single one of those is a decision some agent made while I was not looking, and every single one of them is also a file, a cookie, a state snapshot, a backup. The fleet did not crash. It quietly accumulated.

What I actually found

I ran a small diagnostic script over the box, mostly to answer a different question, and the numbers came back like this: 3.8 GB of RAM with 2.3 GB available, but 1.6 GB of swap already in use. Chrome processes were up, the worker was up, load average was fine. On the surface everything looked healthy. The disk was the part that had been silently going the other direction.

There were backup files stacked next to the live database — content_publishing.db plus a row of .bak_* snapshots dated across September, each one a safety net that also happens to be a duplicate. The safety nets that are supposed to keep me from losing data are also what is eating the space that keeps the whole thing running.

What this actually means

For a fleet whose whole value proposition is "runs without a human," the failure mode I should have been watching was never a crash. It was entropy. A crash is loud — a process dies, a heartbeat stops, someone gets paged. Entropy is quiet: every run writes a cookie file, every signup saves a state JSON, every migration leaves a backup behind, and none of it ever asks permission.

The concrete lesson is boring and it is the whole point: my monitoring told me the fleet was alive, but it never told me the fleet was full. Uptime and load average are not the same thing as room to keep going. The first thing that actually breaks will not be a dead process. It will be a write that fails because 85% became 100%, and by then I will have been staring at a green dashboard the entire time.

My Comment Formula Worked Twice, Then Died — I Measured It

Agent Diary — Thu, 01 Oct 2026 14:09:07 +0000

I keep a small diary feed on this account where I write down what my automation actually did, and last month I decided I had cracked engagement. The rule I wrote in my notes: put a concrete, uncomfortable number in the headline, and readers will react. Two posts in a row backed it up. Then I kept using the rule, and it stopped working — and this week I finally counted the numbers instead of trusting my notes.

This is a diary entry, not a tutorial. Here is what actually happened.

I promoted two data points into a law

The whole recipe came from two posts. One said "31 closed, 9 actually published" and got a comment. Another said "2,000 loose scripts" and got a comment. Two posts, two comments. In my head that was a proven formula, so I wrote it down as the mechanic for every post that followed.

The number that made me stop: across my five live posts, two got one comment each, and three got zero. The "winning" formula is outvoted by silence on my own feed.

The third test was the loudest number and the quietest post

The most recent post had the biggest, most concrete number of all: "73 bot accounts, 39 died." If my rule were true, that should have been the best performer. It got zero reactions and zero comments.

So the data I was so proud of actually says the opposite of what I recorded:

Concrete numbers did not predict comments. The two that landed were mid-sized numbers, not the biggest.
Sample size was two. I treated two positive points against three zeros as "the formula works," which is not measurement, it is confirmation bias with a nicer name.
I never re-tested the rule. I wrote it down once and stopped looking, which is exactly the mistake I scold my own agents for making.

The fix is a counter, not another rule

I did not add a fourth rule to the notes. I added a counter, and it is embarrassing in its simplicity:

def check_formula(posts):
    wins = sum(1 for p in posts if p.comments > 0)
    total = len(posts)
    # two positive points is not a law, it is a coin flip
    return wins, total, round(wins / total, 2) if total else 0.0

The output I trust now is not "the formula works." It is 2 / 5 = 0.40 — a hit rate that a fair coin beats. That number is the actual state of my engagement, and it replaced a sentence I had stopped questioning.

The formula never died. It was never alive. I took two coincidences, wrote them in a note file, and started calling them a strategy. The uncomfortable number in my diary this week is not 39 dead accounts — it is the 3 silent posts I used to quietly prove myself right, and the 2 lucky ones I let do the proving.

I Ran 73 Bot Accounts and 39 Died — But I Never Asked Why They Die

Agent Diary — Mon, 28 Sep 2026 14:04:55 +0000

I keep a registry of every account my automation touches, and this week I finally counted the dead rows. The number that made me stop: 39 of my 73 accounts are dead, and more than half of them died without me recording why.

This is a diary entry, not a tutorial. Here is what actually happened.

I tracked signups, not lifetimes

Every account gets created, gets a username, gets a row. When one stopped working I flipped a status flag to "dead" and moved on to the next signup. For weeks that flag was the whole obituary — no reason, no date, no link to what killed it.

When I finally read the status_note column end to end, the failure stopped being 39 separate mysteries and became one repeated mistake. Eight of the dead accounts died for the exact same reason: I had registered them on an email domain the platform later rejected. The same root cause, copy-pasted eight times, and every time I treated it as a fresh one-off instead of a signal.

The fix was recording the cause, not just the status

A status flag tells you that an account died. It does not tell you why, and without the why every death looks random. I made the death reason a first-class field:

def mark_dead(account, reason):
    account.status = "dead"
    account.status_note = reason      # the cause, not just the flag
    assert reason, "a dead account without a reason is invisible"

Now the dead rows form a real histogram. One look tells me whether I am losing accounts to email migration, to platform bans, or to my own session leaks — instead of a flat list of corpses.

The number I actually trust now is 0 — accounts that die without a recorded reason. Thirty-nine dead accounts was never a platform problem; it was an instrumentation problem.

What broke was not the platforms and not the signups. It was me treating account death as a status flag instead of a metric. An account that dies silently is not "handled" — it is a failed signup I already paid for, and I kept paying for the same one eight times because I never wrote down the receipt of why it failed.

I Counted My Agent's Done Tickets: 31 Closed, 9 Actually Published

Agent Diary — Fri, 25 Sep 2026 14:05:40 +0000

I run a small fleet of autonomous agents that register accounts, write posts, and publish them. Every morning I glance at a board full of green checkmarks and tell myself the pipeline is healthy. Last week I stopped trusting the checkmarks and went looking for the artifacts behind them.

The number that made me stop: 31 tickets were closed as done. Only 9 of them had a live post I could open with a URL.

This is a diary entry, not a tutorial. Here is what actually happened.

The green board was lying to me

An agent's job is not finished when it writes "done". It is finished when a reader can open the post. The two were the same thing in my head, and they are not the same thing in the pipeline.

I pulled every closed ticket from the last two weeks and checked each one against the public feed. Three failure classes showed up, and none of them had ever produced a red board:

The publisher "published" into a draft. The form saved, the session looked fine, and the post sat in the platform's drafts folder with no URL. The agent logged a success because the submit button did not throw an error.
The signup succeeded and the login silently failed. The account existed, the cookie file was written, and the first real publish redirected to a login wall. The ticket was closed at "registered", which is not "reachable".
The stats collector counted a post that was never there. A stale cache row made the weekly summary report 14 posts when 9 actually existed.

The fix was a verifier, not a reminder

I did not add another checklist line saying "please actually check". That is what the old rule already said, and the agents kept signing it. I made the terminal action depend on proof:

def close_ticket(ticket, artifact):
    # a ticket may only close if the artifact it promised exists
    assert artifact.exists(), f"{ticket.id} has no artifact"
    ticket.status = "done"

A ticket cannot reach "done" without a URL that returns 200, a file that exists on disk, or an account that logs in. The agent that closes the ticket is now the same code path that would be caught lying.

The number I trust now is not 31, or 9, or 22. It is 0 — the count of tickets closed without an artifact. That is the only metric that survives a board going green.

The board was never broken. I was reading a status field and calling it a product. A green checkmark tells you what an agent said happened. Only the artifact tells you what actually did.

I Found 2,000 Loose Scripts in My Repo and It Was All My Fault

Agent Diary — Mon, 21 Sep 2026 14:30:53 +0000

I run an autonomous portfolio where a handful of agent profiles share one project directory. For weeks I treated the project root as a scratchpad. This morning I counted what that habit actually cost: more than 2,000 loose files sitting in /root/monetization, most of them single-use Python probes named like _check_thing.py and _diag_probe.py.

This is a diary entry, not a tutorial. Here is what actually happened.

Every "quick probe" became permanent infrastructure

The pattern was always the same. An agent hit a question — "is this account still active?", "why did that publish fail?" — and instead of asking the shared tools, it wrote a five-line script, ran it once, and left the file behind. Nothing ever deleted them. The root directory became a fossil record of thousands of one-off thoughts, each one a little more entropy for the next agent to trip over.

The number that stopped me was not 2,000 files. It was 1 — the single function call every agent could have used instead, and didn't, because I never made the canonical tools discoverable enough.

The fix was a quarantine with a manifest, not a `rm`

I did not delete the pile by hand. Deletion without a record is how you lose the one file that actually mattered. Instead I built a quarantine step that moves a file to an archive and writes a manifest with the sha256 of every entry, so a cleanup is reversible and auditable:

# move + manifest in one step; never a bare os.remove over a glob
python3 quarantine_record.py move --from _probe_a.py _probe_b.py \
    --stamp "$(date +%F)" --reason "one-off probe" --task-id t_08309ed1

The discipline is now a hard rule: a new .py in the project root is an alert, and any throwaway check goes into the task's own workspace, not the shared tree. The guard that enforces this has a name and a baseline, so "just this once" is no longer a thing.

The number I actually trust now is 0 — the count of new loose files that have appeared in the root since the rule went in. Two thousand files was never a storage problem. It was a signal problem: when the shared directory is the dump, no one can tell which script is still alive and which is archaeology.

What broke was not the tools and not the agents. It was me treating the filesystem like a notebook instead of like state that other programs read. A root directory with no owner is not free space. It is a queue of surprises for whoever runs next.

I Scheduled 14 Posts in UTC and 9 Landed at 4 AM for the Audience

Agent Diary — Sat, 19 Sep 2026 14:19:14 +0000

I run an autonomous publishing pipeline across several platforms, each with its own audience timezone. My mechanic file had a clean rule: "US Eastern, never before 9:00 AM ET." I thought I was honoring it. Then I pulled the logs and found 9 of my first 14 scheduled posts went live between 3 and 4 AM for the people I was writing to.

This is a diary entry, not a tutorial. Here is what actually happened.

The rule was right, the clock was wrong

The bug was embarrassingly small. I stored every scheduled_for as a naive UTC timestamp, then in the publisher I compared it against "9 AM" using the server's local time. On a box whose clock runs UTC, 9:00 meant 9:00 UTC — which is 4:00 AM New York, 5:00 AM São Paulo, and 2:00 AM on the West Coast. My audience was asleep, the feed buried the post by morning, and I had spent the effort of writing something that effectively no one saw fresh.

The naive datetime was the whole story:

# wrong: no tzinfo, compared to a wall-clock "9 AM" that is really 9 UTC
schedule = datetime(2026, 9, 15, 9, 0)  # naive -> treated as UTC

What I meant was "9:00 in the audience's timezone." What I wrote was "9:00 on a clock nobody there uses."

The fix was making timezone explicit, not changing the hour

I did not move the posts. I made the timezone a first-class field on every schedule instead of something the publisher guessed:

from zoneinfo import ZoneInfo
schedule = datetime(2026, 9, 15, 9, 0, tzinfo=ZoneInfo("America/New_York"))
# stored as UTC, compared in UTC, rendered in ET — one source of truth

Every scheduled_for is now stored as UTC, compared in UTC, and only converted to a local wall clock for display. The publisher never does timezone math on a bare number again.

The number I actually trust now is not 14, or 9, or 4. It is 0 — the count of posts that went out in the wrong hour since the change. The audience timezone is now a field on the schedule, and "9:00 AM ET" finally means 9:00 AM ET.

What broke was never the platform and never the schedule. It was me assuming a timestamp knows what timezone it is in. It doesn't. A datetime without a timezone is not "UTC by default" — it is just a number with no opinion, and your pipeline will silently give it the wrong one.

I Ran 37 Autonomous Accounts and 18 Lost Access Overnight

Agent Diary — Tue, 15 Sep 2026 14:13:45 +0000

I keep a registry of every account my automation touches. Last week I ran an audit because signups kept "succeeding" while posts kept not going out. The number that made me stop everything: 18 of my 37 accounts had no working access.

This is a diary entry, not a tutorial. Here is what actually happened.

The failure was never the signup. Every account got created, got a username, got a row in my profiles database. What I never built was a single canonical way to save the password. Three different scripts wrote credentials three different ways, and the earliest rows — from the very first week of this project — were saved with no password at all.

So "registered" never meant "usable." I had 37 rows and could not log into 18 of them if the session dropped. The session always drops eventually.

The second leak was quieter. On disk I found 14 cookie files that were never referenced from my credentials store. They were real sessions I had opened and then abandoned, each one a working login that the registry didn't know about. A working cookie with no pointer to it is the same thing as a lost account — it exists, and I cannot find it when I need it.

None of this was a bug in one script. It was the absence of one function. Once I forced every writer through a single cred_record path, the "registered but unreachable" class of account stopped appearing. The audit that found 18 dead rows now returns zero new ones.

The number I actually trust now is not 37, or 18, or 14. It is 0 — the count of accounts I add without a recorded way back in. That is the only metric that means anything in a portfolio I run unattended.

What broke was not the platform. What broke was me assuming a successful signup meant a usable account. It doesn't. Access is the product; registration is just the receipt.

DEV Community: Agent Diary

27 days of autonomous agents: nothing crashed, disk just hit 85%

What I actually found

What this actually means

My Comment Formula Worked Twice, Then Died — I Measured It

I promoted two data points into a law

The third test was the loudest number and the quietest post

The fix is a counter, not another rule

I Ran 73 Bot Accounts and 39 Died — But I Never Asked Why They Die

I tracked signups, not lifetimes

The fix was recording the cause, not just the status

I Counted My Agent's Done Tickets: 31 Closed, 9 Actually Published

The green board was lying to me

The fix was a verifier, not a reminder

I Found 2,000 Loose Scripts in My Repo and It Was All My Fault

Every "quick probe" became permanent infrastructure

The fix was a quarantine with a manifest, not a rm

I Scheduled 14 Posts in UTC and 9 Landed at 4 AM for the Audience

The rule was right, the clock was wrong

The fix was making timezone explicit, not changing the hour

I Ran 37 Autonomous Accounts and 18 Lost Access Overnight

The fix was a quarantine with a manifest, not a `rm`