Cost-Incurring Action Approval Prompt for FinOps Agents

This prompt is designed for cloud and SaaS cost management teams building AI agents that can initiate cost-incurring actions. Use it when your FinOps agent identifies an optimization opportunity that requires spending money, such as purchasing a Savings Plan, upgrading a reservation tier, or provisioning a paid service. The prompt forces the agent to produce a structured approval request with estimated cost, billing impact, resource type, commitment duration, and budget threshold comparison before any action executes. This is not a prompt for general cost reporting or anomaly detection. It is specifically for the approval gate that sits between a recommendation and a spend action. The output is meant to be routed to a human reviewer or an approval workflow system, not executed automatically.

The ideal user is a platform engineer or FinOps practitioner embedding an AI agent into a cloud cost management pipeline. Required context includes the specific cost recommendation, the target account or project ID, the current budget threshold, and the proposed action's parameters. You should not use this prompt for read-only cost analysis, anomaly alerts, or actions that do not immediately incur new charges. A common failure mode is applying this prompt to a savings recommendation (like turning off idle instances) that reduces cost, which requires a different, lower-risk approval path. Another anti-pattern is using this prompt without a downstream system that can enforce the block—if the agent can still execute the action regardless of the approval output, the prompt provides a false sense of security.

Before implementing, ensure you have a human review queue or webhook receiver ready to consume the structured JSON output. The prompt's value is in standardizing the approval payload so that routing rules, budget checks, and audit logs can operate on a predictable schema. Avoid modifying the prompt to include automatic approval logic for low-cost items unless you have a separate, tested threshold policy. The next step is to copy the prompt template and wire it into your agent's decision loop, ensuring that the agent cannot proceed to the execution step without a valid status: approved response from the review system.

This prompt template is designed to be integrated into a FinOps agent's decision loop. Before the agent executes any action that would create a new cost, change a reservation tier, or modify a billable resource, it should use this prompt to generate a human-readable approval request. The template forces the model to act as a meticulous financial gatekeeper, comparing the proposed action against the available budget data and surfacing all relevant fiscal implications. The output is a structured payload that can be sent to a human approval queue, a Slack channel, or a ticketing system.

textCopy
You are a FinOps gatekeeper agent. Your purpose is to generate a structured, data-backed approval request before any cost-incurring action is taken. You must not approve or deny the request; you only prepare the approval package for a human.

Analyze the proposed action against the provided context and generate an approval request using the [OUTPUT_SCHEMA] below.

[ACTION_DESCRIPTION]: The specific technical action being proposed (e.g., 'Provision a new m5.2xlarge EC2 instance', 'Purchase a 1-year committed use discount for BigQuery').
[ESTIMATED_COST]: A detailed breakdown of the estimated cost, including unit price, quantity, and time period (e.g., '$0.384 per hour * 730 hours = $280.32/month').
[RESOURCE_TYPE]: The category of the resource (e.g., 'Compute', 'Database', 'SaaS License', 'Support Plan').
[COMMITMENT_DURATION]: The billing commitment term, if any (e.g., 'On-Demand', '1 Year Reserved', 'Monthly Subscription').
[BUDGET_CONTEXT]: The relevant budget data, including the current monthly/quarterly budget, the amount already spent, and the forecasted spend without this action.
[RISK_LEVEL]: A preliminary risk classification based on cost and budget impact (e.g., 'Low', 'Medium', 'High').

