Cost Threshold Approval Prompt for Agent Actions

This prompt is designed for a single, high-stakes job: preventing an autonomous agent from executing a tool call that would exceed a predefined cost budget. The ideal user is a FinOps engineer, a platform cost engineer, or an SRE embedding a financial safety harness directly into an agent's decision loop. It is not a general-purpose cost estimator or a replacement for cloud billing alerts. The prompt's sole function is to act as a synchronous approval gate, forcing the agent to calculate the projected cost of a proposed action, compare it against a hard budget cap, and either proceed with a structured justification or halt execution with a clear reason. It requires the agent to have access to a resource pricing table, the current cumulative spend, and the proposed tool's estimated duration or resource consumption.

Use this prompt when an agent has the autonomy to invoke tools that incur direct, variable costs—such as provisioning cloud resources, running large-scale data processing jobs, or calling third-party APIs with per-use fees. It is appropriate when the cost of a single action can be material and the budget is a hard constraint, not a soft guideline. The prompt is designed to be inserted as a pre-execution hook in an agent framework like LangChain or a custom orchestrator. It expects the agent to receive a structured [PROPOSED_ACTION] object, a [PRICING_TABLE] mapping resources to unit costs, and a [BUDGET_CONTEXT] that includes the total budget and current spend. The output is a strict JSON decision that downstream code can parse to allow or block the action. Do not use this prompt for actions with zero or negligible cost, or where the pricing model is too complex to be expressed in a simple table, as the model will likely produce a false sense of precision.

The primary constraint is that this prompt is a deterministic gate, not a negotiator. It must not be used in a conversational loop where the agent can argue for a budget increase. The prompt's instructions explicitly forbid the model from modifying the budget or pricing table. Failure modes to watch for include the model hallucinating pricing data if the [PRICING_TABLE] is incomplete, or incorrectly classifying a fixed-cost action as variable. To mitigate this, always validate the output JSON against a strict schema before the action is allowed to proceed. If the model's confidence is low or the cost calculation is ambiguous, the system should default to blocking the action and escalating to a human operator. The next step after implementing this prompt is to embed it within a retry-and-escalation harness that logs every decision, captures the full context for audit, and routes blocked actions to a human-in-the-loop review queue.

This template is designed to be inserted into an agent's tool-execution pipeline immediately before any action that incurs a direct cost. It forces the model to produce a structured cost estimate, compare it against a configured approval threshold, and recommend an action—either proceed, escalate for human approval, or block. The prompt is not a standalone chatbot instruction; it expects to receive structured context from the application layer, including resource pricing, current budget state, and the proposed action details.

textCopy
You are a cost enforcement agent. Before executing any billable action, you must produce a structured cost estimate and an approval decision.

## Input
- Proposed Action: [ACTION_DESCRIPTION]
- Action Parameters: [ACTION_PARAMETERS]
- Resource Pricing Table (resource: cost per unit): [RESOURCE_PRICING]
- Estimated Resource Consumption: [ESTIMATED_CONSUMPTION]
- Estimated Duration (seconds): [ESTIMATED_DURATION]
- Current Budget Period: [BUDGET_PERIOD]
- Total Budget for Period: [TOTAL_BUDGET]
- Budget Consumed So Far: [BUDGET_CONSUMED]
- Approval Threshold (absolute cost): [APPROVAL_THRESHOLD]
- Hard Cap (absolute cost): [HARD_CAP]
- Requester Identity: [REQUESTER_IDENTITY]
- Approval Queue: [APPROVAL_QUEUE]

## Task
1. Calculate the estimated total cost of the proposed action using the pricing table and estimated consumption.
2. Calculate the projected budget utilization percentage after the action completes.
3. Compare the estimated cost against the approval threshold and hard cap.
4. Generate a structured output following the schema below.

## Constraints
- If the estimated cost exceeds the hard cap, the decision must be BLOCK.
- If the estimated cost exceeds the approval threshold but not the hard cap, the decision must be ESCALATE.
- If the estimated cost is at or below the approval threshold, the decision may be PROCEED.
- Include a budget exhaustion warning if projected utilization exceeds 80%.
- All monetary values must be in [CURRENCY] with 4 decimal places.
- Do not invent pricing data; use only the provided Resource Pricing Table.

## Output Schema
{
  "decision": "PROCEED | ESCALATE | BLOCK",
  "estimated_cost": {
    "amount": number,
    "currency": "[CURRENCY]",
    "breakdown": [
      {"resource": string, "quantity": number, "unit_cost": number, "line_total": number}
    ]
  },
  "budget_impact": {
    "current_utilization_pct": number,
    "projected_utilization_pct": number,
    "budget_exhaustion_warning": boolean,
    "remaining_budget_after": number
  },
  "threshold_comparison": {
    "approval_threshold": number,
    "hard_cap": number,
    "within_approval_threshold": boolean,
    "within_hard_cap": boolean
  },
  "escalation_details": {
    "requester": "[REQUESTER_IDENTITY]",
    "queue": "[APPROVAL_QUEUE]",
    "reason": string,
    "expires_at": "ISO8601 timestamp or null"
  },
  "warnings": [string]
}

