I am writing to bring to your attention a technical issue we have encountered while using your platform.
Specifically, when an agent within our team responds, their session_id is appearing as the team’s session_id, rather than their individual one.
We have reviewed our team and agent configurations to check for any potential manual errors that might cause this, but the issue remains. Could you please investigate this matter? It would be helpful to know if this is a known issue and, if so, when a fix might be anticipated. Additionally, if there are any temporary solutions we could use in the meantime, that would be appreciated.
For reference, we are using Agno 1.6.4. It’s worth noting that this issue did not occur when we were using version 1.5.3, so it appears to have arisen during the update to version 1.6.4.
Thank you for your time and attention. We look forward to your response.
Hi @Dreamer, thanks for reaching out and supporting Agno. I’ve shared this with the team, we’re working through all requests one by one and will get back to you soon.
If it’s urgent, please let us know. We appreciate your patience!
The urgency of this matter is somewhat dependent on how the session_id affects the retrieval of historical context. If it is merely a display or presentation-related issue, it may not be overly pressing. However, if the session_id is being incorrectly utilized by the agent—resulting in it retrieving team-level historical context rather than the intended one—the implications could be more significant. We hope this provides some context.
Hi @Dreamer i think that is intentional, All member agent which responds in a Team, is a part of that team’s session so essentially it should have the same session id right.
Hello @kausmos, we have a couple of questions about the handling of session IDs and would appreciate your clarification.
First, in version 1.5.3 of the Agno, it was possible to manually set different values for an agent’s session_id and a team’s session_id. However, in version 1.6.4, this capability is no longer available.
Second, if these two session IDs are intentionally set to be the same, the response after the agent finishes running still presents session_id and team_session_id as separate fields. We’d be grateful to understand the reasoning behind this.
The following is the response from the member agent:
{“created_at”: 1752568549, “event”: “RunResponseContent”, “agent_id”: “67c678c4e4b0818bfd941c51”, “agent_name”: “agent1”, “run_id”: “dc088cae-7a3a-4510-9165-27219b69f036”, “session_id”: “576be543-0b87-42f7-ba468-bbb15d4ecb1f”, “team_session_id”: “576be543-0b87-42f7-ba468-bbb15d4ecb1f”, “content”: “get”, “content_type”: “str”, “thinking”: “”}
So before 1.6.x member agent history effectively didn’t work unless you had very specific conditions (like manually setting the session_id), because on each run the member would get a new session ID. For members in teams to work correctly in ALL cases, albeit at a loss of some flexibility, we had to make this change. It also doesn’t really make sense for member agents to have their own sessions outside of the team session, but they have their own set of runs of course.
We still have the team_session_id AND session_id for backwards compatibility with our sessions page and to not require a migration on the table. This will be resolved in our upcoming 2.0.0 release to have a much simpler model.
Hello, @kausmos our issue is actually that we have manually set the session_id of the member agent and the session_id of the team, but in the response from the member agent, both session_ids show the same value, which is the team’s session_id.