An agent is reviewing a pull request, comparing an architecture document, or running a research plan. Halfway through, the user sends: “Focus on the database migration instead.” A minute later: “Also write a summary for the team.” Then: “Stop—do not touch the production configuration.”
If all three messages are treated as the same kind of event, the runtime is left with two coarse choices: inject them immediately and risk destabilizing active work, or wait until the agent becomes idle and risk frustrating the user.
One design starts by recognizing that a new message has two separate properties:
- It has been durably accepted.
- It has a delivery policy.
In this proposal, acceptance is immediate and durable, while delivery follows an explicit policy. Virillio Code Editorial uses steer, queue, and interrupt as product and runtime terms; they are design choices, not standardized agent-delivery semantics.
LangGraph’s persistence documentation shows how checkpointed state can support continuation and fault tolerance, while Anthropic’s long-running harness account emphasizes structured handoffs between sessions. Neither source defines the three delivery modes proposed here.
A message is not a scheduling policy
Long-running agent systems often model all user input as another line of chat history. That is sufficient for short conversations, but it breaks down when an agent is in the middle of a multi-step plan. A message can mean at least three different things:
- Change the current work as soon as it is safe.
- Ask for a separate task after the current work settles.
- Stop the current work now.
Under this model, those messages request different state transitions. A runtime can persist that difference rather than asking a language model to infer scheduling intent from the latest prose.
A proposed three-mode taxonomy
The following vocabulary is one way to make delivery policy visible in both a product surface and its runtime.
- Mode: Steer — User intent: Reorient the active task — When it becomes model-visible: At the next safe provider-turn boundary — What it must not do: Silently rewind completed work
- Mode: Queue — User intent: Request a follow-on task — When it becomes model-visible: When the agent would otherwise become idle — What it must not do: Starve the active task indefinitely
- Mode: Interrupt — User intent: Stop or cancel active work — When it becomes model-visible: As soon as the execution-control layer can cancel safely — What it must not do: Pretend completed external actions can be undone automatically
Steer: change direction without tearing down state
A steer is a user message that should influence the agent’s next reasoning turn. It might narrow scope, correct an assumption, set a constraint, or ask the agent to prioritize a different part of the same task.
The important phrase in this design is *next reasoning turn*. A steer should not be injected in the middle of a provider request or while a tool call is being settled. Instead, the runtime admits the steer at a safe provider-turn boundary: after relevant tool work has finished and before the next request is sent to the model.
This keeps chronology comprehensible. The model receives the user’s new direction at a point where it can actually act on it. The runtime can record exactly when the instruction became effective. And a future recovery does not have to guess whether a response was generated before or after the steer arrived.
Queue: preserve a real follow-up
A queue input asks for more work, but not necessarily for a context switch. “After this, draft a migration guide” is different from “stop investigating the frontend and look at the migration now.”
Queueing matters because an active agent may have a good reason to continue: it might need to settle a tool call, finish a bounded investigation, or close a plan step before it can safely move on. In the proposed policy, the runtime retains the follow-up durably and promotes one queued item when the current task would otherwise become idle.
Promotion one at a time is a small but useful rule. It prevents the system from turning a user’s backlog into a sudden flood of unrelated instructions. After one queued item becomes visible, the runtime can reevaluate whether the agent now needs continuation before promoting another.
Interrupt: stop execution, not history
An interrupt is not a more urgent steer. It is a control action: stop the active execution ownership chain as soon as the runtime can safely do so.
The distinction matters for truthfulness. Interrupting a provider stream or cancelling a local coordinator can prevent future work. It cannot automatically undo a tool call that already changed the outside world. A good agent UX therefore reports what was stopped, what had already completed, and what may need human follow-up.
Treating interruption as an explicit mode also prevents a dangerous product pattern: burying cancellation requests among ordinary chat messages and hoping the model interprets them in time.
Safe boundaries are a product feature
“Safe provider-turn boundary” sounds like runtime jargon, but users experience it as responsiveness they can trust. A useful boundary has three properties:
- Previously initiated tool work is settled or has a clear failure state.
- The runtime knows which user inputs are eligible to promote.
- The model receives a coherent next context, rather than a mixture of old plan state and new instructions.
That boundary is also where context engineering and delivery semantics meet. Anthropic’s guidance on long-horizon tasks recommends compaction and structured notes rather than indiscriminate context accumulation. The same discipline can apply to user intervention: present an eligible instruction at a coherent decision point instead of adding text at an arbitrary moment.
The admission log is the source of truth
No delivery mode works well if it exists only in memory. The runtime should record an input before waking execution, including its identity, session, body, and mode. A wakeup can be coalesced or lost because the durable inbox remains authoritative.
This gives the system several valuable properties:
- A user can retry an exact submission without creating an ambiguous duplicate.
- A restarted process can discover pending steers and queued tasks.
- The UI can show that an instruction was accepted even if the agent is temporarily unavailable.
- The agent’s history can explain *when* an instruction became visible, rather than merely when it was typed.
This is not a claim that every provider turn is replayable. It is a promise that the user’s input will not disappear because the current executor did.
A decision checklist for product teams
Before adding a “send message to agent” box to a long-running workflow, decide:
- What happens if the agent is currently using a tool?
- Which messages steer the current task, and which are follow-up tasks?
- Is cancellation a distinct control action?
- How does the UI communicate accepted, pending, promoted, and completed states?
- Can a restarted runtime reconstruct pending inputs and their modes?
- What external side effects may already have happened if the user interrupts?
These answers should be visible in the system model, not buried in a prompt template.
What we are learning building Virillio Code
Virillio Code’s session and delivery work remains in development. The current design direction treats durable input and scheduling as separate concerns so a session can accept steering without turning every message into an interruption, and so follow-up work can remain pending without being discarded. This taxonomy describes that design direction, not a published interoperability standard or a guarantee of current product behavior.
The general lesson is simple: for long-running agents, “message received” is not enough. Users need to know whether they redirected the work, added the next task, or stopped the current execution—and the runtime needs those distinctions even more than the UI does.
Sources and further reading
- LangGraph persistence — Checkpoint persistence supports continuation, recovery, memory, and fault tolerance in agent workflows.
- Harness design for long-running application development — Long-running work benefits from structured handoffs and decomposition.
- Effective context engineering for AI agents — Long-horizon agents need curated context and deliberate transitions.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.