Is your feature request related to a problem? Please describe.
In interactive and multi-agent applications, an agent may remain active for a long time while generating responses, executing tools, or progressing through multiple steps. During that execution, a user, supervisor agent, workflow, or external system may need to provide new context, correct an instruction, or change the agent’s priorities.
Without a first-class runtime messaging mechanism, applications must either wait for the execution to finish, cancel and restart it, or implement a custom side channel with their own queues, synchronization, delivery semantics, and lifecycle handling.
This makes message steering difficult and error-prone, especially for long-running agents, tool loops, and multi-agent coordination. It also prevents an active agent from responding naturally to updated instructions until its current execution has completed.
Describe alternatives you've considered
The main alternatives are:
- Waiting for the current execution to finish before sending additional input.
- Cancelling the active execution and starting a new one with the updated instructions.
- Building an application-specific side channel using an event emitter, message queue, database, or WebSocket connection.
- Writing steering messages into conversation memory and having the agent poll for changes between steps.
Waiting does not support interactive steering, while cancelling and restarting loses progress and may repeat completed tool calls. A custom side channel requires every application to reimplement message targeting, ordering, synchronization, persistence, observability, and execution lifecycle handling.
Using conversation memory as a queue also mixes two different concerns: durable conversation history and pending messages that have not yet been consumed by an active execution.
Additional context
The primary use case is steering a long-running agent after its execution has already started.
A message arriving during an in-flight model request or tool call does not need to modify or interrupt that operation. It can remain queued and become visible at the next documented safe boundary, such as before the next model step or after the current tool call completes.
This proposal is intended as a VoltAgent orchestration capability. It should not introduce a parallel generation API, replace conversation memory, or redefine the underlying AI SDK behavior.
Describe the thing to improve
Add a first-class, transport-agnostic inbox for VoltAgent agents and active executions.
Users, supervisor agents, workflows, and external systems should be able to send messages to an agent while it is running. VoltAgent should queue those messages and make them available at documented safe boundaries, such as before the next model step or after a tool call completes, without cancelling or restarting the execution.
The inbox should provide clear targeting, ordering, delivery status, lifecycle events, and behavior for completed or unavailable executions. It should remain separate from conversation memory and should not attempt to modify a model request or tool call that is already in flight.
This would provide a reusable foundation for message steering, supervisor/worker coordination, long-running agents, and multi-agent communication.
Is your feature request related to a problem? Please describe.
In interactive and multi-agent applications, an agent may remain active for a long time while generating responses, executing tools, or progressing through multiple steps. During that execution, a user, supervisor agent, workflow, or external system may need to provide new context, correct an instruction, or change the agent’s priorities.
Without a first-class runtime messaging mechanism, applications must either wait for the execution to finish, cancel and restart it, or implement a custom side channel with their own queues, synchronization, delivery semantics, and lifecycle handling.
This makes message steering difficult and error-prone, especially for long-running agents, tool loops, and multi-agent coordination. It also prevents an active agent from responding naturally to updated instructions until its current execution has completed.
Describe alternatives you've considered
The main alternatives are:
Waiting does not support interactive steering, while cancelling and restarting loses progress and may repeat completed tool calls. A custom side channel requires every application to reimplement message targeting, ordering, synchronization, persistence, observability, and execution lifecycle handling.
Using conversation memory as a queue also mixes two different concerns: durable conversation history and pending messages that have not yet been consumed by an active execution.
Additional context
The primary use case is steering a long-running agent after its execution has already started.
A message arriving during an in-flight model request or tool call does not need to modify or interrupt that operation. It can remain queued and become visible at the next documented safe boundary, such as before the next model step or after the current tool call completes.
This proposal is intended as a VoltAgent orchestration capability. It should not introduce a parallel generation API, replace conversation memory, or redefine the underlying AI SDK behavior.
Describe the thing to improve
Add a first-class, transport-agnostic inbox for VoltAgent agents and active executions.
Users, supervisor agents, workflows, and external systems should be able to send messages to an agent while it is running. VoltAgent should queue those messages and make them available at documented safe boundaries, such as before the next model step or after a tool call completes, without cancelling or restarting the execution.
The inbox should provide clear targeting, ordering, delivery status, lifecycle events, and behavior for completed or unavailable executions. It should remain separate from conversation memory and should not attempt to modify a model request or tool call that is already in flight.
This would provide a reusable foundation for message steering, supervisor/worker coordination, long-running agents, and multi-agent communication.