Skip to content

Conversation

ehhuang
Copy link
Contributor

@ehhuang ehhuang commented Mar 5, 2025

Summary:

Client side change in llamastack/llama-stack-client-python#180
Changes the resume_turn API to accept ToolResponse instead of ToolResponseMessage:

  1. ToolResponse contains metadata
  2. ToolResponseMessage is a concept for model inputs. Here we are just submitting the outputs of tool execution.

Test Plan:

Ran integration tests with newly added test using client tool with metadata

LLAMA_STACK_CONFIG=fireworks pytest -s -v tests/integration/agents/test_agents.py --safety-shield meta-llama/Llama-Guard-3-8B --record-responses

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Meta Open Source bot. label Mar 5, 2025
@ehhuang ehhuang changed the title feat: ClientTool output metadata feat: support ClientTool output metadata Mar 5, 2025
session_id: str
turn_id: str
tool_responses: List[ToolResponseMessage]
tool_responses: List[ToolResponse | ToolResponseMessage]
Copy link
Contributor

@yanxi0830 yanxi0830 Mar 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's difference between ToolResponse and ToolResponseMessage? Maybe we should just keep one?

or

class ToolResponseMessage(ToolResponse)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ToolResponse represents response from a tool.
ToolResponseMessage responses an input message to the model whose content is from a tool response.

ToolResponseMessage here is for backward compatibility and will be removed in future version.

Copy link
Contributor

@yanxi0830 yanxi0830 Mar 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, it feels like these 2 types are kind of redundant and can be unified into 1?

class ToolResponseMessage(BaseModel):
    role: Literal["tool"] = "tool"
    call_id: str
    tool_name: Union[BuiltinTool, str]
    content: InterleavedContent

class ToolResponse(BaseModel):
    call_id: str
    tool_name: Union[BuiltinTool, str]
    content: InterleavedContent
    metadata: Optional[Dict[str, Any]] = None

    @field_validator("tool_name", mode="before")
    @classmethod
    def validate_field(cls, v):
        if isinstance(v, str):
            try:
                return BuiltinTool(v)
            except ValueError:
                return v
        return v

Or is the idea that we could could be augmenting the content from ToolResponse into ToolResponseMessage using metadata?

Copy link
Contributor Author

@ehhuang ehhuang Mar 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea we could unify as it contains mostly the same information, but I think having them separate keeps the interface cleaner. ToolResponseMessage is one of the model inference API inputs. Having metadata there that's never used by the model makes the inference API less clean and could confuse users. From inference API users POV, metadata doesn't make sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense! So ToolExecutionStep would contain metadata from ToolResponse which user can query about, while inference only sees ToolResponseMessage.

@ehhuang ehhuang marked this pull request as ready for review March 5, 2025 19:53
@ehhuang ehhuang added this to the v0.1.6 milestone Mar 5, 2025
Copy link
Contributor

@yanxi0830 yanxi0830 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a task to deprecate the ToolResponseMessage for 0.1.7? Also do we need OpenAPI updates for this PR?

@ehhuang ehhuang merged commit 6cf7943 into main Mar 5, 2025
7 checks passed
@ehhuang ehhuang deleted the pr1426 branch March 5, 2025 22:30
ehhuang added a commit to llamastack/llama-stack-client-python that referenced this pull request Mar 6, 2025
Summary:
Corresponding change on the python client for
llamastack/llama-stack#1426

Test Plan:
Tested in llamastack/llama-stack#1426

Co-authored-by: Eric Huang (AI Platform) <erichuang@fb.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Meta Open Source bot.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants