Agent Claim Registry Update Prompt

This prompt is for multi-agent system architects and platform engineers who need a reliable, machine-readable record of work ownership. The job-to-be-done is generating a structured claim record when an agent takes responsibility for a task, explicitly defining the scope of work, the resources it will touch, and an expiration time for that claim. Without this, multiple agents can silently pick up the same work, leading to duplicated computation, conflicting side effects, and reconciliation debt that compounds with every agent added to the system.

Use this prompt when you have a task router or orchestration layer that assigns work to agents and you need a central, queryable registry of active claims. The ideal user is an engineer wiring this into an agent framework's pre-execution hook, where the prompt's output is parsed and written to a database before the agent begins work. Required context includes a unique task identifier, a description of the work to be performed, the agent's declared capabilities, and a list of resources or state objects the agent intends to modify. The prompt is designed for environments where claim conflicts are resolved programmatically—either by rejecting late claims or by invoking a separate arbitration prompt.

Do not use this prompt as a standalone authorization mechanism. It does not enforce access control, validate agent permissions, or guarantee that an agent will actually complete the work it claims. It is a coordination primitive, not a safety guardrail. Avoid using it in systems where agents operate on independent, non-overlapping resource partitions, as the registry overhead adds latency without reducing conflict risk. For high-stakes mutations—such as database writes, financial transactions, or infrastructure changes—pair this prompt's output with a human approval step or a separate side-effect conflict detection prompt before execution proceeds.

The prompt below is designed to be invoked by an orchestration layer whenever an agent is assigned or self-selects a task. It forces the agent to declare the exact boundaries of its ownership, the evidence it used to claim the task, and a time-bound expiry. This structured output is then written to a central claim registry, which other agents and the orchestrator can query to prevent duplicate work. The template uses square-bracket placeholders that your application must populate before sending the request to the model.

textCopy
You are an agent operating within a multi-agent system. You have been assigned or have selected a task to execute. Before you begin any work, you must register your claim on this task in the central claim registry. Your claim prevents other agents from duplicating your effort and establishes your accountability for the outcome.

Generate a structured claim record using the exact JSON schema provided. The claim must be precise about what you own and what you explicitly do not own.

## Task Context
- Task ID: [TASK_ID]
- Task Description: [TASK_DESCRIPTION]
- Incoming Payload or User Request: [TASK_PAYLOAD]
- Your Agent Role: [AGENT_ROLE]
- Your Agent ID: [AGENT_ID]
- Current Active Claims in Registry (for conflict check): [ACTIVE_CLAIMS]

## Claim Rules
1. Your claim must include a specific, bounded scope. Do not claim the entire problem space.
2. Explicitly list any sub-tasks, resources, or domains you are NOT claiming.
3. Set a realistic expiry timestamp. If you cannot complete the task by then, the claim will be evicted.
4. If you detect a conflicting active claim in [ACTIVE_CLAIMS], you must set `claim_action` to "ABSTAIN" and explain the conflict in `conflict_note`.
5. Provide the evidence or reasoning you used to determine this task falls within your specialization.

