Python: [Feature]: Parallel tool calling in declarative workflows

@peibekwe is already working on this.

Since Jun 1, 2026.

### Description

## Summary of the Issue
Declarative workflows in Microsoft Agent Framework do not support true parallel execution of tools or agents. While a for each construct exists, it executes sequentially only, which blocks common orchestration patterns such as fan‑out/fan‑in, parallel content generation, or concurrent API/tool calls. This limitation forces teams to implement inefficient or fragile workarounds and significantly impacts scalability and performance.

## 1. Feature Description

Parallel Tool Calling in Declarative Workflows enables multiple tool or agent invocations to execute concurrently (fan-out), with results optionally aggregated before the workflow proceeds. This extends existing declarative workflow constructs (such as `foreach`) to support parallel execution semantics, rather than strictly sequential processing.

The feature is intended to support common agentic orchestration patterns where multiple independent tasks can be executed at the same time, while still preserving deterministic workflow completion, clear execution boundaries, and observability.

---

## 2. Problem This Solves

Today, declarative workflows only support sequential execution within loops. Each iteration waits for the previous one to complete before starting the next. This creates several issues:

- **Unacceptable latency at scale**: Workflows that operate over collections (e.g., multiple inputs, variants, or transformations) experience linear increases in execution time.
- **Inability to meet production SLAs**: Sequential execution makes many real-world workflows too slow for customer-facing or time-sensitive scenarios.
- **Limited expressiveness**: Many agentic orchestration patterns rely on fan-out/fan-in behavior, which cannot be modeled cleanly with strictly sequential workflows.
- **Architectural mismatch**: Declarative workflows become unsuitable for scenarios that are naturally parallel, forcing teams to abandon them for custom orchestration.

As a result, declarative workflows cannot currently be used as the primary orchestration mechanism for complex or high-throughput agentic systems.

---

## 3. Expected Behavior

With parallel tool calling support, declarative workflows should be able to:

- Execute independent loop iterations concurrently rather than sequentially.
- Invoke multiple tools or agents in parallel when there are no data dependencies between them.
- Optionally aggregate or synchronize results before moving to downstream steps.
- Provide deterministic completion semantics (e.g., all parallel branches must complete or fail before continuing).
- Preserve observability, logging, and error reporting across parallel branches.
- Allow future extensibility for controls such as maximum concurrency, timeouts, and failure handling strategies.

This would enable declarative workflows to model real-world agentic orchestration patterns without sacrificing clarity or performance.

---

## 4. Alternatives and Workarounds Considered

Several workarounds have been explored, but all have significant drawbacks:

- **Sequential `foreach` loops**
The workflow DSL allows authors to define a for each loop, but each iteration executes one after another, not concurrently. There is no way to fan out multiple tool or agent calls in parallel within declarative workflows.

- **Control-flow hacks using interaction or messaging nodes
Attempts to pass intermediate data in and out of loops using non-standard nodes. These approaches are brittle and have led to unexpected behavior, including loops terminating early or executing incorrectly.

- **Offloading orchestration to hosted agents or custom code**
Hosted agents / pro‑code workflows do support parallel execution. However: Hosted agents are not yet available (pushed to a later date). Declarative workflows are the only viable option today, but they lack this capability.

- **External orchestration frameworks**
Using a separate orchestration layer that supports parallelism, while keeping declarative workflows only for simple tasks. This creates architectural fragmentation and additional operational overhead.

These workarounds reinforce the need for native parallel execution support within declarative workflows rather than relying on indirect or fragile solutions.

### Code Sample

```markdown

```

### Language/SDK

Python