Happy to explain here! The Result (sync) return type in the Invoke Agent block will synchronously block your workflow until it receives a response, whereas the Run State (async) return type continues to schedule workflow blocks while the agent is processing your request. In other words: Sync is best used for shorter running queries where you know you wonāt have to wait too long for an agentās response, whereas Async is better suited when thereās still workflow steps that could happen during longer running queries.
Sync mode (as well as āInvokeā in the Async GUI mode) only accepts a message as an input. Async has the additional JSON Input Mode to offer more granularity/control over what youād like that Agent Block to handle. This guide provides a good example of this, and demonstrates how to poll an agent for its logs using a JSON input. An Invoke Agent block triggered with an "Invokeā action will return an agentId and agentRunId, which you could use in a subsequent code block, an Agent block using JSON (i.e. action: checkLogs), or an Agent block using the āCheck Resultsā action in GUI mode.
Thanks for spending time on the explanation @Altai_Chiang . I guess I donāt understand why Async would be given more granular options than Sync. Async vs Sync is not Simple vs Complex or Beginner vs Advanced. Async vs Sync is just whether we wait for the result or not. So now, if I want want to provide a json input to Sync, I have to modify my prompt to set expectations. Modifying a prompt to handle Sync vs Async doesnāt seem right to me. Just my unsolicited two cents.
That's a fair point and good feedback, @lkiss - I'll pass it on to the team. They'd probably be interested in hearing some additional context about how you'd potentially augment the invoke payload in sync mode, as that's the only meaningful gap between the two modes.