Multi-Agent Task Assignment Collision Prompt

This prompt is for agent-framework builders and AI reliability engineers who need to resolve conflicts when multiple autonomous agents simultaneously claim the same task from a shared queue or work pool. The job-to-be-done is producing a single, deterministic assignee decision that prevents duplicate execution, respects priority rules, and avoids starving lower-priority agents indefinitely. The ideal user is someone integrating this prompt into an orchestrator's critical path—where a wrong assignment means a task runs twice or not at all—and who needs the decision to be auditable and reproducible.

Use this prompt when your system has a formal task model with defined fields for priority, required capabilities, agent workload, and task state. It works best when the collision is detected synchronously, before any agent begins execution, and when you can supply the full set of contending agents and the disputed task in a structured format. The prompt assumes you have already built the detection mechanism—this playbook only covers the resolution decision. Do not use this prompt for simple round-robin dispatching, for systems where tasks are stateless and idempotent by design, or when you lack a capability model for your agents. In those cases, a deterministic queue with a single consumer is safer and cheaper than invoking an LLM.

Before wiring this into production, define your evaluation criteria: zero duplicate assignments for the same task, no agent starvation over a configurable window, and a clear audit trail showing why one agent was chosen over others. The prompt is not a substitute for distributed locking or transactional task claiming—it is a recovery and arbitration layer that runs after a collision is detected. If your system cannot tolerate the latency of an LLM call on the assignment hot path, pre-compute assignments or use a rules engine. Proceed to the prompt template to see the exact input shape and decision logic.

This prompt template is designed to be dropped into an agent orchestration harness whenever a task-assignment collision is detected. It expects a structured description of the task, the set of contending agents, and the resolution rules your system enforces. The output is a machine-readable decision that your harness can act on directly—assigning the task to one agent, queuing it, or escalating for human review. The template uses square-bracket placeholders so you can wire it into your existing agent framework without rewriting the resolution logic each time.

textCopy
You are a task-assignment collision resolver for a multi-agent system. Your job is to produce a single, unambiguous assignee decision when multiple agents claim the same task.

## TASK
[INPUT: Full task description, including required capabilities, deadline, priority level, and any resource constraints.]

## CONTENDING AGENTS
[INPUT: JSON array of agent objects. Each object must include: agent_id, claimed_capabilities (list), current_workload (integer count of active tasks), priority_tier (integer, lower is higher priority), and claim_timestamp (ISO 8601).]

## RESOLUTION RULES
[CONSTRAINTS: Ordered list of rules to apply. Example rules: "1. If one agent has strictly higher priority_tier, assign to that agent. 2. If priority ties, assign to the agent with the lowest current_workload. 3. If still tied, assign to the agent with the earliest claim_timestamp. 4. If no agent meets required capabilities, return 'unassignable'."]

## OUTPUT SCHEMA
Return ONLY a valid JSON object with these fields:
- "decision": "assigned" | "unassignable" | "escalate"
- "assigned_agent_id": string | null
- "reasoning": string (brief explanation referencing which rule resolved the collision)
- "rejected_agent_ids": array of strings (all agents not assigned)
- "starvation_flag": boolean (true if any rejected agent has been rejected for this task type more than [STARVATION_THRESHOLD] times in the current window)

## EXAMPLES
[EXAMPLES: Provide 2-3 few-shot examples showing input collision data and the correct output decision. Include at least one example where no agent is assignable and one where starvation_flag is true.]

## RISK LEVEL
[RISK_LEVEL: "low" | "medium" | "high". If "high", append: "Before finalizing, log the decision for human review and do not execute the assignment automatically."]

To adapt this template, start by replacing the [CONSTRAINTS] block with your organization's actual task-assignment policy. If your system uses a capability-matching vector instead of simple string lists, preprocess that into the claimed_capabilities field before calling the prompt. The [STARVATION_THRESHOLD] should be tuned to your workload patterns—too low and you'll get false starvation flags; too high and you'll miss genuine starvation. For high-risk domains such as infrastructure provisioning or clinical task routing, set [RISK_LEVEL] to "high" and ensure your harness respects the human-review gate before executing the assignment. The few-shot examples in [EXAMPLES] are critical for teaching the model the exact tie-breaking behavior you expect; invest time in crafting examples that mirror your most common collision patterns.

Before deploying, validate that your harness can parse the output JSON and act on all three decision values. A common failure mode is handling "assigned" but silently ignoring "unassignable" or "escalate", which leaves tasks orphaned. Wire the starvation_flag into your monitoring dashboard so operators can detect agents that are consistently deprioritized. Finally, log every collision resolution with the full input and output for at least one retention period—this audit trail is essential for debugging fairness complaints and tuning your resolution rules over time.

The Multi-Agent Task Assignment Collision Prompt operates inside the task-dispatch loop of an agent orchestrator. When two or more agents claim the same task within a configurable collision window, the harness must pause assignment, collect the competing claims, and invoke this prompt before committing any agent to execution. The prompt is not a real-time arbiter; it is a decision service that the orchestrator calls synchronously before mutating task state. This means the harness must hold a lock or use an atomic compare-and-swap on the task record to prevent a third agent from claiming the task while collision resolution is in flight.

Wire the prompt into the orchestrator with a collision-detection trigger that fires when count(pending_claims) > 1 for the same task_id. The harness assembles the prompt context from three sources: the task definition (priority, required capabilities, deadline, estimated duration), the claiming agents' profiles (capability matrices, current workload, recent task-completion history), and any organizational policy overrides (cost caps, agent affinity rules, fairness constraints). The prompt returns a structured decision object with assigned_agent_id, rejected_agent_ids, reasoning, and a starvation_counter increment for each rejected agent. The harness must validate this output against a schema that enforces exactly one assignee, non-empty reasoning, and workload-ceiling checks before applying the decision. If validation fails, retry once with the validation errors appended to [CONSTRAINTS]; if it fails again, escalate to a human operator or a fallback round-robin assignment.

Build eval gates directly into the harness. After every resolution, log the decision and run two automated checks: a duplicate-execution check that verifies no other agent is currently executing the same task, and a starvation check that flags any agent whose starvation_counter exceeds a threshold (e.g., 5 consecutive rejections) and forces a priority-boost or human review. For model choice, use a fast, instruction-following model (GPT-4o or Claude 3.5 Sonnet) with temperature=0 and response_format set to a strict JSON schema. Do not use a reasoning model here—the prompt is a structured arbitration task, not an open-ended analysis. If your orchestrator processes high-throughput task queues, cache agent capability profiles and workload snapshots for 30–60 seconds to avoid redundant model calls for the same collision cluster. The next step is to integrate the starvation counter into your agent-selection policy so that repeatedly rejected agents gain priority in future assignment rounds, closing the loop on fairness.