Scope Boundary Negotiation Prompt Template

This prompt is designed for agent orchestrators and planning pre-processors that must establish a clear, explicit contract about what a given task or project will not address. Its primary job is to prevent the most common failure mode in autonomous systems: scope creep and over-execution. The ideal user is an AI/ML engineer or technical product manager building an agent that receives ambiguous, high-level objectives and must translate them into a safe, bounded execution plan before any tools are called or side effects are produced.

Use this prompt when the cost of doing the wrong thing is high—such as when an agent has access to production databases, customer communication channels, or financial systems. It is particularly valuable as a pre-flight check in a planning module, where the output boundary document serves as a contract that downstream execution loops and human reviewers can validate against. The prompt requires a clear [GOAL_STATEMENT] and, optionally, a set of [KNOWN_CONSTRAINTS] to operate effectively. It is not a goal-setting prompt; it assumes a goal already exists and focuses exclusively on defining its negative space.

Do not use this prompt for simple classification tasks, single-turn Q&A, or workflows where the operational domain is already fully constrained by a rigid UI or API schema. It is also inappropriate for creative brainstorming sessions where exploration is valued over boundary enforcement. If you need to clarify an ambiguous goal first, start with the 'Ambiguous Goal Refinement' prompt. If you need to extract implicit constraints from a user, use the 'Constraint Elicitation Interview' prompt. This prompt is the final gate before planning begins, ensuring that what is out of scope is as rigorously defined as what is in scope.

In production, wire the output of this prompt into a structured validation step. The boundary document should be parsed and checked for completeness: every in-scope item should have a corresponding out-of-scope counterpart, and any 'conditional' items must have explicit trigger conditions. If the validator finds ambiguous edge cases or missing categories, the system should re-prompt with specific gap questions rather than proceeding to task decomposition. For high-risk domains, always route the boundary document to a human reviewer before the agent begins execution.

This prompt template is designed for agent orchestrators and planning pre-processors that must define what is explicitly in scope, out of scope, and conditionally allowed before execution begins. It takes a goal statement, available tools, known constraints, and any existing ambiguity notes, and produces a structured boundary document. The output is intended to be machine-readable for downstream enforcement and human-reviewable for stakeholder alignment. Use this template when the cost of scope creep, over-execution, or unauthorized action is high. Do not use it for trivial single-step tasks where a boundary document adds latency without reducing risk.

textCopy
You are a scope boundary analyst for an autonomous agent system. Your job is to produce a precise, structured boundary document that defines what the agent is allowed to do, what it must not do, and what requires explicit confirmation before proceeding.

## INPUT
Goal: [GOAL_STATEMENT]
Available Tools: [TOOL_LIST]
Known Constraints: [CONSTRAINT_LIST]
Ambiguity Notes: [AMBIGUITY_NOTES]
Risk Level: [RISK_LEVEL]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "scope_boundary": {
    "in_scope": [
      {
        "item": "string (specific action or domain)",
        "rationale": "string (why this is in scope)",
        "tool_required": "string | null (tool name if applicable)",
        "constraints": ["string (applicable constraints from input)"]
      }
    ],
    "out_of_scope": [
      {
        "item": "string (specific action or domain explicitly excluded)",
        "rationale": "string (why this is excluded)",
        "risk_if_violated": "string (what breaks if this boundary is crossed)"
      }
    ],
    "conditional": [
      {
        "item": "string (action or domain that requires confirmation)",
        "condition": "string (what must be true or who must approve)",
        "default_behavior": "string (what happens if condition is not met)",
        "escalation_path": "string (who or what to ask)"
      }
    ],
    "boundary_creep_risks": [
      {
        "scenario": "string (how scope could expand unintentionally)",
        "detection_rule": "string (how to detect this creep during execution)",
        "mitigation": "string (what to do if detected)"
      }
    ],
    "ambiguous_edge_cases": [
      {
        "case": "string (the ambiguous situation)",
        "why_ambiguous": "string (why the boundary is unclear)",
        "recommended_disposition": "in_scope | out_of_scope | conditional",
        "confidence": "low | medium | high",
        "clarification_needed": "boolean"
      }
    ]
  },
  "metadata": {
    "goal_summary": "string (one-sentence restatement)",
    "total_in_scope_items": "number",
    "total_out_of_scope_items": "number",
    "total_conditional_items": "number",
    "unresolved_ambiguities": "number",
    "boundary_confidence": "low | medium | high",
    "recommended_review": "boolean"
  }
}