To adapt this template, replace each square-bracket placeholder with values injected by your application's cost-tracking and action-orchestration layer. The RESOURCE_PRICING table should be sourced from your cloud provider's pricing API or an internal rate card—never hardcoded. The ESTIMATED_CONSUMPTION and ESTIMATED_DURATION fields should come from a pre-flight estimation step, not from the agent's own guess. For high-stakes environments, always pair this prompt with a post-execution reconciliation step that compares the estimate against actual incurred cost and flags discrepancies above a tolerance threshold for human review.

The cost threshold approval prompt is not a standalone safety net—it must be embedded into the agent's tool execution loop as a mandatory pre-flight check for any action that incurs cost. Wire this prompt into your orchestration layer so that before an agent invokes a billable API, spins up a compute resource, or triggers a paid tool, the framework calls this prompt with the proposed action's cost estimate, current budget state, and approval threshold. The prompt returns a structured decision: APPROVE, ESCALATE, or BLOCK. Your harness must enforce that decision—an APPROVE allows execution, an ESCALATE routes to a human review queue with the full justification payload, and a BLOCK prevents execution and logs the reason. Never allow the agent to bypass this gate through prompt injection or tool-call chaining; the approval check must be a hard-coded step in the orchestration framework, not a suggestion in the system prompt.

Implement the harness with these concrete components: 1) Cost Estimator—before calling the approval prompt, compute the projected cost using resource pricing tables, estimated duration, and any per-call fees. Pass these as structured fields in [COST_ESTIMATE]. 2) Budget Tracker—maintain a real-time cumulative spend counter and remaining budget. Feed [CURRENT_BUDGET_STATE] with total_budget, spent_to_date, remaining, and burn_rate. 3) Threshold Config—store approval thresholds per action category (e.g., actions under $10 auto-approve, $10–$500 require escalation, over $500 auto-block). Pass these as [APPROVAL_THRESHOLDS]. 4) Validation Layer—after the prompt returns, validate the JSON structure against a schema that requires decision, reasoning, risk_flags, and recommended_action. If validation fails, retry once with the error message; if it fails again, default to ESCALATE with a validation_failure flag. 5) Audit Log—write every approval decision, including the full prompt input, model response, validator result, and final harness action, to an append-only log with timestamps and actor identity. This is non-negotiable for FinOps governance.

Choose your model and retry strategy carefully. For cost decisions, prefer a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to minimize variance in threshold comparisons. Implement a circuit breaker: if the approval prompt fails three consecutive times, block all cost-incurring actions and alert the platform team. For high-throughput systems, cache approval decisions for identical action-cost-budget tuples with a short TTL (e.g., 60 seconds) to avoid redundant LLM calls. When the budget tracker shows less than 10% remaining, automatically tighten thresholds—actions that previously auto-approved should escalate. Wire budget exhaustion as a hard stop: when remaining <= 0, the harness must block all billable actions regardless of the prompt's output. The prompt advises; the harness enforces.

Human review integration is the most critical handoff. When the prompt returns ESCALATE, your harness must: (a) push a structured ticket to the designated review queue (PagerDuty, Jira, Slack workflow) containing the full approval request, cost breakdown, and risk flags; (b) start a timeout timer based on the action's urgency; (c) if no human responds before timeout, apply the configured default (typically BLOCK for high-cost actions, APPROVE for low-cost with warnings); (d) on human decision, log the reviewer identity, decision, and any overrides. Never allow the agent to proceed while awaiting human review—the orchestration layer must suspend the agent's execution context and resume only after receiving an explicit approval signal. Test this path regularly with synthetic escalations to ensure the review pipeline doesn't silently degrade.

Common failure modes to instrument for: the prompt hallucinates budget numbers instead of using the provided [CURRENT_BUDGET_STATE] (validate that response figures match input); the model approves an action that exceeds the threshold due to arithmetic errors (add a post-prompt numeric comparison check in the harness); the agent accumulates many small sub-threshold actions that collectively exhaust the budget (implement a rolling window spend check that escalates when short-term burn rate spikes); and the human review queue becomes a bottleneck during incident response (pre-define emergency break-glass roles that can override blocks with mandatory post-action review). Monitor these with dashboards tracking approval rates, escalation rates, budget consumption velocity, and human review latency. The prompt is the decision engine; the harness is the safety envelope.