Subagents are useful for dispatching throwaway threads or performing operations concurrently, but they don't exactly map to bound's threading model. The nearest equivalent is tasks - an agent can dispatch one or more tasks in the background and may or may not wait on their results; the created task is decoupled from its "parent." However, this has proven to both be relatively fragile for workloads that do need parent/child relationships (the agent sometimes dispatches a task and assumes it will be woken when it completes, but the created task's instance of the agent just doesn't do it), and it doesn't work at all in boundless, which only permits creating tasks that are not client-bound, meaning they can only perform work in the Main Station, not in the current Satellite Station. This isn't only a matter of binding those tasks to the client; it is also an implicit requirement that we have a parent/child relationship as boundless threads are effectively locked to the lifetime of the client process (they aren't really, but they can only perform Satellite work when a client is attached).
Subagents also have other problems in a persistent agent, in particular regarding memory and persona consistency. A subagent is inherently subordinate to its parent, but in bound, all tasks/threads share a single identity: They are all views of a single agent that spans them. This framing is challenged by subagents, as if an agent is dispatching subagents that are themselves instances of the leader, those threads are no longer peers in a literal sense. An agent needs to dictate instructions to another instance of itself and throw away that instance when it is done; it needs to receive instructions from another instance of itself and know that it will be discarded when it is done. That difference in authority means that some threads are told they are peer "views" when in fact they are not, and cannot be. Once we have an identity split like this, memory gets complicated, because the meaning of a memory might be different from the context of the parent or the child - what happens if a subagent reads a memory that describes a workflow that ends in discarding itself?
To solve all of those problems, I propose a concept of "auxiliary agents" - these are effectively scoped agents with their own memory namespace that cannot read the main agent's memory, while the main agent is able to both read and write the auxiliary agents' memories. Auxiliary agents have a distinct identity and can be instantiated on-demand, and their threads have a strict parent/child relationship with the main agent's thread that dispatched them.
Supersedes #25.
Subagents are useful for dispatching throwaway threads or performing operations concurrently, but they don't exactly map to bound's threading model. The nearest equivalent is tasks - an agent can dispatch one or more tasks in the background and may or may not wait on their results; the created task is decoupled from its "parent." However, this has proven to both be relatively fragile for workloads that do need parent/child relationships (the agent sometimes dispatches a task and assumes it will be woken when it completes, but the created task's instance of the agent just doesn't do it), and it doesn't work at all in
boundless, which only permits creating tasks that are not client-bound, meaning they can only perform work in the Main Station, not in the current Satellite Station. This isn't only a matter of binding those tasks to the client; it is also an implicit requirement that we have a parent/child relationship asboundlessthreads are effectively locked to the lifetime of the client process (they aren't really, but they can only perform Satellite work when a client is attached).Subagents also have other problems in a persistent agent, in particular regarding memory and persona consistency. A subagent is inherently subordinate to its parent, but in bound, all tasks/threads share a single identity: They are all views of a single agent that spans them. This framing is challenged by subagents, as if an agent is dispatching subagents that are themselves instances of the leader, those threads are no longer peers in a literal sense. An agent needs to dictate instructions to another instance of itself and throw away that instance when it is done; it needs to receive instructions from another instance of itself and know that it will be discarded when it is done. That difference in authority means that some threads are told they are peer "views" when in fact they are not, and cannot be. Once we have an identity split like this, memory gets complicated, because the meaning of a memory might be different from the context of the parent or the child - what happens if a subagent reads a memory that describes a workflow that ends in discarding itself?
To solve all of those problems, I propose a concept of "auxiliary agents" - these are effectively scoped agents with their own memory namespace that cannot read the main agent's memory, while the main agent is able to both read and write the auxiliary agents' memories. Auxiliary agents have a distinct identity and can be instantiated on-demand, and their threads have a strict parent/child relationship with the main agent's thread that dispatched them.
Supersedes #25.