KarstenSamaschke
Zurück zu allen Artikeln

Notizen aus der Praxis

My Agent Now Pauses Its Housekeeping When I Ask a Question

When I asked my agent a question while it was summarizing its own history, the question waited. VanillaCore Harness core #152 now asks that model step to stop if it cooperates, while archive writes and session rotation still run to the end.

Karsten Samaschke · · 8 Min. Lesezeit

My Agent Now Pauses Its Housekeeping When I Ask a Question

Say my agent has been in one conversation for hours and decides it is time to tidy up its memory: it asks the model to summarize the history so the context window has room again. While that summary runs, I type a question into the same chat. Until Wednesday night, my question waited for the housekeeping to finish. The only way to cut it short was /stop, which also stops the running turn and throws away everything queued, my question included.

I think housekeeping that blocks the person it works for is a bug, and last night the VanillaCore Agent Harness got the fix in core pull request #152. The hard part was deciding what may be interrupted at all. A summary is only a model call, so it can be cancelled and tried again later; writing the archive, switching to a new session and seeding it with the handover cannot be cut in half without leaving a broken conversation behind. #152 draws that line, and it took three merges in one evening to get there.

A dark navy desk with a neat stack of blank graphite cards, a pencil laid down beside it and one light-blue card placed in front of the stack, under the headline My question first. Housekeeping later.

Three merges to get there

The work started from a context-maintenance warning the harness had shown earlier, and every pull request of the evening states that the cause of that warning is still unknown. I like that more than a confident root cause that nobody proved. Instead of guessing, the harness's developer agent worked through the problem in steps, and each step said openly what it did not fix.

#150 merged at 21:11 Berlin time. When a handover to a fresh session failed halfway, at the checkpoint or while linking the archive, and was retried, the same handover message could be appended to the new session again. Now the PI adapter reuses an identical one already in place and retries only the step that failed; a different handover is still appended. Its description says in so many words that foreground blocking and backoff remain open.

#151 merged 40 minutes later. A failed recovery was retried on every new message, which meant every arrival could hit the same broken step again. Now each failure sets an earliest time for the next attempt, 1, 2, 4, 8, 16, 32 and then 60 seconds later, and the harness stores that deadline on disk so a restart does not reset it. The retry happens with the next message after the deadline, not in a background job, and the conversation stays closed until recovery succeeds. The pull request also added a test that makes the blocking visible with a deliberately stalled fake compaction: a message for the same conversation waits, a message for another conversation goes through. Its description says that the foreground stall remains open.

#152 merged one hour after that and closes the gap the test had made visible.

What may stop and what may not

When a chat or API message arrives for a conversation whose maintenance is in a model step, the harness now asks that step to stop. Three steps count as model steps: the assessment of whether maintenance is needed, compaction and the summary for a handover. Everything that writes stays serialized, so the archive, the recovery of a prepared handover, the session rotation, the seed and the checkpoint run to the end, and no question skips the recovery check or its retry deadline.

Two panels show what happens when a question arrives for the same conversation during maintenance, from core #152 in v0.1.102. Left, asked to stop: assessment, compaction and the handover summary; they are retried later, and the lock is held until cleanup is done. Right, always finish: the archive write, handover recovery, and rotation, seed and checkpoint; no question skips the recovery check.

A cancelled summary is not thrown away as if it never mattered. If maintenance had been requested explicitly, that request stays pending with its cooldown; automatic maintenance keeps its cooldown and can be chosen again later. Either way, the harness tries again at a later eligible boundary instead of starting a loop in the background. If maintenance was stopped before the original turn reached the model, that turn waits until the question has its answer and then runs without repeating its preparation hook in the same process. If the original reply had already been generated, it is committed as it is and not generated a second time.

The detail I trust most is the one that makes the fix slower. The harness keeps its lock on the conversation until the cancelled operation has actually finished cleaning up, not when it merely acknowledged the request. An adapter that ignores cancellation therefore keeps blocking, and the documentation says why: a quick acknowledgement is not proof that the conversation is usable. For the PI runtime, the pull request also closes a race in which the cancellation could arrive before PI had even installed its compaction controller.

This continues what I wrote about yesterday in Asked a Question, Got a Status Report, where a question moved ahead of queued background work but a running turn was steered and never aborted. The rule is the same in both cases: whatever might already have changed something outside the harness is not cut off, and whatever is only a model call may give way.

What I checked

I copied the three test files that #152 added into the code of v0.1.101, the release right before it, and ran them there. None of the nine tests passed: the six conversation tests failed with the assertion that the question must reach the model while maintenance is still stalled, the two restart tests failed because the old code has no way to interrupt maintenance, and the PI cancellation file ran into my 20-second timeout, because the old adapter never passes the cancellation on to PI and the test waits for it forever. At the end of the window, v0.1.103, the same files plus the stall test and the regression tests of #150 and #151 ran 15 tests, and all 15 passed.

The stall test from #151 still passes at v0.1.103, and that is correct: it calls the maintenance layer directly and never asks it to stop, so it still shows that maintenance for one conversation is serialized. One of the new #152 tests does ask a non-cooperating adapter to stop and checks that the lock stays held until it has settled. All of these are controlled local tests: most use fake sessions, the #150 test runs real PI session plumbing on the local file system, and none of them is a live chat or a real provider. The pull request reports 105 targeted tests passing and a full suite that did not pass, 867 of 870, with the failures documented as existing ones; those numbers are the author's, and I only reran the files named here.

Where it stops

#152 promises cooperative cancellation and not an immediate answer. A custom strategy or adapter that does not honor the cancellation signal still holds the question until it finishes, and the writing steps are never interrupted. The cause of the original warning is still unknown. Across a crash, the existing recovery rules apply, and external effects are not exactly-once. None of this was tested against a live provider or a production compaction.

What merged and what shipped

This post covers 28 October 2026, 20:00, to 29 October 2026, 08:00, Berlin time (CET), which is 19:00 to 07:00 UTC. Core merged four pull requests and published four releases: #150 is first in v0.1.100, #151 in v0.1.101 and #152 in v0.1.102, published at 23:05. The fourth merge, #154 at 06:52, pins plugins pull request #28, merged at 06:33. Together they rewrite the nightly report in which the harness describes its own improvement experiments: it now says in plain words what was there before, what was tried and which evidence or open points remain, it separates local improvements, rejected attempts and unclear results, and it drops the raw JSON receipts. The machine-readable archives stay complete. #154 is in v0.1.103, published at 06:56, and its author reports that the full test suite did not pass. Deployment-base merged nothing.

A release tag is not a deployment. Nothing here says which version any installation runs, and #154 itself states that release and GitOps promotion follow only after the normal merge.

Where I land

An agent that tidies its own memory is doing work for me, and work for me should not make me wait. #152 gets that right without pretending that a half-written handover can be undone, and I would rather have a lock that waits for real cleanup than an answer that arrives in a broken session. What I still want is the cause of that first warning, because this evening fixed what it did to the conversation and not why it happened.

Sources used