load_artifacts is not working as expected in adk 2.0

[karthiky7]

adk-python/src/google/adk/tools/load_artifacts_tool.py

Line 212 in 0a290d5

if llm_request.contents and llm_request.contents[-1].parts:

load_artifacts is not working as expected in workflow agent node . agent got stuck in loop of calling load_artifacts because Tool calls get converted to text by workflow layer and tool expects function response as last part
example of object inspect:
[Content(
parts=[ Part( text='For context:' ), Part( text="[no_po_hitl] load_invoice tool
returned result: {'artifact_name': 'E044267733', 'status': 'Artifact E044267733
loaded successfully'}" ), ], role=user' )]

This is text, not a function_response

[adk-bot]

I will view the main SKILL.md file for the adk-issue skill to understand the process of analyzing a GitHub issue in the adk-python repository.I will view adk-issue-analyze/SKILL.md to see the details of the issue analysis process, including constraints and required report structure.I will fetch the details of GitHub issue #5967 using the fetch_github_issue tool.I will use find_by_name to locate load_artifacts_tool.py within the workspace.I will open and view the load_artifacts_tool.py file to understand the logic for loading artifacts and where the issue lies around line 212.I will view the rest of the load_artifacts_tool.py file to understand the _append_artifacts_to_llm_request function in full.I will view the rest of the file by specifying both StartLine and EndLine.I will view the tests/unittests/tools/test_load_artifacts_tool.py file to understand the tests and expected behavior.I will use grep_search to find other occurrences of load_artifacts or how the agent nodes process it.I will use grep_search to find where the tool results are formatted or converted to text within the workflow or agent implementation files.I will view the src/google/adk/flows/llm_flows/contents.py file to see how tool results are formatted or converted to text.I will view the rest of the file src/google/adk/flows/llm_flows/contents.py.I will search for process_llm_request in the codebase to understand where and when it is invoked during LLM request processing.I will use grep_search to find occurrences of process_llm_request in base_llm_flow.py to see the flow of execution.I will view base_llm_flow.py to check how and when process_llm_request is called.I will view base_llm_flow.py from line 200 to 250 to locate the definition of _handle_before_model_callback.I will use grep_search with MatchPerLine=True to locate the exact occurrences of process_llm_request in base_llm_flow.py.I will view base_llm_flow.py between lines 410 and 490 to understand the logic that calls process_llm_request.I will search for _process_agent_tools in base_llm_flow.py to see where it is called relative to the content generation.I will view base_llm_flow.py from line 990 to 1030 to see the flow.I will use grep_search to find append_instructions in the codebase to see how it operates and where the instructions go.I will view llm_request.py to see the implementation of append_instructions and understand where it inserts instructions.I will view lines 190 to 256 of load_artifacts_tool.py to draft the precise changes for our analysis report.I will search for any existing pull requests related to issue #5967.I will fetch the output of the PR search command.# GitHub Issue #5967 Analysis: load_artifacts is not working as expected in adk 2.0

I have completed Phase 1: Triage and Analysis for GitHub Issue #5967. Below is the detailed analysis and findings report.

---

Detailed Analysis

1. Root Cause Analysis ("What is broken?")

When an agent or node uses the load_artifacts tool inside multi-agent frameworks or workflow nodes:

1. The tool is executed and returns a response dictionary containing the status and loaded/requested artifact_names.
2. This event's response (with role 'user') is converted into a structured text format in contents.py because it represents context coming from the workflow layer or a different orchestration event-boundary (i.e. of some other author name).
3. The converted text format has the structure:
   '[{event.author}] load_artifacts tool returned result: {'artifact_names': [...], 'status': '...'}'
4. Meanwhile, load_artifacts_tool.py expects the last turn in llm_request.contents to have a standard FunctionResponse part as its first element:

   function_response = llm_request.contents[-1].parts[0].function_response
   if function_response and function_response.name == 'load_artifacts':

5. Because of the conversion to text, the check fails, the requested actual artifact contents are never appended to the LLM context, and the model receives no data.
6. Consequently, the model gets stuck calling load_artifacts in an infinite loop because it sees the tool was called but never receives the loaded artifact contents.

Additionally, checking only parts[0] of the last message is fragile if there are multiple/parallel function responses in the same user content turn.

2. Legitimacy Analysis

• Status: Legitimate Bug
• Evidence:
  • Code reference: load_artifacts_tool.py
  • Code reference: contents.py
  • Because _present_other_agent_message in contents.py intentionally and explicitly converts function responses from other agents or nodes into user-role text messages, any tool like load_artifacts that relies on inspecting raw FunctionResponse parts inside llm_request.contents will break when running within workflow-agent boundaries.

3. Fix Recommendation

• Recommendation: Should Fix (High Priority)

• Rationale:

  • The bug breaks standard workflows and context offloading patterns using artifacts on multi-agent nodes.
  • The solution is highly clean/localized and has extremely low risk of side effects: we can enhance load_artifacts_tool.py to check all parts of llm_request.contents[-1] and dynamically parse the payload from either raw FunctionResponse or text-formatted strings.

  Using a safe abstract syntax tree evaluator (ast.literal_eval), we can extract the dictionary content securely if a part is converted to a text-formatted string:

  import re
  import ast
  
  # Within the loop over part in llm_request.contents[-1].parts:
  if part.function_response and part.function_response.name == 'load_artifacts':
    ...
  elif part.text and '`load_artifacts` tool' in part.text:
    match = re.search(r'`load_artifacts` tool\s+returned result:\s*(.*)', part.text, re.DOTALL)
    if match:
      try:
        response_dict = ast.literal_eval(match.group(1).strip())
        if isinstance(response_dict, dict):
          names = response_dict.get('artifact_names', [])
          ...
      except Exception as e:
        logger.warning('Failed to parse text-formatted load_artifacts response: %s', e)

4. Existing Pull Requests

• Linked PR: None
• PR URL: N/A
• Analysis: No pull requests were found matching this issue number.

---

Executive Summary

1. What is broken? The load_artifacts tool is unable to attach requested artifacts when used on workflow-orchestrated agent nodes because the workflow layer converts the tool response part from an orchestrating event database into a text part.
2. Is the issue legitimate? Yes, both the code structure and multi-agent context conversions verify this as a legitimate bug.
3. Should we fix it? Yes (High Priority), as it prevents standard workflow nodes from correctly loading and using artifacts, causing infinite model tooling loops.
4. Is there a linked PR that fixes this issue? None.

---

Would you like me to create and implement a fix for this issue in the workspace? (Note: The changes and tests will be created in a new branch but