## CONSTRAINTS
- Every in-scope item must be traceable to the stated goal. If an action does not serve the goal, it is out of scope.
- Out-of-scope items must include a concrete risk description, not a generic warning.
- Conditional items must specify exactly who or what grants approval. Do not use vague terms like "check with someone."
- Boundary creep risks must be specific to this goal and tool set. Do not list generic risks like "the model might hallucinate."
- Ambiguous edge cases must include a recommended disposition. Do not leave them unresolved without flagging clarification_needed as true.
- If the risk level is "high," set recommended_review to true and flag all conditional items for human approval.
- If the goal statement contains unresolved pronouns or implicit references, flag them in ambiguous_edge_cases.
- Do not invent tools, constraints, or capabilities not present in the input.

## EXAMPLES
[EXAMPLES]

## OUTPUT
Return only the JSON object. No preamble, no commentary.

To adapt this template, replace the square-bracket placeholders with your runtime data. [GOAL_STATEMENT] should be the clarified goal from an upstream refinement step, not raw user input. [TOOL_LIST] should include tool names, descriptions, and argument schemas so the model can reason about capability boundaries. [CONSTRAINT_LIST] should capture security policies, data handling rules, cost limits, and operational boundaries already elicited. [AMBIGUITY_NOTES] should carry forward any unresolved questions from disambiguation steps. [RISK_LEVEL] should be one of low, medium, or high and should gate the recommended_review flag and conditional-item strictness. [EXAMPLES] should contain one or two few-shot examples of well-formed boundary documents for your domain. If you omit examples, the model may produce plausible but incorrectly structured output, especially for the boundary_creep_risks and ambiguous_edge_cases arrays.

After generating the boundary document, validate the JSON schema before accepting the output. Check that every in-scope item references a tool from the input tool list or explicitly states no tool is required. Verify that out-of-scope items do not appear in the in-scope or conditional arrays. Count unresolved ambiguities and compare against the metadata field. If recommended_review is true, route the boundary document to a human reviewer before the agent begins execution. For high-risk workflows, log the boundary document alongside the execution trace so post-hoc audits can confirm the agent did not cross declared boundaries.

The Scope Boundary Negotiation prompt is designed to sit at the front of an agent planning pipeline, immediately after goal clarification and before task decomposition. It takes a clarified goal, available tools, and known constraints as input and produces a structured boundary document. This document becomes the contract that downstream planning, execution, and monitoring modules enforce. The harness must treat the boundary output as a machine-readable artifact, not advisory text. Parse the JSON output, validate it against the expected schema, and store it as the active scope context for the remainder of the agent session.

Wire the prompt into your orchestrator as a synchronous pre-processing step. The input payload should include the clarified goal statement, a list of available tool capabilities with their action boundaries, any user-provided constraints, and a risk level indicator. After the model returns the boundary document, run a validation pass that checks: (1) the JSON parses without error, (2) every item in the in_scope and out_of_scope arrays has a non-empty rationale field, (3) conditional items include explicit trigger conditions and resolution criteria, and (4) no item appears in both in_scope and out_of_scope. If validation fails, retry once with the validation errors appended to the prompt as a [CORRECTION_FEEDBACK] block. If the second attempt also fails, escalate to a human reviewer with the original goal, the failed boundary document, and the specific validation errors highlighted. Log every boundary negotiation attempt, including the model version, input context, output, validation results, and escalation decision, for audit and prompt improvement cycles.

For high-risk domains such as healthcare, finance, or autonomous infrastructure, insert a mandatory human approval gate after successful validation. The boundary document should be surfaced in a review UI that highlights conditional items, out-of-scope declarations, and any items where the model's confidence was flagged as low. The reviewer must explicitly approve or modify the boundary before execution proceeds. Do not cache boundary documents across sessions unless the goal, tools, and constraints are identical. When the agent later encounters a replanning trigger, re-run the boundary negotiation prompt with the updated context rather than patching the original boundary document. This prevents boundary creep where incremental changes silently expand scope beyond the original intent.