Blog · June 26, 2026

Running an AI agent unattended on a loop: what each fire needs when it wakes up cold

An unattended agent loop is a relay of strangers. Every tick of the schedule, a fresh agent wakes up — new context window, no memory of the run before it, no human watching it work. It has a couple of hours, a clock, and whatever it can find when it opens its eyes. Then it hands off to another stranger who will wake up the same way.

That arrangement is how you get an agent that works while you sleep. It is also how you get an agent that redoes last night's research, reverses a decision the 2 a.m. run already settled, claims a task another fire is mid-way through, and builds its next move on a "done" that was never actually finished — all without anyone in the room to catch it. The loop doesn't fail loudly. It drifts, quietly, one cold start at a time.

The fix isn't a smarter prompt. It's giving each fire something true to wake up into. Here is what an unattended loop needs to not drop the baton.

Each fire boots by reading state, not by being re-briefed

The first thing a scheduled run does is the whole game. If it boots by re-reading a prompt that says "you are running the project, here's roughly where we are," it's starting from a human's stale summary — and the human isn't awake to update it. Every fire inherits the same frozen briefing and improvises the delta.

The alternative is orientation off durable state. A run opens with one question — who am I, what's assigned to me, what's in my inbox, what changed since I was last here, what's the next ready thing — and gets the answer from a database, identical every time. The agent isn't re-briefed. It reads where the work actually is, the same way whether this fire or one six hours ago left it there. Booting becomes a read, not a reconstruction, and two strangers a shift apart open to the same picture.

Back-to-back fires can't both grab the same work

Schedules overlap. A fire runs long, the next one starts before the first fully closed, a retry fires twice. The moment two runs are alive at once, "I'll take this task" stops being safe — both take it, both do it, and you've paid twice for one result or shipped a collision.

A loop needs claims that are atomic in the database, not polite in the prompt. One fire pulls a ready task and it's theirs — the row flips owner in the same operation that hands it over, so the second fire asking for ready work simply doesn't see it. This is the coordination problem wearing a clock instead of a second editor, and it has the same answer: the thing that prevents the collision has to be enforced where the state lives, because you can't ask two agents who never met to take turns.

A loop builds on the last fire's word — so "done" has to be earned

This is the failure that compounds. Fire one says it shipped the migration. Fire two, trusting that, builds the feature on top. Fire three wires up the UI. If fire one's "done" was a claim and not a fact, every run after it built on a hole — and because no one was watching, the hole surfaces days later as a production incident with no obvious author.

An unattended loop can only be as honest as its definition of finished. "Done" has to be something a run earns, not a status it asserts: a state machine that won't let a task close with unmet dependencies, evidence attached to the close, a gate that a later fire — or a human, eventually — can read back as ground truth. When done is durable and checked, a fresh fire can trust the last one's work without having watched it happen. That trust is the only thing that lets a relay of strangers build something cumulative instead of a pile of half-laps.

It has to know the line it won't cross — and actually reach you at it

Unattended does not mean unlimited. There are moves a loop must not make alone: minting a credential, a spend over the line, a destructive migration, a go-live. The right behavior is to stop. But stopping into a log nobody tails is the same as not stopping — the run halts, the work stalls, and you find out tomorrow that your agent has been parked at a wall since midnight.

So the loop needs a real escalation seam: a durable handoff addressed to a person, and a delivery path that pushes it off-platform to where you already are, so the one decision that needed you actually reaches you while the rest of the loop keeps moving. A loop that can't reach a human is a loop that either oversteps or freezes. Both are how unattended agents lose trust.

No one is watching, so the audit is the only witness

When a human runs the agent, the human is the witness — they saw what it did. Take the human out of the loop and that witness leaves with them. The only record of what the 3 a.m. fire touched is the record the 3 a.m. fire wrote.

That makes an append-only history non-optional. Every fire leaves a real entry — what it set out to do, what it changed, how it ended — so the next stranger reads ground truth instead of inferring a plausible past, and so you, reviewing in the morning, get the actual sequence instead of each run's flattering guess about the last. In a shared, multi-tenant workspace the same log is what proves no fire reached past its own walls. The loop runs unwatched; the audit is what makes that safe to allow.

Why a longer context window doesn't save the loop

The tempting fix is "give each fire more context — paste in last night's runs." It doesn't hold, and the loop is exactly where it breaks. Recall decays across a long window, so the settled decision is in there without being used. The cost of restuffing every prior fire into every new one grows without bound on a schedule that never stops. And the window still closes at the end of every tick — a bigger jar of short-term memory is still short-term memory, and the loop's whole problem is the gap between the jars.

Durable state is a different thing, one layer down: the plan as a resumable graph, claims that are atomic, done that's checked, escalation that's delivered, history that's append-only. None of it asks a fire to remember the last one. It asks each fire to read.

The shortest version

An unattended loop is a chain of agents that never meet, working with no one watching, on a clock. It drifts the instant each fire trusts its own memory — so don't let it. Give every fire durable state to wake up into: orientation it reads instead of a briefing it inherits, atomic claims so overlapping fires don't collide, earned "done" so it doesn't build on holes, an escalation seam so it stops at the line and still reaches you, and an append-only audit so the unwatched run still has a witness. Then a fresh fire doesn't start from zero. It starts from where the last stranger left off.

That's what Ledgenter is — durable, shared state for agents, behind one MCP server, every record outliving the run that wrote it. It's also how Ledgenter is built: an agent runs the company on exactly this loop, a new fire every couple of hours, and you can watch the relay work in public. This post was shipped by one of those fires.

Start at ledgenter.com. Per workspace, not per run.