maxParallelToolCalls=1 still sends parallel_tool_calls: true to OpenAI-compatible providers

[yablokolabs]

Summary

ATOMIC_AGENT_MAX_PARALLEL_TOOL_CALLS=1 limits Atomic's executor, but the main native-tools request path still asks OpenAI-compatible providers to generate parallel tool calls by sending parallel_tool_calls: true.

This prevents the setting from serving as a provider-compatibility control. It was a blocker with Gemini's OpenAI-compatible stream, where parallel calls lacked stable indices and were merged by the consumer.

Observed on Atomic Agent v0.1.72 and confirmed by inspection on v0.1.73/current main (9d525ef4a004a9106608bea7a01ecd70ab279c2d).

Current behavior

The configured executor cap is loaded as agent.maxParallelToolCalls, but step-executor.ts builds the main native tool request with:

parallelToolCalls: true

openai-build-body.ts consequently serializes:

body.parallel_tool_calls = filtered.parallelToolCalls ?? true;

The provider capability model already exposes supportsParallelTools, but it is not reflected in this main request decision.

Steps to reproduce

1. Configure an OpenAI-compatible provider with native tools.
2. Set ATOMIC_AGENT_MAX_PARALLEL_TOOL_CALLS=1.
3. Capture the /chat/completions request body for a normal agent step.
4. Observe parallel_tool_calls: true.

Expected behavior

Atomic should send parallel_tool_calls: false when either:

• agent.maxParallelToolCalls is 1; or
• the selected provider reports supportsParallelTools: false.

When the cap is greater than one and the provider supports parallel tools, the current parallel behavior can remain enabled.

Suggested implementation

Derive CompletionRequest.parallelToolCalls from both runtime configuration and provider capabilities instead of hardcoding it in the step executor.

The localhost Gemini compatibility bridge used during evaluation forced this field to false, which allowed the agent to progress one tool call at a time.

Acceptance criteria

• A request-body test proves ATOMIC_AGENT_MAX_PARALLEL_TOOL_CALLS=1 produces parallel_tool_calls: false.
• A provider with supportsParallelTools: false produces false regardless of the configured cap.
• A capable provider with a cap greater than one still produces true.
• The execution cap continues to reject or repair model batches that exceed the configured maximum.
• Non-tool requests do not gain a parallel_tool_calls field.

[yablokolabs]

Fixed by #207 — parallel_tool_calls is now derived from agent.maxParallelToolCalls > 1 AND the active provider's supportsParallelTools capability, so setting the cap to 1 (or pairing a provider that rejects parallel calls) stops advertising parallel_tool_calls: true on the request body.

[yablokolabs]

Follow-up to #207: #212

Adds an explicit supportsParallelTools?: boolean config field. Gemini now defaults to false (overriding the supportsTools fallback), so the provider-capability term actually fires for the case described in this issue. Users can opt back in with supportsParallelTools: true on a Gemini entry if their deployment supports it.