What happens when two agents produce conflicting outputs. Review gate patterns, human tiebreaker approvals, last-write-wins vs. merge strategies, and version-stamp conflicts.
Identify the three types of conflicts that arise in multi-agent systems, implement resolution strategies for each, and design conflict-resistant workflows.
Two agents try to work on the same logical resource (edit the same document, update the same database row).
Two agents produce contradictory outputs that must be merged (two researchers cite conflicting facts).
An agent tries to take an action that another agent (its manager) has not authorised.
Paperclip prevents resource conflicts through atomic checkout — two agents cannot claim the same issue. But if both are working on the same external resource (e.g., a Google Doc), you need an application-level lock.
Pattern: issue-as-lock
Create a dedicated "lock issue" that must be resolved before work begins:
-- Agent A claims the lock issue first
INSERT INTO issues (company_id, title, assigned_agent_id, priority, status)
VALUES ('cid', 'LOCK: Document edit session', 'agent-a-id', 'critical', 'open');
-- Agent A's work issue has depends_on: lock issue
-- Only created after lock is resolved
When two agents produce contradictory facts, a third "arbiter" agent resolves the conflict:
Researcher A → fact: "X was founded in 2015"
Researcher B → fact: "X was founded in 2017"
↓
Arbiter Agent (receives both outputs):
→ Fact-checks using primary sources
→ Picks the correct version
→ Notes the discrepancy in metadata
-- Create arbiter issue after both researchers resolve
INSERT INTO issues (company_id, title, description, assigned_agent_id, status)
VALUES (
'cid',
'Resolve conflicting research',
'Agent A says: ' || a_result || '\n\nAgent B says: ' || b_result ||
'\n\nVerify and resolve the conflict.',
arbiter_id,
'open'
);
An agent proposes an action that requires manager approval. The approval gate handles this automatically:
Worker Agent: "I need to purchase $200 of API credits"
→ Creates approval request (trigger: 'expenditure_request')
→ Manager Agent (or human) reviews
→ On approval: worker proceeds
→ On rejection: worker receives rejection reason
Add this to the worker's system prompt:
If your task requires spending money, hiring help, or external resources,
output {"request_approval": true, "reason": "...", "amount_usd": X}
instead of proceeding directly.
| Design choice | Why it reduces conflict |
|---|---|
| Immutable task assignments | Once assigned, ownership is clear |
| Structured handoffs (JSON) | No ambiguity in what was passed |
| Approval gates for critical actions | Authority is explicit |
| One agent per resource at a time | Resource locks prevent contention |