Support for Parallel Tool Execution with Custom Models

[omricarmi4]

I am using adk-java version 0.5.0 with a custom model implementation (wrapping GPT-4.1 / GPT-5.1 via LangChain4j).

When these models return multiple tool calls in a single turn (Parallel Function Calling), the LlmAgent in the Java ADK executes them sequentially. This results in significant, avoidable latency compared to concurrent execution.

I have verified that this exact architecture works correctly in the Python ADK (v1.10.0) using the LiteLLM wrapper. In the Python environment, the same models successfully trigger parallel tool execution, drastically reducing the total response time.

I attempted to enforce parallelism using the RunConfig builder in Java, but it did not result in concurrent execution:

Java

RunConfig runConfig = RunConfig.builder()
    .setToolExecutionMode(ToolExecutionMode.PARALLEL)
    .build(); 
// Passed this config to the agent runner

Question Is parallel tool execution currently supported for custom model implementations in the Java ADK? If so, is there a specific configuration required beyond ToolExecutionMode.PARALLEL? If not, is this a planned enhancement for an upcoming release?

[keunlee]

I can confirm this issue and provide a root cause analysis with bytecode evidence from ADK 0.6.0, plus a working fix.

Root Cause

The problem is in Functions.handleFunctionCalls and FunctionTool.runAsync(). Here's what happens:

Functions.handleFunctionCalls dispatches tool calls using concatMapEager:

// Pseudocode from bytecode (Functions.java, ADK 0.6.0)
ToolExecutionMode mode = invocationContext.runConfig().toolExecutionMode();

if (mode == SEQUENTIAL) {
    observable = Observable.fromIterable(functionCalls)
                           .concatMapMaybe(mapper);       // strictly sequential
} else {
    // Both NONE (default) and PARALLEL use concatMapEager
    observable = Observable.fromIterable(functionCalls)
                           .concatMapEager(mapper);       // SHOULD be parallel
}

concatMapEager eagerly subscribes to all inner observables at once — so the parallelism infrastructure is wired correctly. The problem is downstream.

FunctionTool.runAsync() returns Single.fromCallable(...) with no subscribeOn() scheduler:

// FunctionTool.runAsync() — ADK 0.6.0 bytecode
public Single<Map<String, Object>> runAsync(Map<String, Object> args, ToolContext toolContext) {
    // ...confirmation check logic...
    return call(args, toolContext).toSingle();  // call() returns Maybe.fromCallable(...)
}

Since fromCallable() has no scheduler, it runs synchronously on the subscribing thread. concatMapEager subscribes to all observables eagerly, but each one blocks the thread before the next can start — resulting in sequential execution regardless of ToolExecutionMode.

Bytecode Verification

Confirmed via javap -p -s on google-adk-0.6.0.jar:

Class	Method	Final?	Return Type
BaseTool	runAsync()	No (ACC_PUBLIC only)	Single<Map<String, Object>>
FunctionTool	runAsync()	No (ACC_PUBLIC only)	Single<Map<String, Object>>
FunctionTool class	—	No (ACC_PUBLIC, ACC_SUPER)	—
FunctionTool constructors	—	protected	—

Functions.callTool() uses invokevirtual BaseTool.runAsync() — polymorphic dispatch, so subclass overrides are respected.

Fix: ParallelFunctionTool

Since FunctionTool is not final, its constructors are protected, and runAsync() is virtual, a one-class subclass fixes this:

import com.google.adk.tools.FunctionTool;
import com.google.adk.tools.ToolContext;
import io.reactivex.rxjava3.core.Single;
import io.reactivex.rxjava3.schedulers.Schedulers;

import java.lang.reflect.Method;
import java.util.Arrays;
import java.util.Map;

/**
 * Drop-in replacement for FunctionTool that enables true parallel tool execution.
 *
 * ADK's Functions.handleFunctionCalls uses concatMapEager which eagerly subscribes
 * to all tool observables. However, FunctionTool.runAsync() returns
 * Single.fromCallable() with no subscribeOn() scheduler, causing all tools to
 * run sequentially on the subscribing thread.
 *
 * This subclass adds subscribeOn(Schedulers.io()) so each tool executes on an
 * I/O thread, allowing concatMapEager to achieve true parallelism.
 */
public class ParallelFunctionTool extends FunctionTool {

    protected ParallelFunctionTool(Object instance, Method func) {
        super(instance, func, false);
    }

    @Override
    public Single<Map<String, Object>> runAsync(Map<String, Object> args, ToolContext toolContext) {
        return super.runAsync(args, toolContext)
                .subscribeOn(Schedulers.io());
    }

    public static ParallelFunctionTool create(Object instance, String methodName) {
        Method method = Arrays.stream(instance.getClass().getMethods())
                .filter(m -> m.getName().equals(methodName))
                .findFirst()
                .orElseThrow(() -> new IllegalArgumentException(
                        "No public method '" + methodName + "' found on "
                                + instance.getClass().getName()));
        return new ParallelFunctionTool(instance, method);
    }

    public static ParallelFunctionTool create(Object instance, Method method) {
        return new ParallelFunctionTool(instance, method);
    }
}

Usage — drop-in replacement in agent configuration:

LlmAgent.builder()
    .name("MyAgent")
    .model(new LangChain4j(chatModel))
    .tools(
        ParallelFunctionTool.create(toolA, "methodA"),
        ParallelFunctionTool.create(toolB, "methodB"),
        ParallelFunctionTool.create(toolC, "methodC")
    )
    .build();

Suggested Fix in ADK Core

Rather than requiring users to use a subclass, the fix could go directly into FunctionTool.runAsync() or into Functions.handleFunctionCalls. Two options:

Option A — Fix in FunctionTool.runAsync():

// Add subscribeOn when the tool is not long-running
public Single<Map<String, Object>> runAsync(Map<String, Object> args, ToolContext toolContext) {
    // ...existing logic...
    return call(args, toolContext).toSingle()
            .subscribeOn(Schedulers.io());
}

Option B — Fix in Functions.callTool() (centralised, affects all tool types):

private static Maybe<Map<String, Object>> callTool(BaseTool tool, ...) {
    return tool.runAsync(args, ctx)
               .toMaybe()
               .subscribeOn(Schedulers.io())  // <-- add this
               .doOnSubscribe(...)
               ...
}

Option B is cleaner because it fixes the issue for all BaseTool subclasses (including McpTool, AgentTool, etc.) in one place.

I've tested this with ADK 0.6.0 + LangChain4j 1.11.0 + AWS Bedrock Claude Sonnet 4.5, and all integration tests pass. Happy to open a PR if there's interest.

---

Tested against: google-adk:0.6.0, google-adk-langchain4j:0.6.0, Spring Boot 3.4.5, AWS Bedrock.

[hemasekhar-p]

Hi @omricarmi4, Thank you for reporting this issue. I am able to reproduce this behavior in the latest version (1.1.0). we will be tracking this issue in #1152 along with the associated PR #1154 to fix this issue. To prevent duplication of effort, we request you to close this issue and continue the discussion in the linked issue?