Allow separate tool_result (UI) and tool_result_for_llm (LLM context) #5391
tschokokuki
started this conversation in
Ideas
Replies: 1 comment
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Situation
Since the latest version of agent-framework-ag-ui tools can return text and alter state deterministically. Which is already great! 👌
Problem
The
get_weatherexample works fine for simple text. But supposedatais a large structured object (e.g. a list of work items, a chart dataset) that the UI should render as a component — not as text. My hypothesis is, that there is currently no way to send rich JSON to the UI as function_result without also sending it to the LLM, where it tends to be repeated or re-summarised verbatim. Correct?Today
_emit_tool_result_commonuses the same value for both:ToolCallResultEvent.content— what the UI renders-
flow.tool_results[].content— what is fed back to the LLMadditional_propertiesalready travels on the Content object but is never read by the emitter to override either result slot.Proposed solution
Since additional_properties is already on Content, the emitter could honour two reserved keys — no signature change required, full backward compat:
And expose them via state_update:
Why not use state as a workaround?
state is global and persistent. Tool results are ephemeral per-turn. Mixing them forces the frontend to clean up after every tool call and breaks in parallel multi-tool flows.
Beta Was this translation helpful? Give feedback.
All reactions