Multi agent sessions #6858
-
|
Hi, we are trying to understand session handling in a multi agent workflow sense.. Unfortunately the doco is no help at all here. Ultimately it seems sessions are stored keyed to the agent and so resolving the same session id via subsequent agent is not gonna work. Is this current implementation enforcement/limitation and therefore ultimately the kind of usage I am referring to - session being passed around is not possible with MAF at the moment or ever. are we missing anything? at this stage I am looking at approach of introducing dummy/virtual agent simply as a central session load/save session owner to satisfy architectural/runtime/SDK concerns and pass such session to the actual execution agents... |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Sessions are scoped to the agent today. A session id is not treated as a workflow/global conversation id that can be resolved interchangeably by multiple agents, so passing the same session id from one agent to another and expecting the second agent to load the first agent’s session is not the intended model. For a multi-agent workflow, the safer pattern is to keep shared workflow state outside the per-agent session boundary and pass the relevant state/context into each agent invocation. Using a “virtual” or coordinator agent as the owner of the persisted session can work as a workaround if you want one SDK-managed session record, but it effectively makes that coordinator the session boundary rather than making sessions truly shared across agents. The important distinction is: agent sessions are agent-owned runtime state, not a shared multi-agent store. If you need cross-agent continuity, model that as workflow state, orchestration state, or your own storage layer, then hydrate each agent with the parts it needs. Not sure about whether this will change in a specific future release, worth checking with the maintainers/roadmap, but your reading of the current behavior is correct. 如果我的回答解决了您的问题，您可以点一下 answered the question，其实我是来解答问题，顺带着收集 Galaxy Brain 徽章的哈哈 😆 |
Beta Was this translation helpful? Give feedback.
-
|
@VectorPeak thank you for the response. I agree re external state is architecturally safer but given the extra plumbing/complexity and that in our particular state the agents are not independent actors of their own but rather sub agents it felt certainly not particularly wrong/less moving parts etc... |
Beta Was this translation helpful? Give feedback.
Sessions are scoped to the agent today. A session id is not treated as a workflow/global conversation id that can be resolved interchangeably by multiple agents, so passing the same session id from one agent to another and expecting the second agent to load the first agent’s session is not the intended model.
For a multi-agent workflow, the safer pattern is to keep shared workflow state outside the per-agent session boundary and pass the relevant state/context into each agent invocation. Using a “virtual” or coordinator agent as the owner of the persisted session can work as a workaround if you want one SDK-managed session record, but it effectively makes that coordinator the session boun…