## Output Schema
```json
{
  "claim_action": "CLAIM" | "ABSTAIN",
  "claim_id": "string (UUID v4)",
  "agent_id": "string",
  "task_id": "string",
  "scope": {
    "owned_objectives": ["string (specific, bounded sub-goals)"],
    "excluded_objectives": ["string (explicitly not owned)"],
    "resources_locked": ["string (tool names, data partitions, file paths)"]
  },
  "expiry_timestamp": "string (ISO 8601, must be in the future)",
  "confidence": 0.0-1.0,
  "specialization_rationale": "string (why this agent is the right owner)",
  "conflict_note": "string | null (required if ABSTAIN)"
}

Constraints

• Do not fabricate a claim if the task is outside your specialization. ABSTAIN instead.
• The expiry_timestamp must be no more than [MAX_CLAIM_DURATION_MINUTES] minutes from now.
• If [ACTIVE_CLAIMS] contains a claim for the same [TASK_ID] that is not expired, you must ABSTAIN.
• Output only the JSON object. No markdown, no commentary.

To adapt this template, replace the placeholders with live data from your orchestration system. [TASK_ID] and [TASK_DESCRIPTION] come from your task queue. [ACTIVE_CLAIMS] should be a serialized list of current, non-expired claims from your registry, filtered to the same task or overlapping scope. [MAX_CLAIM_DURATION_MINUTES] is a system-wide policy constant—set it based on your expected task latency and your stale-claim eviction job's run frequency. The most critical adaptation is the [ACTIVE_CLAIMS] injection: if this context is stale or incomplete, the agent cannot reliably detect conflicts, and duplicate work will occur. Ensure your registry read is strongly consistent or at least read-your-writes before invoking this prompt.

After receiving the output, your application harness must validate the JSON against the schema, verify the expiry_timestamp is in the future and within the allowed window, and check that claim_action is consistent with the presence of conflicts. If the agent returns ABSTAIN, do not dispatch the task; instead, route to a human or a conflict resolution prompt. If the agent returns CLAIM, atomically write the claim to the registry and check for a write conflict (another agent may have claimed the task between your read and write). A failed write should trigger a retry with refreshed [ACTIVE_CLAIMS]. For high-risk domains, log every claim and abstention decision for auditability.

This prompt is not a standalone chat interaction; it is a structured function call within an agent orchestration layer. The prompt expects a [TASK_ID], [AGENT_ID], [SCOPE_BOUNDARIES], and [EXPIRY_TIMESTAMP] as input, and it must return a valid, machine-readable claim record. The orchestration engine should treat this prompt as a transactional step: before an agent begins work, it must successfully register a claim. If the claim fails validation, the agent should not proceed with execution. The prompt's primary job is to enforce a structured schema, not to engage in open-ended reasoning.

Wire this prompt into a claim registry service that acts as the source of truth for task ownership. The service should expose an acquire_claim endpoint that internally calls the LLM with this prompt template, then validates the output against a strict JSON schema. If the output fails schema validation, retry once with a repair prompt that includes the validation error. If the second attempt fails, log the failure and escalate to a human operator. The registry must also implement a background job that periodically evicts claims where expiry_timestamp < now(), marking those tasks as UNOWNED and eligible for re-claiming. This prevents orphaned tasks from blocking the queue indefinitely.

For conflict detection, the harness must check the registry for an existing active claim on the same [TASK_ID] before inserting a new one. If a conflicting claim exists and is not expired, the harness should reject the new claim and return the existing owner's [AGENT_ID] and claim timestamp to the requesting agent. This check must be atomic to avoid race conditions when multiple agents attempt to claim the same task simultaneously. Use a database transaction or a compare-and-swap operation on the claim record. Log every claim attempt, conflict, and eviction for auditability. For high-risk domains, require a human approval step before an agent can claim a task that was previously owned by another agent and force-released due to a timeout.

Model choice matters here. This prompt requires high schema adherence and low-latency responses, not creative reasoning. Prefer a fast, instruction-tuned model with strong JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet, or a fine-tuned smaller model if claim patterns are stable). Set temperature=0 to maximize output determinism. The prompt should be treated as a system-level instruction, not a user message, to reduce the risk of injection or prompt drift. If your orchestration framework supports it, cache the system prompt prefix to reduce latency and cost on repeated claim operations.

Observability is critical. Emit structured logs containing the task_id, agent_id, claim_timestamp, expiry_timestamp, and the raw LLM response for every claim attempt. Export these logs to your monitoring stack and set alerts on claim conflict rates, schema validation failure rates, and stale claim eviction counts. A sudden spike in claim conflicts may indicate a routing bug where multiple agents are incorrectly assigned the same task. A rise in evictions may signal that agents are crashing or taking too long to complete work. Treat the claim registry as a key reliability signal for the entire multi-agent system.