Cost-Limited Agent Exploration Prompt

This prompt is for agent developers and AI cost engineers who need to constrain an open-ended exploration task—such as codebase analysis, document search, or API discovery—within a strict cost budget. The job-to-be-done is producing an exploration plan that maximizes information gain per unit cost, with explicit early stopping criteria, before any tool calls execute. The ideal user is someone integrating an LLM agent into a production system where tool calls incur real financial costs (per-API-call pricing, token consumption, or metered service fees) and runaway exploration loops are unacceptable.

Use this prompt when the agent faces a large or unbounded search space and must decide which branches to pursue, in what order, and when to stop—all before spending. It is appropriate for tasks like 'find the root cause of this error in a 50-service codebase' or 'identify all documents mentioning this contract clause across a knowledge base.' Do not use this prompt for single-step lookups, deterministic retrieval where the correct tool call is already known, or tasks where the cost of planning exceeds the cost of execution. The prompt assumes the agent has access to tool descriptions with cost metadata (estimated tokens, latency, or monetary cost per call) and a declared total budget.

The prompt template requires several inputs: a task description, a list of available tools with cost estimates, a total budget cap, and a required output schema for the exploration plan. The plan must include a prioritized sequence of tool calls, per-call cost estimates, cumulative cost tracking, explicit stop conditions (e.g., 'stop when confidence exceeds 90%' or 'stop when three corroborating sources are found'), and a fallback strategy if the budget is exhausted before the task completes. Before deploying, validate that the generated plan respects the budget constraint, that stop conditions are measurable rather than vague, and that the plan does not propose tool calls that exceed the remaining budget. For high-stakes domains such as financial audit or clinical review, route the generated plan through a human approval step before execution begins.

Common failure modes include: the model proposing a plan that exceeds the budget on the first step, omitting stop conditions entirely, or optimizing for thoroughness rather than cost-efficiency. Test against edge cases where the budget is too small to complete the task (expect a clear 'cannot proceed' response with justification) and where multiple tools could answer the same question at different costs (expect the cheaper tool to be prioritized unless accuracy requires the expensive one). Wire this prompt into an application harness that parses the plan, validates it against the budget, and enforces stop conditions during execution—do not rely on the agent to self-limit at runtime without guardrails.

This template is the core instruction set you will send to a capable LLM (acting as your exploration agent) when you need it to investigate an open-ended problem domain without exceeding a predefined cost budget. The prompt forces the model to think in terms of cost-benefit analysis for each potential action, rather than simply executing a list of steps. It is designed for scenarios where the search space is too large for exhaustive exploration, such as codebase analysis, market research, or root-cause investigation, and where each tool call (API lookup, database query, web search) has a known, quantifiable cost.

codeCopy
You are an exploration agent operating under a strict cost budget. Your goal is to maximize information gain about [EXPLORATION_OBJECTIVE] while keeping total cost at or below [COST_BUDGET].

Available tools and their costs:
[TOOL_LIST_WITH_COSTS]

Initial context:
[INITIAL_CONTEXT]

Instructions:
1.  **Plan:** Before any action, output a concise exploration plan as a JSON object. The plan must include a list of steps, each with a 'tool_name', 'arguments', 'expected_information_gain' (rated High/Medium/Low), and 'estimated_cost'.
2.  **Budget Check:** Sum the 'estimated_cost' for all planned steps. If the total exceeds [COST_BUDGET], you must prune or replace steps, prioritizing those with the highest 'expected_information_gain' per unit cost. Explain your pruning rationale.
3.  **Execute:** Execute the first step in your plan. You will receive the tool's output.
4.  **Re-evaluate:** After each step, update your understanding of [EXPLORATION_OBJECTIVE] and the remaining budget. Decide if you should:
    *   **Continue:** Plan the next most cost-effective step.
    *   **Stop (Sufficient):** The objective is met. Summarize findings.
    *   **Stop (Budget):** The remaining budget is too low for any high-gain action. Summarize findings and note what was left unexplored.
