Adds Message History to a ConversableAgent

[WaelKarkoub]

Why are these changes needed?

Part of Persistence and state management roadmap. Adds messages to the constructor of a ConversableAgent. This will allow the agent to pick up the conversation from where it left off.

NOTE: User needs to reconstruct the messages if the references of those agents have changed (e.g. the python script was restarted or new agents formed).

Related issue number

Checks

• I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
• I've added tests (if relevant) corresponding to the changes introduced in this PR.
• I've made sure all auto checks have passed.

[ekzhu]

Some build failures.

[ekzhu]

Thanks!

[r4881t]

While this is great PR, I have a few thoughts here

1. In a typical scenario, the "end user" (human) would want the interface (single Agent, SoM, Group Chat etc) to retain their own context. Any system implementing this would most likely store the end user's query and the interface's response in some DB.
2. To recreate this, the only details available would be user's query and the response. This should be passed to the agent (user proxy or similar).

I would expect something like below

1. ConversableAgent's initiate_chat to take a previous history of context and then be able to use it.

While something like this can be achieved using initiate_chat's message param which can be a callable, having a native implementation would be helpful. Because in this scenario, it sometimes end up loosing the context, because it also depends on the system prompt of the agent to be able to realise this.

assistant = ConversableAgent(
      name="Assistant",
      system_message="Your are a friendly Q&A Bot"
      "You may use the previous messages to understand the context of current Query"
      "Return 'TERMINATE' when the task is done.",
      llm_config=self.llm_config,
      human_input_mode="NEVER",
      default_auto_reply="Reply with 'TERMINATE' if the task is done.",
      is_termination_msg=is_termination_msg
    )

def my_message(sender: ConversableAgent,
                   recipient: ConversableAgent,
                   context: dict) -> Union[str, Dict]:
      message = context.get("user_query", "")
      last_chats = context.get("last_chats", [])
      prelude = [f"Query: {x.get('query')}. Answer: {x.get('answer')}" for x in last_chats]
      curr_msg = f"CURRENT QUERY: {message}"
      final_msg = f"Previous Messages: {' '.join(prelude)}. {curr_msg}"
      return final_msg


user_proxy.initiate_chat(
      assistant,
      message=my_message,
      user_query=query,
      last_chats=last_chats,
      verbose=True
    )

In another example from the blog mentioned here, people are replaying the chat in GroupChat and broadcasting it to all other agents. I believe this need can also be eliminated if only the user's query & response are passed onto while initiating group chat

[ekzhu]

In a typical scenario, the "end user" (human) would want the interface (single Agent, SoM, Group Chat etc) to retain their own context. Any system implementing this would most likely store the end user's query and the interface's response in some DB.
To recreate this, the only details available would be user's query and the response. This should be passed to the agent (user proxy or similar).
I would expect something like below

Are you thinking about a stateful agent? For now ConversableAgent is typically created for a task and thrown out once the task is completed -- the state is managed by the application. The choice is made here is we believe application has the best understanding of end user experience and how state should be handled, e.g., long running chat or utility functions.

ConversableAgent's initiate_chat to take a previous history of context and then be able to use it.

This is a great idea. We have a roadmap issue on persistence and this is a work item. Would you be interested in contributing?

See #2358

[r4881t]

Are you thinking about a stateful agent?

No. I don't think that serves any practical purpose. I am more interested in having some way to inject previous history into a stateless agent.

Would you be interested in contributing?

@ekzhu - Sure, I will try and open a PR