Maybe an alternative or in addition to this could be to add an additional output to the Agent called final_message of type ChatMessage which always contains the last message?

@bilgeyucel also mentioned for standalone uses of Agent that this would be helpful.

Agree with @sjrl here. Additionally, Haystack users don't use AnswerBuilder as they get a similar benefit through Pipeline's include_outputs_from parameter. Handling this in AnswerBuilder would force users to add AnswerBuilder to their pipeline

Interesting, I thought about this briefly too, but rejected it because

• it doesn't allow one to add additional information from the rest of the messages, e.g. tool calls. For this you'd need all messages again. AnswerParser could take care of this, e.g. by filling Answer's meta fields with tool call info.
• when using AnswerBuilder, returning a single message would require an OutputAdapter again, as AnswerBuilder expects list[Message] (not a single Message).

Interesting, I thought about this briefly too, but rejected it because

• it doesn't allow one to add additional information from the rest of the messages, e.g. tool calls. For this you'd need all messages again. AnswerParser could take care of this, e.g. by filling Answer's meta fields with tool call info.
• when using AnswerBuilder, returning a single message would require an OutputAdapter again, as AnswerBuilder expects list[Message] (not a single Message).

That's fair! I think it might be worth doing all of the following:

• Update AnswerBuilder to convert last message from Agent and put the rest into metadata for the reasons @tstadel outlined
• Add a final_message of type ChatMessage (or final_answer of type string) output to Agent. This should be helpful for users who want to 1) use the component standalone 2) easily connect the final_message as input to another component other than AnswerBuilder in a Pipeline and 3) use Agent as a tool in ComponentTool where usually you'd want just the final answer as the tool output.

Hey @tstadel @sjrl, I sketched out what needs to be done in AnswerBuilder and it’s turning it into a complicated beast—right now AnswerBuilder verifies that every chat message contains valid text and throws a ValueError when it doesn’t and this is going to be problematic for agent messages that have tool calls and responses. We are mixing a lot of domain logic here, all the way from RAG, pattern matching, reference creation, and now on top of this we are pulling in agent logic into AnswerBuilder. We’d be better off spinning up a separate AgentAnswerBuilder that can look at the agent’s state and handle everything needed to produce the answer, however it needs to look. LMK