5.  **Output Format:** Your final output must be a JSON object with the following schema:
    {
      "objective_met": boolean,
      "total_cost": number,
      "findings_summary": "string",
      "unexplored_areas": ["string"],
      "action_log": [
        {
          "step": number,
          "tool_name": "string",
          "cost": number,
          "information_gained": "string"
        }
      ]
    }

To adapt this template, you must replace the square-bracket placeholders with concrete values from your application. [EXPLORATION_OBJECTIVE] should be a clear, falsifiable question. [COST_BUDGET] is a numeric value in your chosen unit (e.g., USD, tokens, API credits). The [TOOL_LIST_WITH_COSTS] placeholder is the most critical; it must be a structured list, perhaps a JSON array of objects, each detailing the tool's name, description, input schema, and a fixed cost_per_call. The [INITIAL_CONTEXT] provides the agent with its starting knowledge. Before deploying, test the agent's behavior when the budget is too small to make any useful call—it should stop immediately and report an empty finding, not hallucinate a plan.

This prompt is designed to sit inside an agent's planning loop, not as a one-shot instruction. The application layer is responsible for enforcing the budget that the prompt describes. The prompt produces a plan; the harness must track actual spend against that plan, interrupt execution when the budget is exhausted, and decide whether to invoke a fallback, request human approval, or terminate. Treat the prompt's output as a structured intent that the harness validates and executes, not as a runtime guarantee.

Implement the harness as a state machine with three phases: planning, execution, and reconciliation. In the planning phase, call the model with the prompt template, parse the JSON output, and validate that total_estimated_cost does not exceed [MAX_BUDGET] and that each step's estimated_cost is non-negative. Reject plans with missing fields, negative costs, or dependency cycles. In the execution phase, iterate through the planned steps, calling the specified tools and tracking actual cost via a cost accumulator. Before each tool call, check accumulated_cost + step.estimated_cost <= [MAX_BUDGET]. If the check fails, halt execution, log a BUDGET_EXHAUSTED event, and route to the [ON_BUDGET_EXHAUSTED] handler. In the reconciliation phase, compare planned versus actual costs, log the delta, and feed the summary back into the agent's context for future planning improvements.

For model choice, prefer models with strong JSON mode and tool-use capabilities (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). Set response_format to json_schema where available, providing the exact output schema from the prompt template. Implement a retry wrapper: if parsing fails or validation errors occur, retry up to two times with the validation error message appended to the prompt as [PREVIOUS_ERROR]. After two failures, log the malformed response, increment a planning_failure metric, and either fall back to a conservative default plan or escalate to a human operator. Never silently proceed with an invalid plan.

Instrument the harness with structured logging at each state transition. Emit log events for plan_generated, plan_validated, step_started, step_completed, budget_threshold_warning (at 80% spend), budget_exhausted, and reconciliation_complete. Each event must include a trace_id, session_id, accumulated_cost, and remaining_budget. For production observability, export these events as OpenTelemetry spans so platform operators can query cost-per-session, planning accuracy, and early-stopping frequency. If the agent operates in a regulated domain, persist the full prompt, plan, execution trace, and reconciliation summary to an audit log before any destructive action.

The most common production failure is cost estimation drift: the model underestimates tool call costs because it lacks real-time pricing data. Mitigate this by maintaining a tool cost registry in the harness and overriding the model's estimated_cost with actual pricing before execution begins. A secondary failure mode is premature termination: the agent halts exploration before gathering sufficient information because the budget check is too conservative. Address this by implementing a soft budget threshold at 90% that triggers a [LOW_BUDGET_WARNING] prompt, asking the model to prioritize the single highest-value remaining step rather than aborting entirely. Test both failure modes with a golden dataset of exploration scenarios where the optimal stopping point is known, and measure whether the harness stops within 10% of that point.