Model Capability Boundary Prompt Template

This prompt is designed for teams building autonomous or semi-autonomous agent systems that need to evaluate whether a proposed goal is achievable given the actual capabilities of the underlying model. It sits in the planning pre-processor stage, after goal clarification but before task decomposition. The prompt forces the model to produce a structured capability assessment that maps each goal requirement to a known model strength, limitation, or gap. This prevents the most expensive class of agent failure: confidently executing a plan the model cannot actually complete.

Use this prompt when you need a gate between goal definition and plan generation. It is most valuable when the goal is complex, the cost of failure is high (e.g., customer-facing actions, data mutation, financial operations), or the model's capabilities on the specific task type are not well-characterized. The ideal user is an AI engineer or product developer wiring a planning module into an agent harness. Required context includes a clarified goal statement, a list of available tools, and the model's known capability profile or system card. The output is a structured JSON assessment that downstream orchestration code can parse to either proceed with planning, request human review, or downgrade the goal scope.

Skip this prompt when the goal is trivial, the model capabilities are already well-characterized for the task type, or when you are running a fast, cost-sensitive pipeline where capability mismatches will be caught downstream by execution failures. Do not use this prompt as a substitute for actual tool availability checks or runtime error handling; it assesses the model's intrinsic reasoning and generation limits, not whether an external API is currently reachable. For high-risk domains, always pair the capability assessment output with a human review step before allowing autonomous execution to proceed.

This prompt template forces a structured capability assessment before any agent commits to a plan. It maps each goal requirement against known model strengths and limitations, producing a go/no-go signal with explicit gap documentation. Use it when the cost of overestimation is high—long-running agent loops, hallucinated tool calls, or confident but incorrect outputs that corrupt downstream state.

textCopy
You are a capability assessment pre-processor. Your job is to evaluate whether the stated goal is achievable given the model's known capabilities, available tools, and constraints. Do not plan execution. Do not attempt the goal. Only assess feasibility.

## GOAL
[GOAL_DESCRIPTION]

## MODEL CONTEXT
- Model family: [MODEL_FAMILY]
- Known strengths: [KNOWN_STRENGTHS]
- Known limitations: [KNOWN_LIMITATIONS]
- Available tools: [AVAILABLE_TOOLS]
- Tool capabilities: [TOOL_CAPABILITIES]
- Tool limitations: [TOOL_LIMITATIONS]

## CONSTRAINTS
- Latency budget: [LATENCY_BUDGET]
- Token budget: [TOKEN_BUDGET]
- Accuracy requirement: [ACCURACY_REQUIREMENT]
- Hallucination tolerance: [HALLUCINATION_TOLERANCE]
- Data sensitivity level: [DATA_SENSITIVITY]
- Required output format: [OUTPUT_FORMAT]
- Human review available: [HUMAN_REVIEW_AVAILABLE]

## ASSESSMENT INSTRUCTIONS
1. Decompose the goal into capability requirements.
2. For each requirement, determine if the model can reliably meet it given the context above.
3. Classify each requirement as: WITHIN_CAPABILITY, AT_BOUNDARY, or BEYOND_CAPABILITY.
4. For AT_BOUNDARY items, specify the conditions under which they might succeed or fail.
5. For BEYOND_CAPABILITY items, identify the specific gap and whether a workaround exists.
6. Produce an overall feasibility rating: FEASIBLE, RISKY, or INFEASIBLE.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "overall_feasibility": "FEASIBLE|RISKY|INFEASIBLE",
  "confidence": 0.0-1.0,
  "requirement_assessments": [
    {
      "requirement": "string",
      "classification": "WITHIN_CAPABILITY|AT_BOUNDARY|BEYOND_CAPABILITY",
      "rationale": "string",
      "failure_modes": ["string"],
      "workaround": "string or null"
    }
  ],
  "critical_gaps": ["string"],
  "risk_factors": ["string"],
  "recommendation": "PROCEED|PROCEED_WITH_CAUTION|DO_NOT_PROCEED|REQUEST_CLARIFICATION",
  "clarification_needed": ["string"]
}

## RULES
- Do not hallucinate capabilities the model does not have.
- If a requirement depends on tool behavior you cannot verify, flag it as AT_BOUNDARY.
- If accuracy requirements exceed what the model can reliably deliver, classify as BEYOND_CAPABILITY.
- If hallucination tolerance is zero for factual claims, flag any requirement involving factual recall as BEYOND_CAPABILITY unless grounded retrieval is available.
- Be specific about failure modes. Vague warnings are not useful.

Adaptation guidance: Replace each square-bracket placeholder with concrete values from your system context. The [KNOWN_STRENGTHS] and [KNOWN_LIMITATIONS] fields should come from your model's documented behavior, not assumptions. If you lack data for a field, mark it explicitly as UNKNOWN rather than guessing—the prompt will flag unknown capability boundaries as risk factors. For production use, wire the output recommendation field into your agent's gating logic so that DO_NOT_PROCEED or REQUEST_CLARIFICATION blocks execution before planning begins.

Validation and evals: Before shipping, test this prompt against goals you know are beyond your model's capabilities and confirm it returns INFEASIBLE or RISKY with specific gap documentation. Test against goals well within capability and confirm FEASIBLE with high confidence. The most dangerous failure mode is a false FEASIBLE rating—build an eval set of capability-stretching goals and measure false-positive rate. If this prompt feeds autonomous execution, require human review for any RISKY rating before the agent proceeds.

This prompt is designed to sit at the entry point of an agent planning pipeline, acting as a pre-flight check before any task decomposition or tool selection occurs. It should be invoked immediately after a goal has been clarified and constraints have been elicited, but before the planner commits to a multi-step execution strategy. The primary job of the harness is to prevent the system from confidently generating a plan that relies on capabilities the model does not possess, such as perfect factual recall, real-time data access without a tool, or deterministic reasoning over ambiguous inputs.

To wire this into an application, wrap the prompt in a function that accepts a structured [GOAL_SPECIFICATION] object containing the clarified goal, explicit constraints, and success criteria. The model should be forced to return a strict JSON schema with an array of capability assessments, each containing a requirement, model_capability, gap_risk (low/medium/high), and mitigation field. Implement a post-processing validator that checks for missing high-risk gaps. If any gap_risk is high and the mitigation field is empty or proposes a hallucination-prone workaround, the harness must block the planning phase and escalate for human review. For medium-risk gaps, automatically inject the suggested mitigation as a constraint into the downstream planning prompt. Log the full capability assessment as a structured artifact for auditability.

For model choice, use a reasoning-capable model (such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro) rather than a lightweight instruct model, as this task requires honest self-assessment of limitations. Set temperature to 0 to minimize variance in risk classification. Implement a single retry on parse failure with a stricter schema reminder, but do not retry on high-risk gap detection—escalate immediately. The most common production failure mode is the model under-reporting its own limitations to appear helpful, so pair this prompt with an eval that compares the generated capability assessment against a known limitation checklist for your specific model version. If the eval detects a missed known limitation, flag the entire planning cycle for human review before execution begins.