Run the two-worker demonstration
Save pattern_05.py with test_pattern_05.py. Run python3 -B pattern_05.py on macOS or py -3 -B pattern_05.py on Windows. The expected output is status=conflict completed=2 failures=0. Run the same interpreter with -B -m unittest -v test_pattern_05.py to check behavior. Windows Python 3.13 was tested; the macOS command is guidance.
The two callables return fixed strings. They do not query telemetry or invoke models. A real worker adapter could occupy the same callable boundary, but would need authenticated input, transport deadlines, usage accounting and structured evidence output. The demonstration shows concurrency and aggregation separately from those concerns so its successful test result is not mistaken for a live multi-agent deployment.
Architecture and request sequence
Read the architecture as text
- Validated registry: One to eight named callables
- Thread pool: Configured maximum running workers
- Future identity map: Completion retains worker name
- Sorted result report: Stable successes and failures
- Aggregate status: No majority or evidence inference
- Validated registry → Thread pool: submit callable set
- Thread pool → Future identity map: retain future identity
- Future identity map → Sorted result report: sort accepted results
- Sorted result report → Aggregate status: derive explicit status
Read the sequence as text
- Caller → Collector: Call collect with two fixtures
- Collector → Workers: Submit named callables
- Workers → Collector: Return degraded and normal
- Collector → Review: Apply conflict policy
- Review → Caller: Print two results and no failures
Validate the worker registry before submission
collect accepts a dictionary of named callables and a thread limit. It requires one to eight workers, nonempty string names and callable values. The limit must be an integer between one and eight; booleans are rejected. Validation occurs before the pool is created. Empty work is rejected rather than returned as consistent, because the absence of observations should not masquerade as agreement.
The registry is already a dictionary when the function sees it. If upstream configuration accidentally used the same name twice, the dictionary may have overwritten one entry before validation. A production loader should detect duplicate names in its original list or configuration representation. That distinction illustrates why a function's local validation cannot establish every property of its input history. Document what the caller must guarantee as well as what collect checks itself.
Keep future identity attached to its result
The executor submits every callable and stores a mapping from Future to worker name. As futures complete, the loop uses that map to attach each result to the correct worker. A result must be normal or degraded; an invalid value or ordinary exception records the worker in failures. This means completion order does not become result identity. The report sorts the result keys and failure names before returning, giving deterministic presentation despite concurrent execution.
The implementation catches worker exceptions without reproducing their text. In a real service, log a sanitized error category and correlation identifier so failures remain diagnosable without leaking source payloads. The example records names only. It also waits for every callable inside the executor context, with no deadline or cancellation logic. Do not add a superficial timeout to the caller and then claim the underlying work has been stopped.
Read the aggregator as a policy function
After all workers finish, any failure makes the overall status incomplete. With no failures, multiple distinct accepted values make conflict; a single distinct value makes consistent. The tests exercise each path, invalid worker output, empty input and stable result ordering. Another test counts active workers under a lock while six fixtures execute, verifying that the configured limit of two is not exceeded. This is a behavioral concurrency check, not a benchmark.
The aggregator does not choose a majority, resolve causality or validate evidence. A pair of degraded results is consistent even if both came from the same incorrect assumption. A normal result and a degraded result are conflict even if their differing observation windows would explain both. A production envelope must include those windows and source identities before a richer policy can reason about them. Keep this simple policy available as a baseline during such changes.
Add durable collection and container boundaries
A proposed durable collector stores run identity, the expected worker set, task revision and one terminal record per worker. Use a uniqueness constraint on run and worker identity so redelivery cannot inflate completion. Record failure and timeout separately from observed state. Once an aggregation revision is published, late results should create a subsequent revision or remain excluded under an explicit policy. The current function has only process memory and cannot recover a partially completed run after restart.
A container reference runs the fixture under an unprivileged Python user with bounded CPU and memory. For live adapters, limit process concurrency and downstream requests independently, and give each worker only its required read capability. If hard isolation is needed, separate worker processes or services may be appropriate; threads alone do not create a security boundary. No container build or cloud rollout was performed. Test shutdown, late completion and resource reclamation in the actual deployment environment before claiming operational deadlines.
Implementation references and version scope
The original module and its tests are the primary references for this walkthrough. Python's versioned executor documentation defines the underlying API; the design article explains the relevant cancellation limitation. The fixture targets Python 3.11 or later. It establishes deterministic aggregation of synthetic results, not accuracy, speedup or resilient distributed execution.