When an agent hits its usage limit mid-task, the next agent, in the same app or another one, knows nothing about what just happened. It knows only what the previous session wrote down. A shared folder of rules does not change that, because rules are not state.
A recent video promised the opposite. Put one common folder of instructions in the repository, it said, and agents from different apps will pick up each other's work without a gap when one runs out of quota. We checked the claim on 6 November. It does not hold, and the reason fits in one line: AGENTS.md and CLAUDE.md tell a session how to work, not where the last one stopped.
Say the limit hits at 02:14, halfway through a refactor. The session dies. Its context dies with it: what it tried, which tests it ran, which file it was halfway through. A new session opens and reads the rules folder. Now it knows the code style, the test command and the branch policy. It does not know the task is half done.
Anthropic describes the version that works in its engineering write-up on harnesses for long-running agents (November 2025). Every session starts the same way. It reads a progress file (claude-progress.txt in their harness), reads the git log, then picks one unfinished feature and works on that. Continuity is not something the tools provide. The previous session either kept up the habit of writing things down or it didn't.
rules (AGENTS.md, CLAUDE.md) -> how to work -> survives anything, says nothing about now
state (progress log, task list, -> where we stopped -> exists only if the last session wrote it
git commits)
The claim has one true part. A shared instructions file can be read by more than one tool, so rules do travel between apps. That is useful. It is not a handover.
We run krilal board, a task board that models work through on their own. One model executes, another reviews, and the board itself is a git repository: a card is a markdown file, and moving a card is a commit. That makes it a fair test bench for exactly this question.
At one point we had about 27 parallel workers running on one account. The limit cut all of them at once. Then it happened again, right after. No agent handed anything to another agent, because no agent was left to hand it to.
What survived was what had already been written to disk. Workers that saved results as they went left 5 partial batches and 3 partial reviewer verdicts behind, and that work was not lost. We now cap parallel workers at 18.
Keep two numbers apart. About 27 is how many workers went down together. Eight is how many partial results the disk kept. The second number is the whole argument of this piece.
None of these is a product feature. They are rules we keep in our own workers. This is our practice, not a standard.
1. Write partial results to disk as you go. A result that lives only in context disappears when the session is cut. A result in a file gives the next session somewhere to start.
for item in batch:
result = process(item)
append(results_file, result) # written now, not at the end
update(progress_file, last_done=item.id)
2. Commit by path, and leave a note for the next session. A commit is the one record the next session is sure to read. We stage only the files the task touched, so the history shows exactly what this session changed and nothing else. An illustrative example:
git add src/billing/invoice.ts tests/invoice.test.ts
git commit -m "invoice: totals done; rounding still open (see progress.md)"
- [x] totals
- [ ] rounding
- next: run tests/invoice.test.ts first; two cases were failing at stop
3. Keep the alarm outside the agents. This is the one people miss. A thread in r/AI_Agents (21 September) described an account limit that stopped every scheduled task for 19 hours. That included the task whose job was to report failures. In our words, the rule the thread landed on is this: whatever tells you an agent has failed cannot itself be an agent on the same account. The thread's fixes were a heartbeat that runs outside the agents and separate keys for the tasks that must not stop.
agents -> write a heartbeat file every N minutes
watchdog -> plain cron job: no model, separate credentials
-> if the heartbeat is older than 2 x N: send an alert
The watchdog is boring on purpose. It has no model, no shared limit and nothing to run out of.
Suppose a tool shipped real session state: the open task, the last command, the partial output. Suppose an agent from a different vendor could read that state and resume from it without anyone writing it down. Then the claim would hold. We haven't seen this yet. If we do, we will say so here, at the same length.
In our view, handover is a discipline, not a feature. The cost is real but small:
In return, a limit at 02:14 should cost you the last few minutes of work, not the whole night.
Isn't AGENTS.md enough if every tool reads it?
It carries rules from one tool to another. It does not carry where the work stopped. That goes in a progress file and in commits.
Can't the next agent just read the code and work out what was going on?
In our experience, sometimes, partly, and at a cost. Without a note it cannot tell a deliberate half-change from a broken one. A three-line progress entry takes the guessing out.
Why not raise the limit or add accounts?
Limits still hit. On our board, one account cut about 27 workers at once, twice in a row. More headroom changes when the cut happens. It doesn't change what happens to unsaved work.
Who should watch the agents?
Something that is not an agent and does not share their limit: a plain scheduled check with its own credentials that reads a heartbeat the agents write.
How many parallel agents is safe?
It depends on the account and the work. We settled on 18 after two cuts at about 27. Measure your own.
The numbers above come from krilal board. The board's whole record is a git history you can read, blame and revert, and that is why a cut-off session can be picked up at all. The short version of this argument is here: https://www.iloblique.com/blog/shared-folder-does-not-hand-work-between-agents.
If you have agents that need to survive the night, we'd like to hear about it.
Originally published at iloblique.com.