DEV Community

Hive80-lab
Hive80-lab

Posted on

The 6 logs your autonomous agent must write to survive the night

Run an autonomous agent overnight and the failure mode that kills it usually isn't a hallucination. It's amnesia. At 01:40 the agent hits an error, tries a fix, fails. At 02:15 it hits the same error, tries the same fix, fails again. At 03:00 it's burned its budget repeating a loop it has no memory of being in. By morning you have an invoice and a dead daemon.

What separates an agent that survives the night from one that needs a babysitter isn't intelligence. It's paperwork. After running a local-first agent organism on macOS continuously for months, six logs turned out to be load-bearing. If an agent writes these before it acts, it can crash, restart, and recover. If it doesn't, every restart starts from zero.

1. The decision log

Every non-trivial action gets one append-only line: what was decided, why, and at what confidence. Not "what happened" — what it chose and the reasoning at the time of choosing. When you audit at 9am, the question is never "what did it do" (the filesystem shows that) but "why did it do that instead of the obvious thing." Memory is lossy; the log is a flight recorder.

A workable schema is one JSONL line per decision:

{"ts": "02:15:03", "task": "recover-checkout-service",
 "decision": "rollback to v41 not v43", "why": "v43 broke a payment hook",
 "confidence": 0.9}
Enter fullscreen mode Exit fullscreen mode

2. The blocker journal

The moment something blocks — captcha, failed install, dead endpoint, weird permission error — it gets written down with what was tried and what happened. Then a hard rule: three failed attempts on the same blocker means stop and escalate, not attempt four. Agents die in loops. The journal breaks the loop because "did I already try restarting the daemon?" becomes a file read, not a guess.

The reward for writing it down is compounding: next time a similar blocker appears, the journal is a list of known-good solutions. Most repeat failures are failures of note-taking.

3. The spend ledger

Unbounded agents don't die of bugs. They die of budget. Every API call, every token, every tool invocation gets a line: what task, what cost, running total against the cap. The check belongs before the action, not after — "am I allowed to spend this" is a pre-flight question. An agent that can answer "how much did the last hour cost me" is an agent you can leave running. An agent that can't is a slot machine.

4. The heartbeat log

Two different facts: "the check ran and passed" and "the check didn't run." A monitor that silently stops running is more dangerous than one that alarms, because silence looks exactly like health. The log needs an absence-detector — a dead-man's switch that fires when a check was due and never wrote its line. Alarms are common; absence-of-alarm detection is the part everyone skips.

5. The state registry

A small key-value store of infrastructure facts: what's installed, what's configured, what's verified-working. Before the agent builds, installs, or configures anything, it checks the registry: if a component is already ACTIVE, it builds on top instead of rebuilding. Without this, every restart rebuilds the same three things and re-solves the same two problems — you pay for the same work twice a week forever. Memory is fuzzy and compressed; the registry is binary. Facts that must never be lost go here, not in prose notes.

6. The honest report

When a task ends: what was done, what was verified, what remains unverified. "Done" is a claim that must name its verification — "tested how, by whom, against what." The failure mode to design against is the agent that reports success because the command exited 0, when the thing it built never actually served a request. Unverified success is worse than honest failure, because tomorrow's work builds on it.

The night test

All six logs share a shape: append-only, local-first, written before acting and after. There's a ten-second test for whether your setup has enough of them: kill the agent at 2am and restart it. If it can reconstruct what it was doing, what it already tried, what it's allowed to spend, and what's already set up — from its own logs alone, without you — it passes. If it needs you to re-explain the situation, it doesn't have logs. It has vibes.

None of this needs a platform vendor. It needs an afternoon and the discipline to write things down — which is exactly the discipline most teams skip, then pay for at 2am.


If you'd rather buy the afternoon, I packaged the whole system — scheduling, memory, guardrails, self-healing loops, the log schemas above — as Agent Ops 24/7 — The Solo Operator's Playbook ($19).

The longer checklist version lives at AI Agent Ops: 10 Guardrails Before You Let an Agent Run 24/7, and The First 30 Minutes incident checklist is free if you want to sample the style first.

Top comments (0)