[OUTPUT_SCHEMA]:
{
  "approval_request_id": "[A unique ID for this request]",
  "summary": "[A one-sentence summary of the action and its total estimated monthly impact, e.g., 'Request to provision a new m5.2xlarge instance for the Dev environment at an estimated cost of $280/month.']",
  "action_details": {
    "technical_description": "[ACTION_DESCRIPTION]",
    "resource_type": "[RESOURCE_TYPE]",
    "commitment_duration": "[COMMITMENT_DURATION]"
  },
  "cost_analysis": {
    "estimated_monthly_impact": "[The total estimated cost per month as a float]",
    "cost_breakdown": "[ESTIMATED_COST]",
    "budget_comparison": {
      "current_budget": "[The total budget for the period as a float]",
      "spent_to_date": "[The amount already spent in the period as a float]",
      "forecasted_spend_without_action": "[The forecasted total spend for the period without this action as a float]",
      "forecasted_spend_with_action": "[The new forecasted total spend if this action is approved as a float]",
      "budget_remaining_after_action": "[The amount of budget remaining after the action as a float]",
      "budget_overrun_risk": "[A boolean: true if forecasted_spend_with_action exceeds current_budget, otherwise false]"
    }
  },
  "risk_assessment": {
    "risk_level": "[RISK_LEVEL]",
    "risk_rationale": "[A brief explanation of the risk level, mentioning budget overrun risk or spending velocity.]"
  },
  "human_approval_prompt": "[A clear, concise question for the human approver, e.g., 'Approve the provisioning of this m5.2xlarge instance for $280/month?']"
}

[CONSTRAINTS]:
- If [ESTIMATED_COST] is missing or cannot be determined, set the `risk_level` to 'Critical' and the `human_approval_prompt` to 'ACTION BLOCKED: Cost estimate unavailable. Manual review required.'
- If `budget_overrun_risk` is true, the `risk_level` must be at least 'High'.
- All monetary values must be in USD and formatted as floats with two decimal places.
- Do not invent any data. If a field from [BUDGET_CONTEXT] is missing, use `null` for that field in the JSON output.

To adapt this template, replace the square-bracket placeholders with data fetched from your FinOps platform (e.g., CloudHealth, Vantage), cloud provider APIs (AWS Cost Explorer, Azure Cost Management), and your internal budget tracking system. The [OUTPUT_SCHEMA] is designed to be parsed by an orchestration layer. If the budget_overrun_risk field is true or the risk_level is High or Critical, your application logic should automatically route the approval request to a senior approver or block the action entirely until a human explicitly acknowledges the risk. Always log the full JSON payload as an audit record before presenting the human_approval_prompt to the reviewer.

This prompt is not a standalone chat interaction; it is a decision gate inside an automated FinOps agent. The agent should invoke this prompt template before executing any action that would create, modify, or commit to a paid resource. The prompt's output is a structured approval request that must be routed to a human reviewer or an upstream policy engine. The implementation harness must enforce that the agent cannot proceed to the execution step until it receives an explicit approved signal with a valid approval token.

Wire the prompt into a pre-execution hook in the agent's tool-calling loop. When the agent selects a tool classified as cost_incurring, the harness should: (1) pause the agent's execution, (2) populate the prompt template with the tool's proposed parameters, current budget state, and resource context, (3) call the LLM to generate the structured approval payload, (4) validate the output against the expected schema (requiring non-null fields for estimated_cost, budget_threshold_comparison, and commitment_duration), and (5) post the validated payload to a review queue (e.g., Slack, Jira, PagerDuty, or a custom approval API). The agent's state machine must remain blocked until the review queue returns an approved or rejected decision. Log every approval request, the raw LLM output, validation errors, and the final human decision for auditability.

For model choice, use a model with strong structured output and instruction-following capabilities (e.g., Claude 3.5 Sonnet or GPT-4o) and enforce the output schema using the model's native JSON mode or a tool-calling definition. Implement a retry policy: if the initial output fails schema validation, retry once with the validation error message injected into the prompt's [CONSTRAINTS] field. If the second attempt also fails, escalate to a human operator with the raw output and validation errors rather than guessing. Never allow the agent to proceed with a cost-incurring action if the approval payload is malformed or missing required fields. The most common production failure mode is an LLM generating a persuasive but incomplete approval request that omits the budget_overrun_risk flag; your validation layer must catch this before it reaches a human reviewer.