馃敶 Required Information
Is your feature request related to a specific problem?
As suggested by ADK doc, I'm using artifacts to persist session-scope states of large sizes. These states are meant to be used within my control code / tools, not read by the LLM.
The stock LoadArtifactsTool, which can be used by the agent to read supported file types, exposes all artifacts, including those I don't want the agent to see, to the LLM.
LoadArtifactsTool supports a process_artifact callback that can be leveraged to prevent artifact data from being exposed. However, the tool also injects all artifact filenames to the context. So it still leaks the information about the existence of artifacts and can pollute the context.
Describe the Solution You'd Like
Option 1: Provide another callback to process list_artifacts() responses before appending them to the context.
Option 2: Provide a mechanism to distinguish (e.g., by naming) LLM-ingestable artifacts and artifacts that are purely used by the control code.
Impact on your work
I won't say "crucial" because I can reimplement the tool anyway :)
Willingness to contribute
Are you interested in implementing this feature yourself or submitting a PR? Maybe
馃敶 Required Information
Is your feature request related to a specific problem?
As suggested by ADK doc, I'm using artifacts to persist session-scope states of large sizes. These states are meant to be used within my control code / tools, not read by the LLM.
The stock
LoadArtifactsTool, which can be used by the agent to read supported file types, exposes all artifacts, including those I don't want the agent to see, to the LLM.LoadArtifactsToolsupports aprocess_artifactcallback that can be leveraged to prevent artifact data from being exposed. However, the tool also injects all artifact filenames to the context. So it still leaks the information about the existence of artifacts and can pollute the context.Describe the Solution You'd Like
Option 1: Provide another callback to process
list_artifacts()responses before appending them to the context.Option 2: Provide a mechanism to distinguish (e.g., by naming) LLM-ingestable artifacts and artifacts that are purely used by the control code.
Impact on your work
I won't say "crucial" because I can reimplement the tool anyway :)
Willingness to contribute
Are you interested in implementing this feature yourself or submitting a PR? Maybe