How do I run AI coding agents 24/7?

Any long-lived process works: tmux for an interactive agent, cron plus print mode for one-shot runs, RPC mode for programmatic control, or an SDK daemon. The runtime is the easy part — the work pipeline is what actually needs building.

Why do multiple AI agents break each other's work in git?

Without shared plans and reasoning, the agent that lands last silently rewrites another agent's feature and its tests, and reports success. In ~300 runs this happened in 24-28% of plain-git runs; per-agent branches, plan files, Why lines and a pre-push gate reduced it to 0%.

What jobs can AI agents do autonomously overnight?

Jobs where done is machine-checkable: bug fixes with failing repro tests, test coverage expansion, dependency upgrades, small fully-specified features, and triage. Open-ended direction setting should stay human-approved.

Should autonomous agents push directly to main?

Only behind a landing gate: every overlap with other agents' work needs a recorded agreement, their tests must pass, and unresolvable decisions must be flagged as overrides for human review rather than resolved silently.

What is a definition of done for AI agent work?

A machine-checkable condition, usually an acceptance test that goes red to green while the full suite stays green. Anything that requires human taste at 3 a.m. is not done-checkable and should be queued as a proposal, not landed.

Agents While You Sleep: What Actually Breaks Overnight

Every developer building with AI agents has had the same 3 a.m. fantasy. You go to sleep. A fleet of agents picks through your backlog, fixes bugs, builds features, and in the morning you review a stack of small, tested, well-explained changes. On bad mornings, you review one disaster and you're glad you caught it.

I've been trying to make this real, and I've learned an obvious-sounding thing the hard way: keeping the agent process alive is trivial. The work pipeline is the actual problem.

The runtime is a weekend project

There are four ways to keep an agent running around the clock, and none of them is hard:

tmux — an interactive agent survives disconnects and SSH logout
cron + print mode — pi -p "check the failing tests" on a timer, one-shot runs that exit cleanly
RPC mode — a long-lived process another program talks to
an SDK daemon — embed the agent in your own Node process and loop over a queue

Any of these runs for seventy-two hours straight without complaining. And none of them will produce a single useful commit. Because the question was never "how do I keep the process alive?" It's:

what does the agent work on?
what does done mean?
how does the work land?
how do multiple agents avoid clobbering each other?

Call these four things the task source, the definition of done, the landing gate, and the allocator.

What ~300 runs taught me about the clobbering part

I'm building gitaccord, git hooks that let several AI agents work on one repo in parallel. It exists because of a failure I saw repeatedly in experiments: give multiple capable agents the same repository and let them pick features and land their own work with plain git — no central human merge authority. Agents resolve merge conflicts fine. That's not the danger.

The danger is the agent that lands last quietly rewriting another agent's feature to fit its own, adjusting the tests, and reporting success. In our spike, across roughly 300 runs with Claude Code (Sonnet) and pi (GLM), that happened in 24–28% of runs on plain git. No malice anywhere. Each agent did exactly what a well-behaved solo agent should do. The failure was structural: the agents couldn't see each other's plans and reasoning, so "merge" silently became "overwrite."

gitaccord's fix is boring on purpose. One branch per agent. A plan file per task that every agent reads. A Why: line on every commit explaining the reasoning. A pre-push gate that refuses to land any change that breaks another agent's feature unless it's declared as an Override: for human review. In the same ~300 runs: silent overrides went to 0%, main was never left broken, and every no-win decision got flagged for a human instead of resolved silently.

So of the four pieces, I'd argue the landing gate and allocator are solvable — mostly with conventions and hooks, not new platforms.

Which jobs actually work overnight

The constraint isn't the agent's capability. It's whether done is machine-checkable. A sleeping human can't be asked "is this the feature you meant?" at 3 a.m.

What works:

Bug fixes with a failing repro. Red test turns green, full suite passes, diff is small.
Test coverage expansion on existing code — coverage up, behavior provably unchanged.
Small, fully-specified features sliced out of a human-written plan.
Dependency upgrades, where the suite decides.
Triage — reproduce a bug report, write the failing test, draft the fix on a branch. It doesn't even need to land.

What doesn't work overnight — and this is where many 24/7-agent dreams quietly die:

"Figure out what to build next." Open-ended direction has no machine-checkable done. There's a right shape for it though: an agent writes a proposal + spike + failing acceptance test on its branch and doesn't land it. You approve direction in the morning. Landing autonomy was always the easier problem; direction autonomy is the one you should keep.

The overnight loop

What the whole thing looks like when it works:

evening            night                               morning
─────────          ──────────────────────────────      ──────────────
human writes/      agent picks task N                  human reads a digest:
prunes backlog ──▶ writes its plan                    ▸ what landed
                   implements, tests, commits          ▸ flagged overrides &
                   merges main, passes the gate          no-win decisions
                   repeats for task N+1 …              ▸ proposals awaiting direction

The rules that keep it alive until morning:

Small tasks. Long autonomous runs rot from context drift. One bug per task, one slice per feature.
Bounded autonomy. A cap per night, a budget per run, per-agent branches. A failed task gets recorded and the loop moves on instead of thrashing.
One output you must read: the flag queue. The system's job is to make that queue short and high-signal — the Override:s and no-win decisions — so your morning review is minutes, not hours.

Notice where the hard engineering lives, though. A daemon loop is a hundred lines. The backlog format, the allocator, the digest generator — that glue between human direction and agent execution is the real build. Almost nobody has productized it, because everyone (me included) keeps getting stuck polishing the agent runtime instead.

Where I am, honestly

I don't have the overnight loop running yet. I have the hard middle part in progress: the hooks and conventions that stop agents from destroying each other's work when there's no human gate. The runtime options are sitting there ready. The missing piece is the boring pipeline — and my plan is to run it on gitaccord itself first: the backlog of porting each hook from spike to real implementation writes itself, and if overnight agents break something, my own landing gate is the cheapest possible place to learn that.

What I'd love from you

If you've tried running agents unattended — or decided not to — I want to hear where it broke:

What's your job source? Backlog files, GitHub issues, something else?
What did your definition of done look like, and did agents find loopholes in it?
Did you let work land to a main branch, or queue it for morning review?
Has anyone shipped a good task allocator / digest tool, or is everyone hand-rolling this?

The runtime wars are over. The pipeline is where this is won or lost.

Agents While You Sleep: the Runtime Is Trivial, the Pipeline Is Hard