Make background work yield to the user

A background agent may be midway through changing a file when the person returns with a more important request. Telling it to “pause” is insufficient if it cannot say which operation has finished, which result has been saved and whether another worker can safely use the current files.

In January, I proposed idle self-improvement for Magellan, an assistant I was customizing. I defined idle time as a period without a request and said the improvement loop should pause when I returned. I also said the assistant did not yet act very autonomously. The record supports the desired behavior, not a demonstrated persistent self-improvement system.

The proposal makes availability part of the design. Useful background work should not prevent the person from directing the assistant, and interruption should not leave a new request dependent on unexplained half-finished changes.

A request arrives during a render check

Consider an illustrative agent improving a local document formatter. It has read a test file, prepared an edit and started a render check. A new user request arrives before the check completes.

The agent needs to distinguish cancelling the next task from terminating the current operation. Stopping between tasks may be safe. Killing a write midway through replacing a file may leave a corrupted artifact, while interrupting an external submission can leave the outcome uncertain.

A practical design uses isolated working copies and bounded operations. The agent can finish a local write, record that the render check is unfinished and release the working state without claiming that the new version is ready. The user’s new request should not automatically consume an unreviewed draft merely because it is the most recent file.

The exact behavior depends on the tool. Some operations support cancellation; others return only after completion. State that limitation in the design and test it in a harmless setting before relying on it during consequential work.

During the interruption test, inspect the working directory from a fresh process that has no access to the earlier conversation, because that process approximates the information available when a later worker must recover the unfinished task. If it cannot identify the last accepted output and the separate unverified draft from the saved record, revise the record and repeat the pause before relying on conversational memory to reconstruct which file is safe to deliver.

Resuming from the saved record

The pause record should identify the task, the current artifact version, completed checks and the next unresolved condition. It should also say whether any external action was attempted. A conversational summary such as “almost finished the formatter” leaves too much for the next run to infer.

On resumption, inspect the saved artifacts and relevant external state before repeating work. If the previous operation created an output file, verify that file rather than assuming the interruption prevented creation. For a side effect such as submitting a form, uncertainty about completion requires reconciliation before retrying.

The background task may also have become irrelevant. A new user instruction can change the desired format, cancel the project or replace the implementation approach. Resumption should check the current request instead of treating the earlier plan as permanent authority.

Scope and interruption tests

Idle time alone does not authorize arbitrary improvement. Specify which project the agent may inspect, which changes it may prepare and which actions require another decision. Reading a test fixture and preparing a local patch have different consequences from publishing a release or contacting somebody.

Resource limits matter as well. Background work should not consume the entire machine or use an unbounded service budget while the person is trying to do something else. Set the relevant limits and report when they prevent further progress.

A useful interruption test starts the harmless formatter task, pauses it at several known stages and checks the saved state after each pause. Resume from the record and confirm that completed operations are not needlessly repeated. Then change the task’s requirement before resumption and verify that the worker notices.

The design is ready for broader use only after those tests show that a new request can take priority without losing the identity of the unfinished work. Keep the paused artifact separate from the accepted output until its remaining checks have run against the version that will actually be delivered.

Source notes

Drew Wiberg, Magellan idle-improvement requirements, 31 January 2026. Contemporary author records distinguish existing customization from proposed autonomy.

Worked examples and review procedures in this article are instructional applications, not additional historical project results.