Hi,
When an action is exposed to the LLM via the reasoning.actions block (which is how CLT-driven, user-input actions are typically wired), "the LLM can subjectively choose to run the tool based on the current context." The tool only actually executes "when the LLM receives the resolved prompt, not when the agent parses the subagent." This confirms the behavior you're seeing is expected non-determinism in how the planner decides to invoke the action, not a config bug on your end, the LLM can choose to fire the action before the CLT's user-input round trip has actually captured a value, especially if its reasoning at that turn "believes" it already has enough context.
Reference:
https://developer.salesforce.com/docs/ai/agentforce/guide/ascript-ref-actions.htmlTwo things worth checking based on this, per Salesforce's own CLT developer guide:
1. Confirm your CLT is wired as an explicit input collection step (not just user_input=true on the action parameter), and that your instructions/reasoning text explicitly tell the agent to ask the user via the CLT before invoking the action, rather than relying on the parameter flag alone to force the pause. The planner treats user_input=true as a hint, not a hard gate.
2. Double-check the valuechange event and wrapper field name matching. Per Salesforce's official CLT blog: "the wrapper class field names must exactly match the action parameter names... A mismatch here silently breaks the entire CLT connection," and this kind of silent break can look exactly like "sometimes it works, sometimes it doesn't" if the mismatch only surfaces under certain reasoning paths.
Reference:
https://developer.salesforce.com/blogs/2026/05/use-custom-lightning-types-in-agent-script-for-rich-agent-uiGiven this is planner-level non-determinism by design, the more reliable fix is tightening your reasoning/instructions text to explicitly require the CLT interaction as a precondition before the action is eligible to run, rather than depending solely on the user_input flag.
4 件の回答