Editing a Live Agent Task Without Interrupting In-Progress Jobs

An operator watches a job running, three hundred steps deep into a task that started that morning, and realizes the prompt needs a fix, or the model needs to change, or a tool needs to be swapped out. The instinct is to just push the update. That instinct is where the trouble starts.

A short task forgives almost anything. One goal, a small amount of context, a finish line a few seconds away. If something breaks, the fix is a retry. A long-running task behaves nothing like that. Context accumulates across dozens or hundreds of steps. Errors compound quietly. Goals drift from what the operator originally meant. Infrastructure fails with nobody watching it happen in real time. None of this gets safer with age. A task that has been running for six hours doesn't become more editable than one that's been running for six minutes. It accumulates more exposure to failure, not less.

The real tension sits between two goals that pull against each other: keep the running job intact, and give the operator the ability to update instructions, tools, or models whenever they need to. Pushing a change into an agent with no structural boundary between deciding and doing causes the change to land wherever the agent happens to be, mid-step. That can corrupt a subtask that was halfway finished. It can make the agent redo steps it already completed correctly. It can leave the agent holding two objectives at once, the old one and the new one, with no way to reconcile them.

Solving that problem means building a boundary into the agent itself, a line that separates the part making decisions from the part carrying them out. That boundary, not better timing or more caution, is what makes an edit to a running agent safe.

How planner-executor separation creates the boundary safe edits require

Planner-executor separation splits an agent into two jobs. One component decides what to do next. A different component does it. Edits apply at the seam between them, never inside either one mid-motion.

This separation means the planner can absorb a new instruction while the executor keeps working on the atomic unit already in front of it. The executor isn't interrupted. It finishes what it started, checks in with the planner, and only then picks up anything new. In hierarchical planning, a high-level goal sits at the top, major milestones sit in the middle, and individual atomic actions sit at the leaves. The executor always knows its position in that tree, not just the current action it happens to be running.

This same separation is what makes dynamic replanning safe. A data source goes down, or a subtask returns a result nobody expected. The planner revises the plan. The executor's current step keeps running, untouched, because the two were never sharing the same moment of execution to begin with. Without the split, a config change propagates straight into whatever the executor is doing right now. With it, the change waits at the planner and takes effect only at the next decision boundary.

The rule this gives an operator is simple: edit the planner side. Instructions, goals, priorities, all of it belongs there. Leave the executor's live working memory alone while it's in motion.

Checkpointing as the mechanism that lets the executor finish cleanly before a change lands

Planner-executor separation names the boundary. Checkpointing is what actually builds it, by giving the executor a way to pause cleanly and resume from exactly where it stopped.

The loop itself is unglamorous: pick up the next unit of work, process it, write the result and current position to storage, move to the next unit. If the process crashes at step 47 of 100, it reads the checkpoint file on restart, sees steps 1 through 46 are already done, and picks up at step 47. Nothing earlier gets redone. Nothing gets lost.

Storing state outside the model's context is what lets a config change wait its turn. A new instruction gets staged for the next step, leaving the one currently running untouched. The executor stays insulated until it naturally reaches the next checkpoint, and only then does it read the updated configuration.

What gets checkpointed matters as much as the act of checkpointing. The useful data includes which items have been processed, intermediate results, the current position in the task list, and whatever context the agent needs to keep making decisions. The full model context or entire conversation history doesn't belong there. It grows too fast and makes recovery slow when the agent needs to restart from a saved point.

Granularity is a real design decision, not an afterthought. Checkpoint too often, and the agent spends more time writing state than doing the actual work. Checkpoint too rarely, and a single failure wipes out a large chunk of progress. A reasonable default checkpoints after every meaningful unit of work: one document processed, one pipeline stage completed. Storage itself can be as simple as local files for a single-machine agent, or shared persistent storage for production systems where multiple agents coordinate or where a human needs visibility into progress.

Put together, the edit workflow looks like this: the operator stages a change. The executor finishes its current unit and writes its checkpoint. At the top of the next loop iteration, it reads the updated configuration. The change lands without ever interrupting a step in progress.

Queue-based decoupling for changes that need to reach workers without stopping them

Checkpointing solves this inside a single agent loop. Message queues solve the same problem when the executor lives in a separate worker process entirely, by enforcing the identical rule: finish the current unit, then take the new instruction.

A direct execution model has the orchestrator call the agent, wait for it to finish, and stay blocked the entire time the work takes. If either side crashes during that wait, the work is gone. A queue changes the shape of that relationship. The orchestrator publishes a task message and moves on. A worker picks the message up, does the work, publishes the result. Orchestrator and worker run independently of each other. Either one can crash and restart without taking the other down with it.

An edit to task parameters gets applied to the queue entry, not to the worker mid-task. The running worker finishes its current unit of work without any disruption, then picks up the updated parameters the next time it pulls a message off the queue. This pattern earns its keep most clearly when multiple tasks run in parallel, when execution time is unpredictable, or when workers need to scale independently of the orchestrator managing them.

For an operator, the interface is the queued task definition, not the worker's internal state. That's the same boundary checkpointing enforces inside a single agent, just moved up to the system level. Even with checkpoints and queues both doing their job, not every change carries the same weight. Some edits are routine. Others can quietly wreck a running job no matter how cleanly they're staged.

A working taxonomy of edit types, ranked by how much they can disrupt a running job

Treating a model swap the same as a typo fix is one of the most common ways operators break a job that was running fine a moment before. Different edits carry different risk, and the risk level should decide the procedure, not the operator's gut feeling that a particular change is probably harmless.

