One customer issue.
A swarm that resolves it.

The specialist task invocations: CRM context, product entitlements, knowledge policy, billing adjustments, technical remediation, and escalation management. Each specialist has its own instructions and tool. Its model calls and tool execution can overlap with those of other specialists in the same wave.

The coordinator first creates the plan, then the runtime dispatches specialists. After their results are collected, the coordinator writes the final answer. Planning and final synthesis are separate stages around the parallel work.

All six are independent in the supplied instructions, but the preview default is five concurrent specialist tasks per run. With that setting, five can run in one wave and the remaining task in a later wave. A tenant with a different limit can group them differently.

The reviewed implementation waits for all branches in the current wave before scheduling the next one. It does not refill a freed slot immediately when the fastest specialist finishes. “Six tasks completed” confirms completion count; it does not establish six simultaneous executions.

1. Plan: the coordinator’s model calls submit_plan with task assignments and dependencies.
2. Dispatch: the scheduler selects ready tasks, up to the concurrency limit.
3. Execute: the Go state-machine engine starts a concurrent branch for each selected specialist invocation.
4. Join: a barrier waits for the wave, then applies its state updates sequentially. More ready work causes another dispatch.
5. Synthesize: collected outputs and task statuses are given to the coordinator’s model to produce one answer.

That is the source-level path plan → dispatch → specialist × N → barrier → dispatch or synthesis. Shared run state is updated at the join, rather than each specialist freely mutating it while peers run.

It is multiple agent invocations and model calls. The coordinator uses its configured model for planning and synthesis. Each native specialist runs with its own agent configuration and may make several model/tool turns.

The original downloaded YAMLs all select groq/openai/gpt-oss-120b; the unified launcher selects watsonx-orchestrate/frontier by default. Sharing a model identifier does not make them one invocation, and distinct models are not required for concurrency. Model availability, provider capacity, and rate limits still affect elapsed time.

Agent parallelism schedules several specialist tasks, each with its own role, instructions, and reasoning/tool loop. Tool parallelism concerns multiple tool calls inside one agent’s execution and is controlled separately.

This sample gives each specialist one business tool. Setting coordination: parallel on the coordinator does not make every tool call inside each specialist simultaneous; the specialist still follows its own execution flow.

Use exact matching output keys and put producers before consumers in the submitted plan. These are fields of the runtime plan, not extra top-level agent YAML settings.

The supplied instructions do not enforce that order. They explicitly request requires: [] for all six tasks. The demo’s “multi-wave” label and narrative do not create a dependency. An extra wave may simply be caused by the concurrency limit.

If billing must use the quota result, change the planning instructions to have the product task produce an entitlement artifact and the billing task require it. Then inspect the emitted plan and execution; a prose description alone is not proof that the required ordering happened.

This illustrative submit_plan payload makes billing consume the entitlement result. It explains the contract; it is not the downloaded sample’s plan and should not be pasted as agent YAML.

{
  "tasks": [
    {
      "id": "t2",
      "agent_id": "product_entitlement_agent",
      "display_text": "Check Acme quota",
      "execution_text": "Inspect entitlements for CUST-ENTERPRISE-8821.",
      "produces": ["entitlement_report"],
      "requires": []
    },
    {
      "id": "t4",
      "agent_id": "billing_action_agent",
      "display_text": "Review Acme relief",
      "execution_text": "Use the entitlement report to determine eligible relief for CUST-ENTERPRISE-8821.",
      "produces": ["billing_result"],
      "requires": ["entitlement_report"],
      "depends_on": ["t2"]
    }
  ]
}

The explicit depends_on repeats the ordering that requires implies here. Other independent tasks can still run alongside the quota check. An ordering dependency does not validate the business result or grant approval for an action; the consuming specialist/tool must check that its required evidence is present and acceptable.

They do not share a live conversation or see peers’ in-progress reasoning. Each branch gets a snapshot of previously collected artifacts when its wave starts. Required outputs are inserted into the specialist’s task message; new outputs are merged at the wave boundary.

The runtime also supplies coordination tools such as check_parallel_results, publish_artifact, and wait_for_artifacts. In the reviewed implementation, wait_for_artifacts reads available snapshot data; it does not suspend a branch until a same-wave peer publishes. Use a dependency and a later wave when fresh peer output is required.

A named artifact is content associated with a key. The runtime can store the specialist’s final text under its declared produces key; that name alone does not turn the result into a validated, typed business object.

