@busy-branch-28834 and @abundant-pillow-85439, we talked about parallel delegation in our meeting, here’s the PR where @modern-fireman-99755 is working on it: https://github.com/issues/assigned?issue=OpenHands%7Csoftware-agent-sdk%7C2350

great, thanks for the pointer!

The PR is still a draft, but I’ll mark it as ready soon. Feel free to take a look in the meantime! https://github.com/OpenHands/software-agent-sdk/pull/2390

Thanks Vasco! Just to clarify, this will ensure that all read-only tools like grep, glob, view, web search etc. are executed truly in parallel if the LLM made parallel tool-calls? I assume terminal tool isn't read-only in principle so is that disabled? Or is it for the LLM/user to ensure that the tools are thread-safe?

Premise: This PR adds the infrastructure required for parallel tool calls, but the feature is disabled by default. The standard behavior remains sequential.

Or is it for the LLM/user to ensure that the tools are thread-safe?

We are currently following this path (as discussed in the issue). Theoretically, LLMs are already trained to perform independent tool calls when they can emit them. But there is always a stochastic risk. If we find through testing and experimenting that parallel calls frequently fail due to dependencies, we will develop a dedicated solution to handle it. We chose this approach because managing tool calls independence is a significant challenge; trying to tackle everything at once was not optimal.

I assume terminal tool isn't read-only in principle so is that disabled?

By nature, the terminal is not read-only. However, we can enforce read-only constraints on specific sub-agents (this is a feature we plan to implement). For example, an "explorer" sub-agent that uses the terminal only to navigate a codebase would be restricted to read-only actions, making parallel calls safe. Regarding web search and browser tools: The safety of parallel calls generally only applies if you are using the terminal for basic web searches. If you use the

web_browser

tool (which utilizes a Chrome instance), you may encounter interdependent tool calls. For instance, clicking a button and then needing to visualize the resulting content before the next action.

alright, thank you for the detailed explanation!