Merging Multi-Agent Results: Provenance, Conflict Arbitration, and Atomic Commits
After multiple agents return results, concatenation or voting loses evidence and applicability conditions. This article designs candidate-result lineage, deterministic conflict classification, arbitration records, and atomic publication so merged conclusions can be recomputed and revoked.
Key Points
- Topic Focus: AI、大模型、AI Agent
- Suitable for: indie hackers, full-stack engineers, AI application developers
- Core value: quickly understand background, practical paths, common pitfalls, and engineering advice
Have three agents research security, cost, and performance separately, then ask an "editor-in-chief" to write the conclusion, and the merge may appear complete. The real risk is that the editor receives only three blocks of text: it does not know which conclusion came from which input version, which evidence was cited repeatedly by two candidates, or that "upgrade immediately" and "stay on the old version" actually apply to different environments. Majority voting is equally unreliable: three replicas derived from the same source do not constitute three independent pieces of evidence.
RAG Citation Provenance connects claims in an answer to document chunks, while Agent Memory Consolidation Lineage handles the reversible integration of long-term summaries. This article focuses on how multiple executable candidates enter the same canonical result within a single multi-agent run while ensuring that the arbitration decision itself remains auditable.
result-envelope.v1 Does Not Accept Bare Text
Each candidate must include a candidateId, runId, producer node and attempt, input artifact digest, sourceEpoch, authorizationEpoch, output schema, implementation/model/prompt/policy versions, structured claims, evidence, assumptions, scope, and confidence rationale. The body may be stored as an artifact, but it cannot be the only interface.
{
"schemaVersion": "result-envelope.v1",
"candidateId": "cand_security_7",
"producer": {"node": "security", "attempt": "a3", "fence": 12},
"inputs": [{"artifactId": "repo_9", "digest": "sha256:..."}],
"claims": [{"claimId": "c17", "predicate": "deployable", "value": false,
"scope": {"env": "prod"}, "evidence": ["ev_31"]}]
}
Digest computation uses fixed character encoding, field ordering, and numeric representation; RFC 8785's JSON Canonicalization Scheme can serve as the basis for JSON signature input. Duplicate keys, non-finite numbers, and unknown schemas must be rejected before hashing; each language cannot be allowed to stringify values arbitrarily. W3C PROV's Entity, Activity, and Agent relationships are suitable for describing artifacts, transformations, and executors, but the business domain must still freeze its own bounded fields and versions.
CandidateSet stores the expected producers, each producer's terminal state, OPEN/SEALED status, set version, and seal generation. A registration transaction accepts only valid attempts from expected producers while the set is OPEN, and increments the set version; late results go only to quarantine. Once all required producers have reached terminal states and optional producers have been closed according to a versioned deadline policy, CAS changes OPEN -> SEALED, freezing the ordered candidate root, provenance root, source/auth epoch, and seal generation. Candidates can subsequently enter only the next generation and cannot modify the sealed set. Multi-Agent Task Claims provide attempt fencing; shared memory still follows Concurrency Control for Multi-Agent Shared Memory.
Classify Conflicts Before Choosing Rules
The normalization service groups claims by subject, predicate, scope, and validity interval, then generates SUPPORTS, COMPLEMENTS, CONTRADICTS, SUPERSEDES, or INCOMPARABLE edges. Conclusions with different scopes are usually complementary and should not be forced into a binary choice. Candidates derived from the same evidence must be marked with a common ancestor to prevent duplicate votes. A candidate missing required evidence is incomplete, not a "minority opinion." A semantic classifier may propose edges, but the final type for a high-risk predicate must be confirmed by rules or a human.
Arbitration policies are versioned by claim type. Measurable values use predefined aggregation only after their units and observation windows are aligned. Normative facts prioritize valid, accessible primary sources. Code changes must pass an independent testing gate. Risk assessments retain dissenting opinions and applicability conditions. Security or compliance conflicts default to UNRESOLVED; model confidence scores cannot be averaged. Unlike RAG Evidence Conflict Resolution, candidates here may also contain patches, plans, and tool artifacts, so arbitration must check side-effect preconditions and artifact compatibility.
ArbitrationDecision.v1 stores the candidate-set digest, conflict-graph digest, rule version, accepted and rejected claims, reason codes, human actor, approvals, and expiration time. Model-generated natural-language explanations are only supplementary presentation; the decision must be reviewable through bounded enumerations and references.
Publish the Canonical Result with CAS
The merger reads only SEALED sets. The publication transaction locks the run and validity clock; rechecks the DAG revision, seal generation, candidate/provenance root, current source/auth epoch, and result version; and verifies individually that every evidence item remains accessible. Only if every check matches does it write canonicalResultVersion+1, the arbitration record, and the outbox entry. After sealing, no late candidate can enter the same generation. Revocations and revisions advance their respective epochs first, so only one side can succeed when racing with a commit. Downstream systems consume only canonical commits.
When a source is revoked, an input is revised, or an error is detected, first advance the epoch so the old result cannot continue propagating. Then use provenance to find the affected claims, create a higher-version REVOKED record, seal a new set from the currently valid inputs, and recompute forward. The user interface displays unresolved conflicts and scopes. Human Approval Gates for Agents can be used for irreversible conclusions, but the approval digest must bind the sealed root, epoch, and policy digest.
Concurrency and Adversarial Testing
Make candidate registration race with OPEN -> SEALED, and assert that the candidate either enters the root or is rejected. Of two mergers, only one may commit. Then race an epoch advance caused by revocation against publication, and cover duplicate evidence, unit/environment conflicts, forged producers, tampered artifacts, stale attempts, and arbitration timeouts. Property tests verify that candidate ordering does not change the result, duplicate candidates do not increase weight, and every canonical claim can be traced to currently accessible inputs.
Metrics include coverage of claims with lineage, unresolved conflict rate, common-ancestor deduplication rate, arbitration CAS conflicts, candidate-to-publication latency, human review volume, revocation propagation time, and the number of results that cannot be recomputed. Critical thresholds are 100% evidence coverage for high-risk claims, zero canonical claims without sources, and identical replay digests for the same candidate set.
For rollout, first build provenance and conflict graphs in shadow mode, then use the new format only for new runs. Freeze promotion when anomalies occur. A previous version may be republished as input to a new canonical version only if its provenance, source/auth epoch, and policy remain valid; otherwise, publish REVOKED/UNAVAILABLE and rebuild forward from the currently valid inputs. Rollback must not delete provenance or turn unresolved conflicts into success. Before recovery, replay the sealed root and rules, confirm that the digest matches, and then gradually reopen arbitration.
Related
Related Content
Article
What Is Vibe Coding? Will It Change How Programmers Work?
Technical trends, engineering practices, and an indie developer perspective on Vibe Coding, AI, and independent development.
Article
From Copilot to Codex: AI Coding Tools Enter the Agent Era
Technical trends, engineering practices, and indie-developer perspectives around AI, AI Agents, and Vibe Coding.
Article
Why Does MCP Matter? Understanding the AI Tool Protocol
Technical trends, engineering practices, and an independent developer perspective on MCP and AI Agents.
Article
Core Architecture of AI Agents: Planning, Memory, Tools, and Execution
Technical trends, engineering practices, and independent developer perspectives around AI Agents and large language models.