In the general parallel pattern, a specialist can request follow-on work through post_follow_on_task. The unified launcher’s generated lab instructions explicitly prohibit follow-on tasks to keep this demonstration to the six assigned tasks. Those requests are collected and considered for a later dispatch, subject to admission rules and configured budgets. Posting a task is not proof that it has been admitted or executed.

The current preview does not have a coordinator review-and-replan loop after the specialists finish. The coordinator’s last stage synthesizes their results. This is distinct from a specialist requesting additional work while it runs.

In the reviewed runtime, an invocation error can requeue that task for a later wave, with up to two retries after the initial attempt. Exhausted attempts mark the task failed. An engine-level failure can terminate the run; ordinary specialist failures can still lead to synthesis with partial results.

The synthesis prompt includes task status and asks the model to acknowledge gaps. If final synthesis fails or returns no content, the runtime can return a plain-text fallback of available specialist results.

A tool returning a normal response that says “not eligible” or “operation failed” is a business result, not necessarily an invocation error that triggers a scheduler retry. Check both task status and the reported business outcome. Retries do not provide rollback or exactly-once execution for external actions; real integrations need their own idempotency controls.

These are stage budgets, not a promise that the whole run finishes in 120 seconds. Waves, retries, model latency, and upstream limits affect the total. The facilitator must confirm tenant-specific settings; changing a YAML or the browser page does not change server concurrency limits.

The response stream includes thread.parallel.event envelopes. The parallel_event payload identifies events such as parallel.agent.started, parallel.agent.completed, and parallel.run.state. A started event carries the task and wave; a completion event can include task_state and a short result summary.

Inspect task_state: an invocation finishing may mean success, failure, or a retry being queued. Progress delivery is best-effort. Use thread.message.completed for the final answer, and read its task outcomes rather than treating the existence of a final message as proof that every action succeeded.

For this lab’s embedded chat, point at the Live coordinator and keep woAPI: "v2completions", as in step 8.

No. It helps when substantial work is independent. A useful approximation is:

Total time ≈ planning
           + sum of the slowest specialist duration in each wave
           + final synthesis
           + orchestration / network overhead

Dependencies, retries, and provider throttling can reduce the benefit. Multiple specialist calls plus planning and synthesis also consume model usage; shorter wall-clock time does not imply lower token cost. The recorded GIF is a demonstration, not a controlled benchmark.

The hosted preview guide says an active plan cannot stop to ask for clarification, and an in-progress run is not resumed after a service restart. Give every task the needed customer/ticket identifiers and instruct specialists to report missing information instead of waiting for the user.

The implementation records run, task, and artifact data, but stored data alone is not a crash-resume guarantee. For this fixture-only lab, you can submit the sample again after a failed run. With real external actions, first reconcile what completed before rerunning.

No. The coordinator must retain coordination: parallel, and the target runtime must have the preview enabled. The source gate is ORCHESTRATION_PARALLEL_ENABLED; participants use the facilitator’s enabled instance. A compatible ADK must preserve the field during import.

The general coordinator supports a direct_answer path for simple requests. This demo’s instructions specifically demand submit_plan and six tasks. If it answers immediately without specialist progress, inspect the imported configuration and generated plan. The embed API setting selects the chat API; it does not enable the server feature.

In the bundled Customer Resolution source, all six Python tools return fixed sample JSON. The +1M API calls, $1,500 waiver, cleared 429 errors, and resolved ticket are fixture results. These functions do not call the billing system, gateway, CRM, or notification service.

To build a real integration, replace those functions with connected tools and define the data dependencies, permissions, business checks, and repeat-call behavior those actions require. Keep independent lookups parallel; make actions that need verified context depend on that context.

The participant-facing source of preview behavior is the hosted preview guide. The original agent YAMLs and tools are linked in What you imported; generated lab copies are in your local generated folder.

For readers with repository access, the source review used agent-runtime@f3e13c0b:

• Coordinator nodes: planning, waves, retries, artifact collection, synthesis.
• State-machine runtime: concurrent branches and the join barrier.
• Scheduler: task admission, dependency inference, ready-task selection.
• Coordination tools and synthesis: shared results, follow-on requests, and fallback output.

Source inspection explains the reviewed implementation; it does not identify the exact runtime build serving a tenant. The successful six-task recordings in this guide establish the demonstrated happy path, not every failure or recovery case discussed here.