Agent Task Ownership Arbitration Prompt

This prompt is designed for platform operators and orchestration engineers who manage multi-agent systems where task contention is a live operational problem. Its job is to resolve conflicts when two or more agents claim ownership of the same task, producing a single, justified assignment decision. The prompt assumes you already have a task router or arbitration service that receives conflicting claims and needs a deterministic, auditable way to select one owner. It is not a general-purpose task dispatcher, a load balancer, or an initial assignment mechanism—use it only when a conflict has been detected and escalated to the arbitration layer.

To use this prompt effectively, each agent claim must include three structured fields: a specialization fit score (how well the agent's declared capabilities match the task requirements), a current load metric (e.g., queue depth, active task count, or utilization percentage), and a claim timestamp (ISO 8601, with timezone). The prompt evaluates these inputs against a defined tie-breaking policy—typically prioritizing specialization fit first, then load, then timestamp—and outputs a structured decision with a justification trace. You must also supply a [CONSTRAINTS] block that defines the arbitration policy (e.g., 'prefer specialization over load balancing' or 'enforce strict FIFO by timestamp') and an [OUTPUT_SCHEMA] that specifies the required fields: selected_agent_id, rejected_agent_ids, justification, and confidence. Without these structured inputs, the prompt will produce inconsistent or unverifiable results.

Do not use this prompt for real-time task assignment where no conflict exists—that path should use a simpler routing prompt with lower latency and cost. Do not use it when claims lack the required metadata fields; the prompt will hallucinate justifications rather than fail gracefully. In high-stakes environments where incorrect ownership could cause data corruption, duplicate mutations, or safety violations, always route the arbitration output through a human approval step before the selected agent proceeds. The next section provides the copy-ready prompt template you can adapt to your arbitration service.

This prompt template is the core arbitration instruction you will paste into your model's system or user message. It is designed to be stateless and deterministic: given the same set of claims and agent metadata, it should produce the same owner selection. The template uses square-bracket placeholders that your application must resolve before sending the request. Do not modify the arbitration logic unless you also update the corresponding eval assertions and tie-breaking test cases.

textCopy
You are a deterministic task ownership arbitrator. Your job is to evaluate conflicting claims from multiple agents on a single task and select exactly one owner. You must not split ownership, delegate, or suggest collaboration. Return only the selected owner's agent ID and a structured justification.

## INPUT
[AGENT_CLAIMS]

## ARBITRATION RULES
1. **Specialization Fit**: Prefer the agent whose declared specialization most closely matches the task's domain, required tools, and output schema. A perfect match beats a partial match.
2. **Current Load**: If specialization fit is equal, prefer the agent with the lower current load, as indicated by [LOAD_METRICS]. Load is measured by active task count, not queue depth.
3. **Claim Timestamp**: If specialization and load are equal, prefer the earliest claim timestamp. Stale claims older than [STALE_THRESHOLD_SECONDS] seconds must be discarded before comparison.
4. **Tie-Breaking**: If all factors are equal, select the agent with the lexicographically smallest agent ID. This ensures deterministic output.
5. **Single Winner**: You must select exactly one agent. If no valid claims remain after discarding stale ones, return a `no_valid_owner` result.

## CONSTRAINTS
- Do not invent agent capabilities not present in [AGENT_CLAIMS].
- Do not consider agents not listed in [AGENT_CLAIMS].
- Do not propose a new agent or a human fallback.
- If the task requires capabilities no claiming agent possesses, return `no_valid_owner`.

## OUTPUT_SCHEMA
Return a valid JSON object with exactly these fields:
{
  "selected_agent_id": "string | null",
  "reason": "string",
  "discarded_claims": [
    {
      "agent_id": "string",
      "discard_reason": "string"
    }
  ]
}

If no valid owner, set `selected_agent_id` to null and explain why in `reason`.

To adapt this template, replace each placeholder with live data from your agent registry and task queue. [AGENT_CLAIMS] should be a structured array of claim objects, each containing the agent's ID, declared specialization tags, current load metrics, claim timestamp, and any task-relevant capability evidence. [LOAD_METRICS] should be a map of agent IDs to their active task counts. [STALE_THRESHOLD_SECONDS] should match your system's claim expiry policy—typically 30 to 300 seconds depending on task latency requirements. Before deploying, run this prompt against the tie-breaking and stale-claim test scenarios described in the evaluation section of this playbook. If your system operates in a regulated domain, log the full arbitration payload and result for audit review.

This prompt should be deployed as a stateless arbitration service called by your agent orchestrator whenever a claim conflict is detected on a task queue. The orchestrator collects all active claims for a given task ID, packages them into the [CONFLICTING_CLAIMS] input, and calls this prompt to produce a single ownership decision. The prompt does not modify the task queue directly—it returns a structured verdict that the orchestrator enforces by revoking losing claims and confirming the winner. Keep the prompt stateless: do not rely on conversation history or session memory. Every call must be self-contained with all evidence provided in the input payload.

Validation and retry logic is critical because an invalid arbitration output can orphan tasks or grant ownership to an agent that has already timed out. After receiving the model response, validate the JSON schema strictly: selected_agent_id must match one of the input claim's agent_id values, reasoning must be a non-empty string, and tie_breaking_factors must be an array of strings. If validation fails, retry once with the same input and an additional [CONSTRAINTS] note flagging the specific validation error. If the second attempt also fails, escalate to a human operator with the full claim set and both failed responses. Log every arbitration call—including input claims, model output, validation result, and final enforced decision—to an append-only audit table. This log becomes your evidence trail for debugging ownership disputes and measuring arbitration accuracy over time.

Model choice and latency budget matter here. This prompt requires careful reasoning over structured evidence, not creative generation. Use a model with strong JSON-following behavior and low hallucination rates on structured comparison tasks. Latency should be budgeted at 2–5 seconds for the arbitration call, including validation. If your orchestrator cannot block that long, implement an asynchronous arbitration pattern: queue the conflict, call the prompt, and apply the verdict to the next scheduling cycle. Do not skip arbitration under load—unresolved claim conflicts compound into duplicate work and state corruption. For high-throughput systems, consider caching recent arbitration decisions keyed by a hash of the sorted claim set to avoid re-arbitrating identical conflicts within a short window.

Tool use and RAG are not required for this prompt. The arbitration decision depends entirely on the claim data provided in the input. Do not inject external context or retrieval results unless your claim records are incomplete and you have a verified source of agent capability metadata. If you do enrich claims with agent capability profiles, add them to the [CONTEXT] section of the prompt template and ensure the enrichment happens before the arbitration call, not inside it. Human review is required when the prompt returns a confidence score below your threshold, when tie-breaking factors are contradictory, or when the losing claim has a timestamp older than your stale-claim expiry window but the agent is still actively reporting. In these cases, surface the full arbitration payload to a review queue with a clear summary of what the model decided and why it was uncertain.