Budget-Aware Human Approval Trigger Prompt

This prompt is a governance control for compliance engineers and platform operators who need to insert a mandatory human approval step into an agent's execution loop. The primary job-to-be-done is preventing autonomous overspend in regulated or high-stakes environments. You should use this prompt when an agent is about to make a tool call that would exceed a predefined cost budget, consume a scarce rate-limit quota, or breach a cumulative spend threshold. The ideal user is someone responsible for platform safety, auditability, and financial controls—not a developer doing casual cost optimization. Required context includes the agent's current task, the specific tool call it intends to make, the estimated cost of that call, the remaining budget, and the consequence of both approval and denial.

Do not use this prompt for trivial cost-saving nudges or general budget awareness. It is specifically designed for moments where the consequence of denial must be explicitly documented and the decision requires a human's judgment. For example, in a financial audit workflow, an agent might need to call an expensive external data enrichment API that would consume 80% of the remaining monthly budget. The prompt forces the agent to pause, produce a structured approval request detailing the cost, remaining budget, and what happens if denied, and then wait. This is distinct from a cost-optimization prompt that might suggest a cheaper alternative; here, the agent must not proceed without a documented human decision.

Before implementing this prompt, ensure you have defined the cost and rate-limit metadata that the agent can access. The prompt is only as effective as the data it can surface. If your agent cannot reliably estimate the cost of a tool call or query its remaining budget, this prompt will produce vague or incorrect approval requests. Wire this into your agent's tool-calling middleware so that it intercepts function calls before execution, evaluates them against a budget policy, and injects this prompt when a threshold is crossed. The next step is to pair this with a structured logging system that records every approval request, the human decision, and the resulting action to create a complete audit trail.

This prompt acts as a pre-tool-call guard. It evaluates the next planned action against the current budget state and rate limit counters, then decides whether to proceed, block, or escalate for human approval. Wire it into your agent's tool router so it runs before every tool invocation. The prompt is designed to produce a structured decision object that your application harness can parse and enforce.

textCopy
You are a budget-aware approval guard for an AI agent. Your job is to evaluate the next proposed tool call against the current resource budget and rate limit state, then output a structured decision.

## CURRENT STATE
- Remaining budget: [REMAINING_BUDGET]
- Budget cap: [BUDGET_CAP]
- Estimated cost of proposed call: [ESTIMATED_COST]
- Rate limit window remaining calls: [RATE_LIMIT_REMAINING]
- Rate limit window resets at: [RATE_LIMIT_RESET_TIME]
- Consecutive same-tool calls: [CONSECUTIVE_SAME_TOOL_COUNT]
- Consecutive same-tool cap: [CONSECUTIVE_SAME_TOOL_CAP]

## PROPOSED TOOL CALL
- Tool name: [TOOL_NAME]
- Arguments: [TOOL_ARGUMENTS]
- Justification from agent: [AGENT_JUSTIFICATION]

## DECISION RULES
1. If estimated cost > remaining budget, output decision "BLOCK" with reason "BUDGET_EXCEEDED".
2. If rate limit remaining == 0 and reset time is in the future, output decision "BLOCK" with reason "RATE_LIMITED".
3. If consecutive same-tool calls >= cap, output decision "BLOCK" with reason "LOOP_RISK".
4. If estimated cost > [HIGH_COST_THRESHOLD] and remaining budget < [LOW_BUDGET_THRESHOLD], output decision "ESCALATE" with reason "HIGH_COST_NEAR_CAP".
5. If the tool is in the high-risk list [HIGH_RISK_TOOLS] and estimated cost > 0, output decision "ESCALATE" with reason "HIGH_RISK_TOOL".
6. Otherwise, output decision "PROCEED".

## OUTPUT SCHEMA
Return ONLY valid JSON with this exact structure:
{
  "decision": "PROCEED" | "BLOCK" | "ESCALATE",
  "reason": string,
  "approval_request": {
    "summary": string,
    "tool_name": string,
    "estimated_cost": number,
    "remaining_budget_after": number,
    "consequence_of_denial": string,
    "budget_percentage_consumed": number
  } | null
}

