Parallel Reconcile Merge

Parallel Reconcile-Merge

Overview

Parallelism itself is not the enemy — uncoordinated parallelism is. The chapter's safe pattern embeds a parallel window inside a sequential control flow: planning verifies the branches are truly independent, the branches run simultaneously reading different data sources and writing to separate channels, and only the merge node combines them.

This skill implements the execution + reconciliation half:

• Per-branch error isolation (tree-pipeline error aggregation): each branch runs in isolation; an exception is caught and recorded in that branch's own result. "One branch's failure shouldn't cascade to others or corrupt shared state." Branches receive a copy of context and never write shared state — only the merge node combines them.
• Reducer-style deterministic merge (Example 5-8): merge successful branch values with a reducer (add, extend, union, max, min) so the result is "deterministic merging regardless of execution order."
• Completion policy: all_or_nothing (every branch must succeed) vs partial_coverage (a quorum suffices — "sometimes three successful branches out of four provide sufficient coverage").
• Flag union: any red flag from any branch is surfaced; a failed sibling never silently drops another branch's flag.

In the DevOps latency investigation (account 123456789012), the planner spawns parallel hypothesis tests — database connection-pool metrics and payment-service memory profiles — reading different data sources. The pool branch raises a pool_exhausted flag; the memory branch comes back normal. Reconcile surfaces the flag, merges both findings, and (under all-or-nothing for a confirmation phase) reports completion only if both branches succeeded. The analogous claims case runs fraud / provider-credentials / medical-necessity branches the same way: any flag from any branch affects the final decision.

When to Use

• A planning node has verified branch independence (different data sources, no shared decision, no shared mutable state)
• Parallel hypothesis tests, multi-aspect verification (fraud / pricing / credentials), parallel research tracks
• You need deterministic merge + a quorum/all-or-nothing completion policy + flag aggregation

Phrases: "merge parallel branches", "reconcile branch results", "controlled parallelism", "error isolation across branches", "all-or-nothing vs partial coverage", "state reducer merge".

When NOT to Use

• Branches share mutable state or make a joint decision (uncoordinated parallelism — the documented failure mode; serialize or re-decompose first)
• Strictly sequential dependent steps (use a sequential pipeline)
• You actually need concurrency tuning — this is the isolation+merge contract; swap in threads/asyncio/Send API for the dispatch mechanism in production

Process

Rationalizations

Red Flags

• Branches mutate context and expect siblings to see it. They get copies by design; a branch relying on another branch's write is not independent and should not be in this window.
• all_or_nothing chosen for an exploratory fan-out. One flaky branch fails the whole window when partial coverage would have sufficed — wrong mode for the task.
• Flags empty but a branch reported a problem in its value. The branch is not surfacing red flags through the flags channel; the merge cannot union what it cannot see.

Non-Negotiable Verification

1. Run the benchmark battery. python cli.py benchmark must report:
   • a raising branch is isolated (ok=False) and siblings still run
   • all_or_nothing completes only when every branch succeeds
   • partial_coverage completes at the quorum and fails below it
   • flags are unioned across branches (including from non-failing siblings)
   • reducer merge is order-independent for a commutative reducer
   • succeeded/failed partition matches branch outcomes
2. Verify CLI help. Exits 0 and prints the SKILL.md description.

Security Posture

• Prompt injection. Branch results are untrusted - branches typically run LLM reasoning over untrusted sources. The merge treats values and flags as data (reducers, unions), never executing them; one compromised branch can bias the merged value but cannot rewrite siblings' channels, because branches get context copies and only the merge node combines.
• Data exfiltration. No network calls, no file writes in the window itself. The merge concentrates findings from every branch into one outcome - apply per-branch data-access policy upstream, since the merged report sees everything any branch saw.
• Privilege escalation. No shell invocation, no eval. The guarded property is signal integrity: flag union guarantees a failed or malicious sibling cannot suppress another branch's fraud/red flag, and completion policy - not any single branch - decides whether the window counts as done.

Source Attribution

Distilled from Agentic GraphRAG (O'Reilly, by Anthony Alcaraz and Sam Julien) Ch5 — Reasoning & Planning: "Tree Pipeline: Parallel Exploration" (Example 5-7), "State management across pipelines" reducer pattern (Example 5-8), and "The Multi-Agent Debate" / "The architecture of controlled parallelism" (Example 5-16) — independence verification, per-branch error isolation, and the ontologically-validated merge.