Writing a Conflict-Resolution Policy for Agent Actions

The ladder is an ordered list. The first rule that matches decides. Every agent loads the same list, so two agents that collide produce the same winner regardless of which one noticed the collision first.

Three notes on making the ladder work.

First, rank 3 names roles, not individuals, and the role list is versioned alongside the policy. "Compliance outranks marketing" is a rule you can test. "Ask Dave" is not.

Second, rank 4 needs a tie-breaker that does not depend on wall-clock timestamps, because clocks disagree across machines. Use a monotonic sequence number attached by the observation source, and if two sequence numbers are equal, fall through to rank 5. The accepted way to detect conflicts between two candidate claims is the standard interval overlap test, Start1 <= End2 AND Start2 <= End1 (SQLServerCentral). The same arithmetic applies when two agents try to claim one calendar slot or one payable invoice.

Third, rank 5 needs a named queue and a timeout. An escalation rule with no queue is a deadlock.

A minimal ladder file, loaded at start-up, looks like this:

policy_version: 7
ladder:
  - id: human_override
    when: action.source == "human"
    beats: all
  - id: owner_agent
    when: agent.id == resource.owner_agent_id
    beats: [role_seniority, freshness]
  - id: role_seniority
    order: [compliance, finance, support, sales, marketing]
  - id: freshness
    compare: observation.sequence_number
  - id: escalate
    queue: agent-conflicts
    timeout_minutes: 30

The point of the file is that it is data, not prompt text. Two agents reading the same file cannot disagree about the order.

The cheapest conflict is the one you define out of existence. Two agents editing different fields of the same record are not in conflict, and treating them as if they were is the most common source of needless escalations.

Sort every shared record into fields and assign each field a merge strategy:

Two habits make this work. Keep the loser's value in a shadow field or the decision log rather than discarding it, because someone will ask why a note vanished. And make the merge functions total: every field gets a rule, including the ones nobody has fought over yet, because the field nobody fights over today is tomorrow's escalation.

The calendar world shows why visibility without blocking fails. Sharing a calendar lets you see events, but seeing is not blocking: a colleague's invite only checks the busy state of that one calendar, so a personal event does not stop a work meeting from landing on top of it (Chronock). The same failure appears with agents. An agent that reads a shared record and then writes it, with no reservation between the two steps, creates a race. Real-time two-way sync, where a slot is removed from availability the moment it is taken, is what closes the gap (Cal.com). In your own systems, the write path must claim the slot, not merely observe that it was free.

For interval-shaped fields (booked windows, service periods, validity ranges), accept a write only if it does not overlap an existing one, and reject it with the conflicting window attached so the agent can propose an alternative. That single constraint removes the whole double-booking class of conflicts before the ladder is consulted.

Money is where a wrong resolution is expensive and hard to unwind. Treat money-moving actions as a separate class with their own hard rules, layered on top of the ladder.

One writer per account. Each money account has exactly one agent identity authorized to write, and the authorization is enforced at the account level, not in the prompt. Other agents submit intents to the writer. This removes account-level races rather than resolving them.

Reserve before you act. Before any commit, hold the amount so a second agent sees it as unavailable. An unguarded agent that retries on timeout can produce duplicates in a short burst that no fraud rule catches; reconciliation finds them the next morning, when the customer disputes every charge and the auditor asks who authorized the purchase (Formance). The reserve step is the difference between a queue and a race.

Two-phase commit with a compensating action. Phase one reserves and records intent. Phase two commits. If phase two fails, the compensating action releases the reservation and writes a reversal entry, and the retry reuses the same idempotency key so the second attempt cannot double-spend. Idempotency keys are the standard mechanism for making retried requests safe to repeat, which is why payment APIs document them as a first-class feature (Stripe). An API call is a defined request and response between software systems (AWS), so the key belongs in the request contract, not in the agent's memory.

An approval gate above a threshold you set. Pick the threshold from your own loss tolerance, not a vendor default. Four autonomy models give you a menu: a human confirms every transaction; the agent holds a scoped credential with per-transaction limits and no per-transaction sign-off; the agent holds a virtual card with network-enforced spend rules; the agent holds its own wallet (Formance). For most enterprises the first or second covers the bulk of volume, with the higher models reserved for tightly capped spend.

A decision log that records who won and why. Every money-moving action writes the action id, the idempotency key, the agent identity, the ladder rule that authorized it, the amount, the reservation id, the commit or reversal outcome, and the approver if a gate applied. Without it, an auditor's question has no answer.

