This prompt is designed for reliability engineers and platform developers who operate multi-agent systems where two or more agents disagree on whether a specific action requires human approval. The core job-to-be-done is resolving a binary or multi-level approval trigger conflict into a single, defensible decision. The ideal user is someone integrating this prompt into an agent orchestration pipeline, not a business user manually copying text into a chat interface. The required context includes the original user request, the conflicting agent outputs with their stated rationales, the relevant organizational approval policy, and a risk classification for the action in question.
Prompt
Agent Output Conflict Resolution for Human Approval Trigger Disagreements Prompt Template

When to Use This Prompt
Define the exact job this prompt performs and the conditions under which it should—and should not—be deployed.
Use this prompt when your agent topology includes a dedicated 'approval gating' step and multiple agents (or multiple runs of the same agent) produce inconsistent verdicts on whether to escalate. It is appropriate for high-stakes actions such as financial transactions, data deletion, external communication, or configuration changes where an incorrect 'auto-approve' decision has significant blast radius. Do not use this prompt for low-risk, reversible actions where the cost of human review is higher than the cost of an error. It is also not a substitute for a deterministic policy engine—if your approval rules can be expressed as explicit boolean logic, implement them in application code instead of relying on an LLM arbiter.
Before wiring this prompt into production, ensure you have a structured schema for agent disagreement inputs and a logging sink that captures the final decision, the override rationale, and the identity of any human reviewer. The prompt assumes that the conflicting agents have already produced their outputs; it does not re-evaluate the underlying action. If the agents disagree because they received different evidence or operated under different policy versions, fix that upstream context mismatch before invoking this arbitration prompt. The next step after reading this section is to review the prompt template and adapt the placeholders to match your internal risk taxonomy and approval policy document.
Use Case Fit
Where the Agent Output Conflict Resolution for Human Approval Trigger Disagreements prompt works and where it introduces new risks.
Good Fit: High-Risk Action Gating
Use when: Agents disagree on whether a destructive or irreversible action (e.g., sending an email, running a database migration, executing a financial transaction) requires human approval. Guardrail: The prompt must receive the full action payload and the specific policy rule being evaluated, not just a summary of the disagreement.
Bad Fit: Ambiguous Policy Interpretation
Avoid when: The underlying approval policy is vague, contradictory, or relies on unwritten organizational knowledge. Risk: The LLM will hallucinate a coherent policy interpretation, creating a false sense of security. Guardrail: Do not deploy this prompt until the approval policy is written, versioned, and included as a grounded input.
Required Inputs: Structured Agent Positions
Risk: Feeding the prompt raw, unstructured agent logs leads to misinterpreting an agent's reasoning. Guardrail: Each agent's position must be provided as a structured object containing its decision (APPROVE/ESCALATE), confidence score, the specific policy clause cited, and the evidence it relied on.
Operational Risk: Override Documentation Drift
What to watch: When the prompt resolves a conflict by overriding an agent, the justification may not be persisted in the system of record. Guardrail: The output schema must include a mandatory override_justification string that is automatically written to an immutable audit log alongside the final decision.
Operational Risk: False Approval
What to watch: The prompt incorrectly resolves a disagreement by approving an action that should have been escalated. Guardrail: Implement a post-resolution check that compares the final decision against a hardcoded list of "never auto-approve" action types. If a match is found, force an escalation regardless of the prompt's output.
Bad Fit: Real-Time Latency Constraints
Avoid when: The system requires a sub-second decision on whether to escalate. Risk: An LLM arbitration step adds unacceptable latency to the critical path. Guardrail: Use a deterministic rule engine for the hot path and reserve this prompt for asynchronous post-hoc analysis and policy tuning.
Copy-Ready Prompt Template
A reusable prompt for resolving disagreements between agents about whether a human approval trigger should fire, producing a final decision with risk justification and policy alignment.
This prompt template acts as the final arbiter when two or more agents disagree on whether a given action or output requires human approval. It is designed to be wired into an agent orchestration pipeline after individual agents have already produced their approval recommendations. The template forces the model to reason over the conflicting positions, ground its decision in a provided policy, and produce a structured output that can be programmatically consumed to either block execution, allow it, or escalate to a human reviewer.
textYou are an approval arbitration agent. Your task is to resolve a disagreement between agents about whether a proposed action requires human approval before execution. ## INPUTS [AGENT_POSITIONS] <!-- A structured list of each agent's recommendation (APPROVE, BLOCK, ESCALATE), their confidence score, and their reasoning. --> [PROPOSED_ACTION] <!-- A description of the action the system intends to take, including affected resources and side effects. --> [APPROVAL_POLICY] <!-- The organization's policy defining when human approval is mandatory, optional, or not required. Include risk thresholds and override conditions. --> [CONTEXT] <!-- Any relevant session history, user role, data sensitivity level, or previous related decisions. --> [OUTPUT_SCHEMA] <!-- The required JSON structure for the final decision. --> [CONSTRAINTS] <!-- Specific rules such as 'never auto-approve actions affecting PII' or 'escalate if confidence below 0.8'. --> ## INSTRUCTIONS 1. Analyze each agent's position against the [APPROVAL_POLICY]. Identify which arguments are policy-aligned and which are based on misinterpretation or irrelevant factors. 2. Determine the risk level of the [PROPOSED_ACTION] by considering the worst-case outcome if the action is taken without human review. 3. Produce a final decision of APPROVE, BLOCK, or ESCALATE. 4. Justify your decision by referencing specific clauses in the [APPROVAL_POLICY] and explaining why you agreed with or overruled each agent. 5. If you ESCALATE, formulate a clear, single question for the human reviewer to answer. 6. Output your decision strictly according to the [OUTPUT_SCHEMA].
To adapt this template, replace the square-bracket placeholders with data from your application context. The [AGENT_POSITIONS] should be a serialized list of objects containing the agent ID, its vote, and its reasoning. The [APPROVAL_POLICY] is critical for grounding; without it, the arbiter has no basis to overrule an agent and will default to the safest (often most disruptive) option. Before deploying, run this prompt against a golden dataset of known disagreements where the correct approval decision is documented. Measure both the false approval rate (allowing a risky action) and the unnecessary escalation rate (blocking a safe action) to calibrate the [CONSTRAINTS] field.
Prompt Variables
Inputs required for the Agent Output Conflict Resolution for Human Approval Trigger Disagreements prompt. Each variable must be populated before the prompt is assembled and sent to the model.
| Placeholder | Purpose | Example | Validation Notes |
|---|---|---|---|
[AGENT_OUTPUTS] | Array of agent outputs that disagree on whether human approval is required. Each entry must include the agent's proposed action, its approval recommendation, and its stated rationale. | [{"agent_id":"agent-1","action":"DELETE_USER_ACCOUNT","approval_required":true,"rationale":"Destructive action per policy A.2"},{"agent_id":"agent-2","action":"DELETE_USER_ACCOUNT","approval_required":false,"rationale":"User confirmed identity via MFA"}] | Must contain at least 2 agent outputs. Each entry must have agent_id, action, approval_required (boolean), and rationale fields. Reject if any agent output is missing required fields. |
[APPROVAL_POLICY] | The organization's human approval policy document, including action categories, risk thresholds, and override conditions. | "Human approval is required for: (1) destructive actions on production data, (2) financial transactions over $500, (3) PII exports. Override allowed when user provides multi-factor confirmation." | Must be a non-empty string. Policy should be self-contained and referenceable by clause. Validate that policy covers the action types present in [AGENT_OUTPUTS]. |
[ACTION_CONTEXT] | Metadata about the action being evaluated, including user identity, session details, and environmental factors. | {"user_id":"usr_4521","session_auth_level":"mfa_verified","action_target":"production_db","timestamp":"2025-03-15T14:22:00Z"} | Must be a valid JSON object. Required fields: user_id, session_auth_level, action_target. Validate that action_target matches the action described in agent outputs. |
[RISK_THRESHOLD] | The organization's risk tolerance configuration, expressed as a structured threshold for auto-approval vs. escalation. | {"max_auto_approval_risk_score":3,"require_human_if_agents_disagree":true,"escalation_contact":"oncall-security@example.com"} | Must be a valid JSON object. Required fields: max_auto_approval_risk_score (integer 1-10), require_human_if_agents_disagree (boolean). Validate that risk score is within defined range. |
[PREVIOUS_DECISIONS] | Optional array of similar past conflict resolution decisions for consistency reference. Use null if no history exists. | [{"conflict_id":"c_001","action":"EXPORT_USER_DATA","final_decision":"approval_required","reasoning":"Policy C.3 applies; MFA not sufficient override"}] | Can be null or an array. If provided, each entry must have conflict_id, action, final_decision, and reasoning fields. Validate that referenced actions are comparable to current conflict. |
[OUTPUT_SCHEMA] | The expected JSON schema for the final resolution output, including required fields for decision, justification, and audit trail. | {"type":"object","required":["final_decision","risk_justification","policy_alignment","override_documentation"],"properties":{"final_decision":{"type":"string","enum":["approval_required","auto_approve","escalate"]}}} | Must be a valid JSON Schema object. Required top-level fields: final_decision, risk_justification, policy_alignment, override_documentation. Validate that enum values match expected decision types. |
[CONFLICT_METADATA] | Operational metadata about the conflict itself, including detection method, timestamp, and pipeline stage. | {"conflict_id":"conf_7823","detection_method":"approval_disagreement_detector_v2","pipeline_stage":"pre_execution_review","detected_at":"2025-03-15T14:22:01Z"} | Must be a valid JSON object. Required fields: conflict_id, detection_method, pipeline_stage. Validate that pipeline_stage is one of: pre_execution_review, post_execution_review, runtime_intercept. |
Implementation Harness Notes
How to wire the agent output conflict resolution prompt into a production application with validation, retries, logging, and human review integration.
This prompt is designed to be the final decision node in a multi-agent pipeline where two or more agents disagree on whether human approval is required before executing an action. The implementation harness must treat this prompt as a deterministic policy engine, not a conversational assistant. Wire it into your application as a synchronous function call that receives structured agent positions and returns a structured decision payload. The prompt expects a JSON input containing the proposed action, each agent's approval recommendation with justification, the governing policy, and the risk level. The output is a JSON object with a final decision (APPROVE_AUTO, ESCALATE, or REJECT), a risk justification, policy alignment notes, and an override documentation block. Because this prompt makes decisions that can trigger irreversible actions or block critical workflows, the harness must enforce strict validation on both input and output before any downstream system acts on the result.
Validation and retry logic is the backbone of this harness. Before calling the model, validate that all required input fields are present: [ACTION_DESCRIPTION], [AGENT_POSITIONS] (with at least two entries containing agent_id, recommendation, and justification), [POLICY_DOCUMENT], and [RISK_LEVEL]. After receiving the model response, validate the output JSON against a strict schema that requires final_decision to be one of the three allowed enum values, risk_justification to be a non-empty string, and override_documentation to be present even when no override occurs (use an explicit `
none
value). If validation fails
retry up to two times with the validation error message appended to the prompt as `[PREVIOUS_ERROR
Expected Output Contract
Fields, types, and validation rules for the final approval decision payload produced by the conflict resolution prompt.
| Field or Element | Type or Format | Required | Validation Rule |
|---|---|---|---|
final_decision | enum: APPROVE | ESCALATE | REJECT | Must match one of the three enum values exactly. Parse check required. | |
risk_justification | string (max 500 chars) | Must contain at least one explicit reference to a policy clause from [POLICY_CONTEXT]. Citation check required. | |
policy_alignment | array of objects | Each object must have 'policy_id' (string) and 'alignment_note' (string). Schema check required. Empty array allowed only if no policies apply. | |
override_flag | boolean | Must be true if final_decision contradicts any agent's recommendation. Logic consistency check required. | |
override_rationale | string (max 300 chars) | Required if override_flag is true. Null allowed otherwise. Conditional presence check required. | |
conflict_summary | array of objects | Each object must have 'agent_id' (string), 'recommendation' (enum), and 'reasoning' (string). At least two agents required. Schema check required. | |
escalation_package | object | Required if final_decision is ESCALATE. Must contain 'priority' (enum) and 'pending_decisions' (array of strings). Null allowed otherwise. Conditional presence check required. | |
audit_trail | object | Must contain 'timestamp' (ISO 8601), 'model_version' (string), and 'arbitration_method' (string). Schema check required. |
Common Failure Modes
What breaks first when agents disagree on whether to escalate for human approval, and how to guard against it.
False Approval: Agent Skips Required Review
Risk: An agent incorrectly classifies a high-risk action as safe, bypassing the human-in-the-loop checkpoint. This often happens when the agent over-indexes on user satisfaction or speed. Guardrail: Implement a secondary, lightweight policy-check agent that validates the approval decision against a hard-coded risk taxonomy before the action is executed.
Unnecessary Escalation: Alert Fatigue
Risk: The system escalates low-risk, reversible actions to human reviewers, flooding the queue and causing reviewers to ignore critical alerts. This is often due to an overly conservative or vague escalation policy. Guardrail: Define explicit, quantitative thresholds for escalation (e.g., 'escalate if data mutation affects > 10 records'). Log every escalation reason and run a weekly audit to tune the policy.
Policy Ambiguity in Edge Cases
Risk: The approval policy is silent on a specific scenario, causing the arbiter agent to hallucinate a justification or default to a safe-but-wrong escalation. This is common with novel user requests. Guardrail: Structure the arbiter's prompt to output a policy_gap: true flag when no existing rule clearly applies, forcing a deterministic escalation to a human policy author instead of guessing.
Context Stripping in Handoff
Risk: The arbiter agent resolves the conflict but fails to include the original agents' dissenting reasoning in the handoff package to the human reviewer. The reviewer lacks the context to make an informed decision. Guardrail: Use a strict output schema for the handoff that requires a dissenting_opinions array, and validate its presence programmatically before creating the review task.
Override Documentation Drift
Risk: A human reviewer overrides the AI's decision but provides an incomplete or ambiguous reason. This corrupts the audit trail and prevents future policy improvements. Guardrail: The review interface should require a structured override reason from a predefined, evolving taxonomy, rather than a free-text field, to ensure machine-readable feedback.
Temporal Risk Blindness
Risk: The arbiter evaluates risk based on the immediate action but fails to consider the downstream impact of a chained workflow. Approving a single low-risk step might enable a high-risk sequence. Guardrail: Provide the arbiter with a summary of the full planned agent trajectory, not just the immediate step, and instruct it to evaluate the 'cumulative risk' of the entire chain.
Evaluation Rubric
Use this rubric to test whether the conflict resolution prompt correctly decides when to trigger human approval. Each criterion targets a known failure mode in production agent pipelines.
| Criterion | Pass Standard | Failure Signal | Test Method |
|---|---|---|---|
False Approval Trigger | Prompt does not escalate when all agents agree on low-risk autonomous action and no policy threshold is breached | Output contains | Run 20 low-risk unanimous scenarios; assert approval_required is false in all cases |
Missed Escalation Trigger | Prompt escalates when any agent flags approval-required and provides a policy-cited reason or when risk_score >= [RISK_THRESHOLD] | Output contains | Run 15 scenarios with one dissenting agent citing policy; assert approval_required is true |
Risk Justification Quality | Risk justification references specific policy clause, agent position, or evidence source; no generic statements | Justification field contains phrases like 'to be safe' or 'better to check' without citing [POLICY_REFERENCE] or agent evidence | Parse justification field; regex-check for policy clause IDs or evidence line references |
Override Documentation Completeness | When override_decision differs from majority agent vote, override_reason field is non-empty and references specific evidence or policy | override_decision is true but override_reason is null, empty, or contains only generic language | Run 10 override scenarios; assert override_reason length > 50 chars and contains a policy or evidence reference |
Agent Position Attribution | Final output preserves each agent's position, confidence, and reasoning in the agent_positions array without omission | agent_positions array missing an agent from [AGENT_LIST] or truncating an agent's stated reason | Count agent_positions entries; assert count equals input agent count; assert each position.reason matches input |
Confidence Score Preservation | All agent confidence scores from input appear unmodified in output agent_positions | Confidence values are rounded, normalized, or altered from input values | Float comparison between input and output confidence values; assert exact match within 0.001 tolerance |
Output Schema Compliance | Output validates against [OUTPUT_SCHEMA] with all required fields present and correctly typed | JSON parse fails, required field missing, or field type mismatch against schema definition | Validate output with jsonschema against [OUTPUT_SCHEMA]; assert no validation errors |
Policy Alignment Traceability | approval_decision explicitly references the policy clause that triggered or permitted the decision | approval_decision present but policy_reference field is null or contains 'general policy' without clause ID | Parse policy_reference field; assert matches pattern [POLICY_CLAUSE_PATTERN] or is explicitly null when no policy triggered |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Adapt This Prompt
How to adapt
Start with the base prompt and a single model. Replace [AGENT_OUTPUTS] with a hardcoded JSON array of two sample agent positions. Remove the structured output schema requirement initially—just ask for a paragraph decision with a reason. Skip the eval harness and test manually with 5-10 conflict pairs you construct.
Watch for
- The model defaulting to 'escalate to human' for every disagreement instead of resolving low-risk conflicts
- Missing the distinction between 'agent A says approve, agent B says approve' (no conflict) and 'agent A says approve, agent B says escalate'
- Overly verbose justifications that bury the actual decision

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us