Skip to main content
Version: 1.0.0

Bounded parallelism

Use parallel to process a list of independent inputs. The program declares the target, arguments and limits; the runtime schedules branches without granting their agents or tools extra authority.

Group syntax​

parallel ProcessTicket
    each ticket in tickets
    with ticket as ticket
    max_concurrency 4
    max_items 32
    into results

This fragment belongs in a skill or strategy's do body, with a target declared in uses and an available typed list. The target may be a function, skill, strategy, agent or tool. Its output signature must be explicit: an output R produces a List of R. A pure function can be the target, but cannot contain this orchestration.

Two distinct bounds​

BoundEffect
max_itemsRejects the group before its first call if the list is too long.
max_concurrencyLimits simultaneously executing branches.
Host limitsMay tighten concurrency, live branches, external calls and depth.
Run budgetsRemain shared by branches and descendant calls.

Both source bounds are positive integers and max_concurrency <= max_items. There is no silent truncation. An empty list returns an empty list without calling the target.

Results, errors and effects​

Results follow input order, not branch completion order. The join waits for every branch: partial results are never published as success. An error stops new starts and requests cooperative cancellation of active branches. It does not retroactively undo an external effect already dispatched.

Variables and observations are isolated per invocation. Access to shared memory remains governed and writes are serialized by runtime locks; this does not replace transactions in a shared backend.

Pauses and resumption​

A human validation coordinates suspension of the group. The checkpoint preserves continuations, completed results and consumed budgets. Resumption revalidates authority and does not redispatch completed branches.

An unanswered ask pauses the group with user_input_pending. The host reads pendingInteractions (JavaScript) or pending_interactions (Python), saves the parallel checkpoint and supplies occurrence-specific answers through userInputs / user_inputs. Resumption retains completed branches and consumed budgets. Each answer belongs to one occurrence.