A worked example makes the cost visible. An invoice agent and a treasury agent both act on the same 4,000 dollar payable. Treasury sees a cash buffer below target and wants to defer. Invoice sees a due date and wants to pay. Without reservations, both commits land and the vendor is paid twice. With the rules above: single writer means only the invoice agent can pay; the reserve step makes the 4,000 unavailable when treasury reads the account, so treasury's deferral becomes an intent rather than a write; the conflict goes to the ladder, where finance outranks sales and the deferral wins for the cycle. The decision log records both intents and the rule. Added cost: one reservation row and one log entry.

The same logic at the boundary, in code:

def pay(account_id, amount, idem_key, agent):
    assert agent.id == accounts[account_id].writer_id
    if not reserve(account_id, amount, idem_key):
        return conflict(rule="reserve_held", amount=amount)
    try:
        txn = commit(account_id, amount, idem_key)
    except CommitFailed:
        release(account_id, idem_key)
        log_reversal(idem_key, agent)
        raise
    log_decision(idem_key, agent, rule="owner_agent", amount=amount)
    return txn

The human end of the ladder deserves its own design. A gate that stops work for hours is worse than no gate, because teams route around it.

Progressive trust is the pattern worth copying. A system can start in a confirmation mode where it proposes actions (a booking, a reschedule, an update) and waits for staff confirmation before anything writes to the system of record; once the team is satisfied, it switches to automatic sync (Elva). Applied generally: week one, every consequential write is proposed and approved. Week two, low-risk classes auto-commit and money stays gated. Record the mode and the date of each change in the policy file, because "who decided this agent could write directly" is a question that eventually arrives.

Handoffs need context, not just routing. When a voice agent transfers a caller, the receiving person should get the reason, the captured information and the cause of the handoff so the caller does not start over (VocalOps). Your agent-to-human escalation should carry the same package: the colliding actions, the ladder rule that failed to decide, the fields in dispute, and a proposed resolution. A human who receives "conflict on invoice 4471, finance wants defer, sales wants pay, here are both intents" resolves in seconds. A human who receives "agent needs help" starts from zero.

Capability boundaries belong in the policy too. Permission matrices that toggle each capability per channel, with separate settings for sensitive topics drafted and held for approval, are a practical way to keep the gate narrow (Elva). Translate that to your own channels: allow cancellation by phone but not by email if the identity signal is weaker there, and hold financial replies for approval rather than blocking every reply.

The decision log turns a policy into something you can audit and improve. Record the timestamp, policy version, colliding action ids, winning action, the deciding ladder rule, any field-level merge rule, the human approver, and the outcome. Write it append-only, then review it on a schedule for two signals. Rule distribution tells you which rule does the real work; if 60 percent of resolutions come from one rule, the others are decoration, so tighten or delete them. Escalation rate tells you where the ladder is incomplete: each cluster of similar rank-5 escalations is a candidate new rule.

The log also supplies the numbers for the approval threshold. Pull the distribution of money amounts and the reversal rate per class, then set the threshold where expected error cost (amount times reversal frequency plus cleanup hours) exceeds the cost of one approval minute. That is a calculation you can defend, unlike a threshold copied from a blog post.

For teams running several agents across a line of business, policy design and operating discipline converge on the same questions: which agent owns which writes, what gets gated, and who reviews the log. That is the kind of setup Quanta Experts (https://quantaintelligence.ai/agents) fits, since each expert reads your context, does the work and hands back finished deliverables, including a draft policy and decision-log schema you can review.

A policy never tested against failure is a wish. Run these five tests against a staging copy of the ladder.

The partial failure and duplicate tests matter most, because both produce money errors and both are preventable with the reserve and idempotency rules. The clock skew test catches the subtle bug where an agent wins on freshness because its host clock runs fast. Add one more: a sample set of thirty labeled conflicts that two agents must resolve identically. Divergence means the policy text is ambiguous, and the sample set becomes the regression suite for every future edit. If your agents speak through one API layer, those tests run across model providers without a new harness; that is how Quanta Inference (https://quantaintelligence.ai/inference) is arranged, with text, image, video, audio and embedding models behind one OpenAI-compatible key, prepaid and priced in US dollars.

Put the policy in one versioned file with five sections in this order: scope (which resources and action classes it covers), the ladder, the per-field merge table, the money rules with thresholds and approvers, and the escalation and review process. Keep it short enough that a new engineer reads it in one sitting, and require a version bump for every change, logged with who approved it and why.

Two writing rules carry most of the quality. Every rule must be decidable by a machine from data it already has; "use judgment" is not a rule, it is an escalation with no queue. And every rule needs a named counterexample in the document, a case it deliberately does not cover, because the boundary is where reviewers find the gaps.

The policy is finished when three people can independently resolve the same ten conflicts using only the document and reach the same answers. Until then it is a draft, and no money-moving agent should run against it.