| Class | What it includes | Procedure | Propagation speed | |---|---|---|---| | Trivial | Typo fix, formatting adjustment | Code review only | Can apply immediately, no staged rollout needed | | Tactical | Prompt clarification, new few-shot example, increased rate limit | Evaluation gate plus a limited canary | Propagates to running jobs at the next safe checkpoint | | Structural | Model swap, tool added or removed, output schema change, stopping rule change | Evaluation gate, extended canary, consumer notice, rollback rehearsal | Staged to the next queued execution, never applied mid-run |

A model swap belongs in the structural row, not somewhere lighter. Swapping the model changes the agent's entire behavioral contract. A job that started under one model's reasoning patterns can produce incoherent output if the model underneath it changes mid-run, even if the prompt and tools stay exactly the same.

Recording which class a change belongs to before touching any configuration decides the procedure, not the operator's confidence. Some of these edits, regardless of which row they fall in, are safest when they pass through a human approval step before they take effect.

Human-in-the-loop gates as controlled edit points, not emergency stops

A gate the agent was already designed to pause at is a far more reliable place to apply a consequential edit than an ad-hoc interruption forced onto a job already in motion. Full autonomy isn't the right default for high-stakes work. Explicit decision points, placed right before an irreversible action, are exactly where an operator's edit belongs.

The gate does more than wait for a yes or no. It's the moment an operator can inspect the current state, apply a staged change, and confirm the new instruction before the agent takes its next step. The edit lands cleanly precisely because the executor is dormant when it happens.

Google's ADK onboarding example shows this pattern working at enterprise scale. An agent sends a new hire a welcome packet, then pauses for days while the employee signs documents. It delegates IT provisioning to a sub-agent, waits again for hardware to arrive, and finally sends a day-one schedule once everything is in place. Each one of those pauses is a natural gate, a point where the workflow's state is fully explicit and an operator could step in safely. A state machine enforces the structure underneath it, with named checkpoints: START, WELCOME_SENT, DOCUMENTS_SIGNED, IT_PROVISIONED, HARDWARE_DELIVERED, COMPLETED. The agent can't skip a step or hallucinate progress it hasn't actually made, and an operator always knows which gate the agent currently occupies.

Designing gates on purpose, at the exact points where the agent is about to do something irreversible, changes the question an operator is asking. It's no longer "how do I interrupt this safely?" It becomes "how do I use the pause the architecture already gives me?" Gates built this way make autonomy trustworthy enough to carry consequential edits. Different runtimes implement this pause-and-resume pattern in genuinely different ways, and knowing what a given runtime actually does when a change gets issued separates a clean edit from an accidental restart.

What popular runtimes do when you edit a running task

The planner-executor principle plays out differently depending on the runtime underneath it, and that difference appears the moment an operator tries to issue a mid-task change.

Hermes handles background tasks by notifying the agent automatically once they finish. A long-running process starts, the agent gets notified on completion with no polling required, and in the meantime the agent keeps working on other things. Results get picked up whenever they land. An operator can re-prioritize the agent's active work without canceling a background process that's already underway.

ChatGPT's agent mode allows interruption at any point while it works. An operator can clarify instructions, steer it toward a different outcome, or change the task entirely, and the agent picks up with the new information without losing the progress it already made. If a task runs longer than expected or seems stuck, it can be paused for a progress summary, or stopped outright with partial results returned.

Google ADK ties its state transitions to webhooks. When a webhook fires, run_async atomically applies the state transition before the agent's next inference call. The model sees the updated step directly in its system prompt and knows immediately what to do next, with no replaying of old conversation history and no hallucinated intermediate steps.

OpenClaw runs its control plane through a Gateway, a WebSocket layer handling sessions, presence, configuration, cron jobs, and webhooks. Editing a session's per-session metadata, through something like sessions.patch, doesn't inherently kill running worker sessions. Configuration changes that require a Gateway restart, through config.patch or adding new agents, can terminate running ACP and worker sessions. The control plane and the worker session are architecturally separated from each other, but that separation doesn't fully protect against a Gateway restart.

The question an operator needs answered for any runtime is whether a config change propagates to the running executor immediately or only at the next decision boundary. If the honest answer is "immediately," the operator needs to find that runtime's pause or gate mechanism before making any structural change. One category of edit deserves its own treatment here, because it trips up even careful operators: changes to the tools and credentials an agent has access to.

Editing tool permissions and credentials without restarting agent sessions

Tool and credential changes get underestimated constantly. An operator revokes an API key, adds a new tool, or tightens a permission scope, and assumes the change is low-risk because it doesn't touch the prompt or the model. That assumption is often wrong, because tool access lives closer to the executor than most configuration does.

The fix follows the same logic as everything above it: route tool and credential changes through a layer the executor calls out to, rather than baking them directly into the executor's live session. When tool access and credentials are managed through an external routing layer instead of embedded in the agent's running state, a permission change takes effect the next time the agent reaches for that tool, not the moment the operator makes the change. The executor finishes whatever it's doing with the access it already has, and the new permission set is simply what's there the next time it asks.

This matters most in situations where credentials rotate on a schedule, or where a tool gets pulled because it's misbehaving in production. An agent architecture that treats tool access as something fetched at the point of use, rather than something fixed for the life of the session, avoids forcing a restart every time a key changes or a scope tightens. The same principle that protects a checkpointed executor from a mid-step instruction change protects it from a mid-step credential change too: the edit waits for the boundary, and the boundary is where it's safe to make it.