feat: Extend AnswerBuilder for Agent

[vblagoje]

Why:

Enhances the AnswerBuilder component to preserve conversation history when processing Agent outputs.

• fixes Extend AnswerBuilder to convert only last message for agentic pipelines #9330

• Addresses the need to maintain agent message context in GeneratedAnswer objects

• Enables seamless integration between Agent components and the AnswerBuilder

What:

• Updates AnswerBuilder to store entire conversation history in metadata
• Adds "all_messages" field to GeneratedAnswer metadata containing all messages
• Preserves backward compatibility with existing pipelines
• Updates tests to verify the new functionality

How can it be used:

Connect Agent and AnswerBuilder in a pipeline to maintain conversation context:

from haystack import Pipeline
from haystack.components.builders import AnswerBuilder
from haystack.components.agents import Agent
from haystack.components.generators.chat import OpenAIChatGenerator

# Create components
agent = Agent(chat_generator=OpenAIChatGenerator())
answer_builder = AnswerBuilder()

# Create pipeline
pipeline = Pipeline()
pipeline.add_component("agent", agent)
pipeline.add_component("answer_builder", answer_builder)

# Connect components
pipeline.connect("agent.messages", "answer_builder.replies")

# Run the pipeline
result = pipeline.run(data={"agent": {"messages": [user_message]}})

# Conversation history is preserved in the answer metadata
conversation_history = result["answer_builder"]["answers"][0].meta["all_messages"]

How did you test it:

• Unit tests verify that conversation history is properly stored in metadata
• Added helper function to test metadata while ignoring the new field
• Tests ensure backward compatibility with existing code

[coveralls]

Pull Request Test Coverage Report for Build 15186489091

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 81 unchanged lines in 7 files lost coverage.
• Overall coverage decreased (-0.03%) to 90.423%

---

Files with Coverage Reduction	New Missed Lines	%
components/builders/answer_builder.py	1	98.53%
components/rankers/init.py	2	50.0%
components/embedders/openai_text_embedder.py	6	89.09%
components/agents/agent.py	9	91.07%
components/rankers/transformers_similarity.py	9	91.67%
components/embedders/openai_document_embedder.py	22	62.61%
components/tools/tool_invoker.py	32	83.51%

Totals
Change from base Build 15136007493:	-0.03%
Covered Lines:	11104
Relevant Lines:	12280

---

💛 - Coveralls

[vblagoje]

@tstadel would you please have a look - is this what you had in mind?

[tstadel]

@vblagoje having all messages in meta is already a big win. Do I get this right, that if I just want to get the last message as answer (and have the others in this message's meta), I still have to put an OutputAdapter after AnswerBuilder?
If so would it be possible to add a flag that makes the AnswerBuilder return only the last message?

[vblagoje]

@vblagoje having all messages in meta is already a big win. Do I get this right, that if I just want to get the last message as answer (and have the others in this message's meta), I still have to put an OutputAdapter after AnswerBuilder? If so would it be possible to add a flag that makes the AnswerBuilder return only the last message?

No, no @tstadel we added dedicated last_message output in Agent, see this

[vblagoje]

So in that sense this PR was all about adding all_messages in meta - and slight accommodation of not checking that each messages has text and raising ValueError in that case. That constraint or prerequisite seems a bit drastic in this day and age of tool calling and multimodality so I removed it. I'm hoping that this slight change won't cause any issues to existing usage of AnswerBuilder - and that's what I would ask you to please think about. 🙏 man

[tstadel]

@vblagoje I think that slight change is fine. But how would I get exactly one Answer (using the last message) having the all_messages meta field when using Agent and AnswerBuilder.
Agent just returns the last message as Message object, right?. So I can't use it in this scenario, no?

[vblagoje]

Yeah, I thought I could achieve what you wanted via this minimal change:

• connect Agent's [last_message] to AB replies and don't bother about tool calls and message history - extracted_reply will get the text of the last message, parse it for reference if somehow documents are provided etc
• connect Agent's [messages] to AB replies and then extracted_reply will get the text of the last message as it iterates through all messages and you'll also have all_message in metadata in addition

I did it this way cause I think it does what you wanted and doesn't cause, hopefully, too many issues to existing pipelines.

Update: As last_message in Agent will stay of ChatMessage type - we should figure out how to do the same with connecting [messages] only @tstadel.

It seems still ok. Please follow this line of reasoning. In current PR, If we connect Agent's messages output to AB, AB will take the last message from [messages] and assign it to extracted_reply, all_message still being added to the meta as planned. So we seem to be good in that case as well. LMK if I'm overlooking something.

[vblagoje]

@tstadel have a look now 🙏

[tstadel]

Looks great! Thx a lot 🙏

[anakin87]

@vblagoje do you need a review from me as well?
Please LMK. I don't want to block this work...

[vblagoje]

@anakin87 please do a please focus on 6dd96fd as this unit tests demonstrates nicely what @tstadel asked for.

Another thing that I'd love to ask you is if we perhaps need last_message_only as run parameter. @tstadel didn't ask for it and I wasn't sure if we should add it or not. I was leaning to not because we already have one too many params in run. LMK what you think.

[anakin87]

I left some minor comments.

About last_message_only as run parameter: let's avoid it for the moment, if you agree.

[anakin87]

LGTM