## CONSTRAINTS
- Do not invent budget numbers. Use only the provided state.
- If decision is "PROCEED", set approval_request to null.
- If decision is "ESCALATE", populate all approval_request fields.
- consequence_of_denial must describe what the agent cannot do if this call is rejected.
- budget_percentage_consumed must be calculated as ((budget_cap - remaining_budget + estimated_cost) / budget_cap) * 100.

Adaptation notes: Replace the square-bracket placeholders with live data from your budget tracker and tool router before each invocation. The HIGH_RISK_TOOLS list should contain tool names that always require human approval, such as send_email, create_payment, or delete_record. Adjust the HIGH_COST_THRESHOLD and LOW_BUDGET_THRESHOLD to match your organization's risk tolerance. For production use, add a [TRACE_ID] placeholder and log every decision with the trace ID for auditability. If your agent runs in a regulated domain, extend the output schema to include a reviewer_instructions field that tells the human approver what evidence to check before approving.

This prompt is a guard function, not a conversational step. It should be invoked programmatically by your agent runtime before a tool call is executed, whenever the cumulative or per-call cost exceeds a configured threshold. The prompt receives structured context about the proposed action, remaining budget, and rate limit state, then returns a structured decision: APPROVE, ESCALATE, or DENY. The calling system must respect this decision and halt execution on DENY or ESCALATE until a human reviewer acts. Do not embed this prompt inside a general chat loop; it belongs in a dedicated validation step within your agent's tool execution pipeline.

Wire the prompt into your agent's pre-tool-call hook. When the agent selects a tool and computes its estimated cost (via your internal cost model or the tool's documented pricing), compare the estimated cost against the remaining session budget and any per-call cap. If the estimate exceeds a threshold—say 20% of remaining budget or a hard per-call dollar limit—construct the prompt payload with the fields [TOOL_NAME], [ESTIMATED_COST], [REMAINING_BUDGET], [RATE_LIMIT_STATE], [TASK_CONTEXT], and [CONSEQUENCE_OF_DENIAL]. Send this to the model with response_format set to a strict JSON schema containing decision, reasoning, approval_request_summary, and escalation_priority. Validate the response before acting: if the JSON is malformed or missing required fields, default to ESCALATE and log the failure. Never proceed with the tool call on a parse failure—this is a safety-critical boundary.

Build retry and fallback logic around the prompt invocation itself. If the model call fails or times out, retry once with the same payload. If the second attempt fails, escalate to a human reviewer with a pre-formatted message containing the tool name, estimated cost, and remaining budget. Log every invocation—including the prompt payload, model response, and final decision—to your audit trail. This log is essential for compliance review, cost attribution, and debugging false escalations. For high-throughput systems, consider caching approval decisions for identical (tool, cost, budget) tuples within a short time window to reduce latency and model costs, but invalidate the cache if the budget or rate limit state changes.

Choose your model based on the risk profile of the domain. For financial compliance or healthcare workflows, use a model with strong instruction-following and low hallucination rates on structured tasks—GPT-4o or Claude 3.5 Sonnet are reasonable defaults. Avoid smaller or older models that may produce inconsistent JSON under pressure. Set temperature=0 to maximize determinism. If your system processes high volumes of low-risk approvals, you can route to a faster, cheaper model for the initial screening and escalate to a stronger model only on borderline cases. Test this routing with a golden dataset of 50–100 scenarios covering near-budget-exhaustion, rate-limit-imminent, and normal-operation cases. Measure false-positive escalations (unnecessary human interruptions) and false-negative approvals (approvals that should have been escalated). Tune your thresholds until both rates are acceptable for your operational context.

After deploying, monitor three key signals: escalation rate (what fraction of tool calls trigger this guard), human override rate (how often reviewers reverse the model's decision), and time-to-resolution for escalated items. A sudden spike in escalation rate may indicate a budget miscalibration or a tool whose cost model is wrong. A high override rate suggests the prompt's thresholds or reasoning need adjustment. If time-to-resolution grows, your human review queue may be understaffed, creating a bottleneck that defeats the purpose of autonomous agents. Wire these metrics into your existing observability stack and set alerts for anomalous patterns. Remember: this prompt is a safety net, not a substitute for sound budget architecture. If you find yourself escalating more than 5–10% of tool calls, revisit your upstream budget allocation and tool selection logic rather than tuning the guard prompt endlessly.