[Agent] Introduce "session" - POC

[Guikingone]

Q	A
Bug fix?	no
New feature?	yes
Docs?	no
Issues	Improve #239
License	MIT

Hi 👋🏻

A small POC for the "session" that we discussed in #239, this PR is a WIP (and even more than a WIP, an open discussion 😅 ).

Here's the current state:

• Agent refactoring - Done
• Chat refactoring - Not needed IMO
• Message store refactoring - Tricky part

If we want to store "multiple sessions" depending on the agents, we can't interact with the bag (as it's not persisted), the only way is to do it at the store level, thing is, how?

Well, one way is to "initialize" the store with a session, the question is: Is it mandatory every time we initialize a store?

If so then we can just change the constructor of InMemoryStore and it's done, easy, simple, not much work, thing is, we'll be blocked if we want to handle multiple agents at the same time in the same store (parallel handling, etc).

So here's my take, not perfect, open to discuss about it, it's a POC after all 😄

PS: At the end, this API calls will be hidden when using the bundle, the main concern is the "OOP without Sf" usage.
PS II: The interface is inspired by the one from Cache for tags, the behavior is not the same but the idea still there.

[chr-hertel]

I'd say it's not the agent, that needs the ID, but the MessageBag. The message bag represents the conversations of a specific user/interaction. It is the subject we want to persist.

[Guikingone]

Agree but you need to define the id of the agent at the agent level then pass it into the message bag, without it, you'll be not able to "tie together" both the agent and the messages 🤔

[chr-hertel]

@Guikingone but you're referring to differentiating various agent configurations not instances of the same agent per User, right?

Would a name of the agent solve that concern?

[Guikingone]

My POV is the following:

• Each agent must have a unique identifier (UUID, ULID, other?) used to store messages related to this agent

Regarding the technical implementation, to be fair, I have two approaches in mind:

• Triggering an UUID at the agent level, this UUID is used by every chat to identify the message bag linked to this agent.
• Triggering the UUID at the chat level then store it with the message bag.

The first approach seems "the way to do it" in my mind, each agent is unique, we might want to reuse messages linked to this one, it should "store" its identifier.

The second one is tied to the chat in a way that any agent that "connect" to this chat can retrieve the chat history, IMO, that's an issue as we sometimes prefer to link to a specific agent (due to messages concerns, etc).

Either way, I just pushed a "new version" of the POC, feel free to explore it (it doesn't change the "public API") 🙂

[chr-hertel]

Why this doesn't make sense to me is because I still see the Agent as a service - which might potentially change, but right now it is treated like that. It's also how the bundle treats it - meaning one instance of the agent is shared per Symfony kernel - having the UUID in the agent also means that it changes with every kernel boot.

On top we already have a state object, that we can persist and hydrate - which is the MessageBag. I will try your POC but just can't follow your reasoning/design decision here right away.

[Guikingone]

Ah, got it, didn't thought about the kernel reboot (especially during container compilation), I was focused on the approach via the examples, not the "framework usage" one.

Of course, it make sense now, I was wrong, completely wrong, I'll check the idea of having the UUID at the bag level, it should be easier to handle in the store, etc.

Sorry for the dead end discussion, wasn't on the "right path" 🙁

[chr-hertel]

@Guikingone nooo, all good, you're on a streak anyhow :D