Budget-Conscious Agent Planning Prompt

Use this prompt when you have a complex task that an agent must decompose into multiple tool calls, and you need a hard resource budget enforced at planning time rather than at runtime. The ideal user is an agent developer or AI cost engineer who has a known tool catalog with declared per-call costs and a task description that can be broken into discrete, sequential steps. The prompt produces a validated step plan with per-step cost estimates, a total that demonstrably stays within the declared cap, and explicit trade-off decisions when the ideal plan would exceed the budget. This is a planning-time guardrail, not a runtime budget enforcer. It prevents the agent from designing a plan it cannot afford to execute, which is the most common failure mode in cost-unaware agent loops.

This prompt is not appropriate for simple single-tool lookups, tasks where tool costs are unknown or highly variable, or workflows where the agent must dynamically replan based on intermediate results. If your tool costs depend on payload size, result cardinality, or server-side pricing that the model cannot predict, a planning-time budget will be misleading. In those cases, use a runtime spend cap enforcement prompt instead. Similarly, if the task requires open-ended exploration where the number of steps cannot be estimated upfront, a cost-limited exploration prompt with early stopping criteria is a better fit. Do not use this prompt when the agent's tool catalog changes between planning and execution, as stale cost data will invalidate the budget constraint.

Before deploying this prompt, you must have a tool catalog with declared costs that the model can reference. Costs should include token estimates for tool input and output, any per-call fees, and expected latency if that factors into your budget model. The prompt assumes costs are additive and independent. If tool costs interact—for example, a cache hit on one tool reduces the cost of a subsequent call—you need to model that in the cost declarations or accept that the plan will be conservative. Validate the output plan by summing the declared per-step costs and confirming the total does not exceed the cap. For high-stakes workflows where budget overruns carry financial or compliance risk, add a human approval gate before the agent begins execution. The next section provides the copy-ready prompt template you can adapt to your tool catalog and budget model.

This prompt template is designed to be placed in the system instructions of an agent before it begins planning a complex task. It forces the model to treat a resource budget as a first-class constraint, producing a step-by-step plan where each step carries an estimated cost and the total stays within the declared cap. Use this when your agent has access to tools with known or estimable costs (API calls, token-intensive operations, human review loops) and you need to prevent runaway spend before execution starts.

textCopy
You are a budget-conscious planning agent. Your job is to decompose a given task into a sequence of discrete steps, each with an estimated resource cost, such that the total estimated cost does not exceed a declared budget.

## INPUTS
- Task: [TASK_DESCRIPTION]
- Available Tools: [TOOL_LIST_WITH_COST_MODELS]
- Total Budget: [BUDGET_LIMIT] (expressed in [COST_UNIT], e.g., USD, tokens, API calls)
- Constraints: [CONSTRAINTS] (e.g., latency limits, required approvals, data residency)

## PLANNING RULES
1. Decompose the task into the smallest reasonable steps. Each step must map to one or more tool calls or internal reasoning actions.
2. For each step, estimate the cost using the provided tool cost models. If a step's cost is variable, provide a range and explain the variance.
3. The sum of all step cost estimates must not exceed [BUDGET_LIMIT].
4. If the task cannot be completed within the budget, produce a partial plan that maximizes progress and explicitly list what is deferred or dropped.
5. Identify at least one trade-off: a step where spending more would improve quality, or where spending less would increase risk.
6. Flag any step that requires human approval before execution.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "plan_id": "string",
  "total_estimated_cost": number,
  "budget_limit": number,
  "cost_unit": "string",
  "steps": [
    {
      "step_number": number,
      "description": "string",
      "tool_calls_required": ["tool_name"],
      "estimated_cost": number,
      "cost_rationale": "string",
      "requires_approval": boolean,
      "depends_on": [number]
    }
  ],
  "trade_offs": [
    {
      "step_number": number,
      "description": "string",
      "alternative": "string",
      "cost_difference": number,
      "quality_impact": "string"
    }
  ],
  "deferred_or_dropped": ["string"],
  "risk_notes": ["string"]
}

## VALIDATION
Before returning the plan, verify:
- The sum of all step estimated_cost values equals total_estimated_cost.
- total_estimated_cost <= budget_limit.
- All depends_on references point to valid step numbers.
- No step with requires_approval: true executes a high-risk action without a human gate.

To adapt this template, replace the square-bracket placeholders with your specific values. [TASK_DESCRIPTION] should be a clear, bounded objective. [TOOL_LIST_WITH_COST_MODELS] must include the actual tool names and their cost functions—for example, search_api: $0.002 per call or gpt-4o: $0.005 per 1K output tokens. If you lack precise cost models, use conservative upper-bound estimates and note the uncertainty. [BUDGET_LIMIT] and [COST_UNIT] should align with how your platform tracks spend. [CONSTRAINTS] can include latency budgets, required review gates, or data handling rules that affect step feasibility. After pasting, test the prompt with a known task and verify that the output JSON parses correctly and that the cost arithmetic is accurate. For high-stakes production use, add a post-generation validation step in your harness that independently sums the step costs and rejects plans that exceed the budget.

This prompt is designed to sit at the planning layer of an agent loop, invoked before any tool calls are executed. The application should call this prompt after receiving a user task but before the agent enters its execution phase. The prompt expects a declared resource budget—typically a combination of estimated tool call cost, token budget, and latency ceiling—and produces a step plan with per-step cost estimates. The harness must validate that the returned plan is structurally complete, that the sum of per-step estimates does not exceed the declared cap, and that every step references a tool that actually exists in the agent's current tool registry.

Validation and enforcement: Parse the model's JSON output and run a schema check that verifies the presence of steps (array), total_estimated_cost, budget_cap, and trade_offs (array of strings). Compute the sum of all estimated_cost fields across steps and compare against budget_cap. If the sum exceeds the cap, reject the plan and re-prompt with the violation details injected into [CONSTRAINTS]. If any step references a tool name not present in the agent's tool registry, reject and re-prompt with the available tool list. Retry logic: Allow up to two retries for budget violations or missing-tool references. After two failures, fall back to a hardcoded sequential plan that uses the cheapest available tool for each step, and log a plan_generation_fallback event. Model choice: Use a model with strong JSON-following behavior and low latency for this planning step—GPT-4o or Claude 3.5 Sonnet are reasonable defaults. Avoid small or instruction-light models that may drop fields or hallucinate tool names.

Logging and observability: Log every plan generation attempt with the model name, input budget, output plan, validation result, and any retry count. Attach a plan_id UUID to each accepted plan so downstream execution steps can be traced back to the planning decision. If the plan is rejected after all retries and the fallback is used, emit a structured log event with severity warning and include the original budget, the violation reason, and the fallback plan. Budget enforcement during execution: The agent execution loop must track cumulative tool call cost against the plan's per-step estimates. If actual cost exceeds a step's estimate by more than 20%, pause execution and re-invoke this planning prompt with the remaining budget and completed steps as [CONTEXT]. This prevents a single expensive tool call from silently consuming the remainder of the budget. Human approval gate: If the total estimated cost exceeds a configurable threshold (e.g., $2.00 or 50 tool calls), route the plan to a human reviewer before execution begins. The review interface should display the plan, per-step costs, and the remaining budget after each step. Do not skip this gate in production systems where tool costs are real and unbounded loops are possible.