constrained-prompting-guide

---

title: "Constrained Prompting: How to Keep AI on Topic and on Format" description: "Learn constrained prompting techniques to force AI models to stay on topic, follow strict output formats, and avoid unwanted content with practical examples and prompt patterns." date: 2026-07-15 tags: ["constrained prompting", "prompt engineering", "techniques", "advanced"]

If you've ever watched a language model wander off-topic, add unwanted commentary, invent facts, or blow past a format you carefully specified, you've run into the core problem that constrained prompting solves. It's one of the most practical skills in prompt engineering — and one of the least discussed. Most guides talk about what to put in a prompt. This guide is about how to build walls around the model's behavior so it stays exactly where you want it.

Constrained prompting is the practice of designing prompts that restrict what a model can talk about, how it formats its output, and what it's allowed to do at each step. It's not about being a harsh prompt writer — it's about engineering boundaries that make output predictable. When you constrain a model well, you spend less time editing, less time re-rolling, and less time apologizing for confused draft content. This guide walks through the techniques, when to use each one, and concrete prompt patterns you can copy and adapt.

Why Models Drift (And Why It Matters)

Before jumping into techniques, it helps to understand why models drift in the first place. Large language models are trained to continue text in a way that's statistically likely. They're not reasoning about your goals — they're predicting the next token. When the likely continuation conflicts with your intent, the model tends to follow probability, not your wishes.

Several common patterns cause drift:

• Open-ended instructions like "write about X" give the model enormous latitude in what to include and what tone to take.
• Missing format specification means the model falls back to its default, which is often a chatty essay rather than a structured table, JSON, or list.
• Implicit constraints that live in your head ("I didn't want a conclusion section") don't exist for the model unless you say them.
• Temperature effects: At higher temperatures, the model explores more, which can pull it away from a narrow task.
• Long context that dilutes instructions: If your instructions sit in a sea of input text, the model may weight the input more than the instruction.
• Tool or function ambiguity: If a model can call a tool but isn't told exactly when to stop, it may over-use or under-use it.

Understanding these failure modes is the first step. Each constrained prompting technique targets one or more of them.

1. Explicit Boundary Statements

The simplest constrained prompting technique is to tell the model, in plain language, what it may and may not do. This sounds obvious, but it works because models are highly sensitive to explicit instructions in the system or user turn. The key is to be specific. "Stay on topic" doesn't help much. "Do not mention pricing, competitors, or future roadmap items" does.

Prompt Pattern: In-Scope / Out-of-Scope

You are a customer support assistant for Acme Corp, maker of the AcmeCloud storage product.

IN SCOPE: Answering questions about account setup, billing issues, file sharing,
          and sync problems for AcmeCloud.
OUT OF SCOPE: Anything related to AcmeOffice (a separate product), competitor
              products, pricing negotiations, or feature requests beyond 
              forwarding to the team.

If a user asks something out of scope, respond: "That's outside what I can help
with here. I'll forward your message to the right team." Do not elaborate further.

Notice the structure: you define a domain, you define what's in and out, and you give the model a specific thing to do when it hits the boundary. This makes the constraint operational, not just descriptive. The model doesn't have to guess what "out of scope" looks like in practice.

Example: Research Boundary

You are summarizing medical research papers for a clinician audience.

INCLUDE: Study design, sample size, primary outcome, statistical significance,
         and limitations mentioned by the authors.
EXCLUDE: Background on the disease that clinicians would already know,
         moral commentary, and any speculation about clinical practice not 
         explicitly stated in the paper.

Do not add disclaimers about consulting a physician. The audience is physicians.

The last line is important. Default safety behavior sometimes injects disclaimers that are inappropriate for certain audiences. Constraining means telling the model when those defaults shouldn't apply.

2. Format Locking with Schema or Templates

When you need structured output, the most reliable constraint is to give the model an explicit template and tell it to fill it in. The closer your template is to a schema, the more predictable the output. This is especially valuable when the downstream pipeline parses the model's output.

Prompt Pattern: Fill in the Template

Extract the following information from the rental listing and output it 
using EXACTLY this template. Do not add any text before or after.

{
  "address": "<full street address including city and ZIP>",
  "rent_monthly": <number, no currency symbol>,
  "deposit": <number, no currency symbol>,
  "bedrooms": <integer>,
  "bathrooms": <integer or float, e.g., 1.5>,
  "pets_allowed": <true or false>,
  "amenities": ["<amenity 1>", "<amenity 2>", "..."],
  "availability_date": "<YYYY-MM-DD or null if not stated>"
}

Rules:
- If a field is not mentioned in the listing, use null.
- Do not infer amenities that aren't explicitly listed.
- Do not include a trailing comma after the last array element.
- Output only the JSON object. No markdown fence, no explanation.

The rules at the end are a form of constraint stacking: each one catches a common failure mode. "No markdown fence" is a real problem — models love to wrap output in ```json blocks even when you ask for raw JSON, which breaks naive regex parsers.

Template-Based Constraints for Prose

For prose output, a paragraph-by-paragraph template works as a soft constraint. It's less rigid than JSON but still keeps the structure deterministic.

Write a product description following this structure exactly. Do not add,
remove, or reorder sections.

Paragraph 1 — Hook: One sentence stating the problem the product solves.
Paragraph 2 — Solution: Two to three sentences describing what the product does.
Paragraph 3 — Differentiator: One sentence on why it's better than alternatives.
Paragraph 4 — Call to action: One sentence telling the reader what to do next.

Product: <insert product name and one-line description>

The "do not add, remove, or reorder sections" line is doing real work. Without it, models frequently add intro or conclusion paragraphs that you didn't ask for.

3. Vocabulary and Word-Choice Constraints

Sometimes the issue isn't what the model says but how it says it. AI models default to certain phrasings — "delve into," "in today's fast-paced world," "it's important to note" — that read as generic. You can constrain this away.

Prompt Pattern: Banned Phrases and Style Rules

Style constraints for this article:

Banned words and phrases (do not use any of these under any circumstances):
- "delve", "delved", "delving"
- "tapestry", "tapestry of"
- "in today's fast-paced world"
- "navigate the complexities"
- "game-changer", "game changing"
- "leverage" (use "use" instead)
- "foster" (use "build" or "encourage" instead)
- "it's important to note that" (just state the point directly)

Style rules:
- Average sentence length under 18 words.
- No sentence longer than 30 words.
- No paragraph longer than 4 sentences.
- Use active voice unless a passive construction is genuinely clearer.
- No em-dashes; use commas or parentheses instead.

This kind of prompt doesn't constrain content but it constrains expression, which is often what makes AI-written text feel AI-written. Combined with a good outline, vocabulary constraints turn out noticeably more human output.

Example: Tone Locking

Tone: direct, practical, slightly skeptical. Not enthusiastic. Not corporate.
       Not motivational. Imagine explaining to a competent colleague who 
       doesn't want to be sold to.

Forbidden tones:
- Enthusiastic ("This is amazing!", exclamation points in general)
- Corporate ("unlock your potential", "drive results")
- Salesy ("don't miss out", "act now")

Tone constraints are soft by nature — models won't perfectly hold a tone — but giving negative examples ("not enthusiastic, not corporate") is more effective than positive ones because it gives the model something to avoid.

4. Length and Density Constraints

Models tend to write more than you ask for because their training distribution rewards completeness. If you ask for "a paragraph," you often get three. Explicit length constraints fix this.

Prompt Pattern: Hard Length Limits

Write a response to the user's question. 

CONSTRAINTS:
- Between 150 and 200 words total. Count your words before outputting.
- Exactly 3 paragraphs.
- First paragraph: 2-3 sentences answering the question directly.
- Second paragraph: 2-3 sentences with the most relevant context.
- Third paragraph: 1-2 sentences with a caveat or limitation.

Do not exceed 200 words. Do not add headings or bullet points.

The "count your words before outputting" instruction sometimes helps models self-correct, though it isn't perfectly reliable. For strict length limits, the most robust approach is to generate slightly long and then post-process with a script. But for most use cases, a hard upper bound ("do not exceed 200 words") gets you within 10-15%, which is good enough for drafts.

Density Constraints

Sometimes the issue isn't length but filler. Models pad with hedges, qualifiers, and meta-commentary. A density constraint attacks this directly.

Density rule: Every sentence must introduce a new claim or piece of evidence.
Do not write sentences that only transition, summarize, or hedge.
Do not open paragraphs with "Moreover," "Furthermore," "Additionally," or similar.

If a sentence doesn't add information, cut it. I prefer terse writing.

Paired with a length constraint, this produces stripped, dense text that reads more like expert writing. It's useful for executive summaries and one-pagers where every word counts.

5. Constrained Generation with Stop Sequences

If you're working through an API, you have a programmatic constraint available that prompt-level techniques can't match: the stop sequence (also called a stop token). When the model generates a specific string you've provided, the API stops generation immediately.

This is invaluable for keeping a model from running on. Common use cases:

• Stopping after an answer when the model is prone to adding unnecessary explanations.
• Enforcing turn-taking in agent loops by stopping on a sentinel token.
• Splitting output steps by stopping at a delimiter and processing each piece separately.

Example: Stop After the Answer

User: What's 2 + 2?

Answer: 4.
END_ANSWER

With the stop sequence set to END_ANSWER, the API returns just "4." and stops before the model can add "As you can see, simple arithmetic..." This is a constraint you can't enforce at the prompt level alone.

Stop sequences are a developer feature; they're not available if you're copying a prompt into a chat UI. But if you're building anything programmatic on top of a model API, they're one of the most powerful constraint mechanisms available, and they supplement prompt-level techniques perfectly.

6. Instruction Hierarchy: Where to Put Constraints

A subtle but important question is where in the prompt your constraints go. The answer depends on the model, but a useful rule of thumb:

• System message: Use for stable, task-level constraints that always apply — in-scope/out-of-scope rules, banned phrases, output schemas.
• User message: Use for task-specific constraints — this particular user's length request, this particular field to extract.
• Final instruction repetition: If the prompt is long, briefly repeating the most important constraint at the very end helps. Models weight the end of the prompt more than the middle due to recency effects.

Prompt Pattern: Sandwich Your Constraints

[System]
You are a data extraction assistant. Output only the fields requested as JSON.
No commentary, no markdown.

[User]
Here is a lease agreement. Extract: tenant name, monthly rent, lease start date,
lease end date, and property address.

Output as JSON with these exact keys: tenant, monthly_rent, lease_start,
lease_end, address. Use null for any field not present.

[After agreement text]
Remember: JSON only, no prose, no markdown fence, no explanation.

The repetition is deliberate. It's not sloppy writing — it's a recency constraint. Models sometimes "forget" early instructions when the context is long, and a final reminder costs nothing while measurably improving compliance.

7. Handling Multi-Turn Drift

In a conversation, constraints can erode over turns. A model may start perfectly on-format, then drift toward chatty responses by turn five. This happens because each turn adds context, and the recent context of friendly conversation can outweigh the original instruction.

Techniques to Maintain Constraints Across Turns

• Re-inject the constraint in system or pinned context: If your platform supports a persistent system message, keep the core constraints there.
• Prepend the most recent user turn with a reminder: It feels unnatural, but adding "(Remember: respond only with the table, no commentary)" at the start or end of user turns keeps the model on track in long sessions.
• Use temperature settings: Long conversations often benefit from lowering temperature over time, since high temperature promotes exploration that can violate format constraints.
• Detect and resend: If you're building a tool, detect format violations programmatically and retry with a stronger prompt. This is the most robust approach for production.

Example: Pinned System Constraint

[System — pinned across all turns]
For every response in this conversation:
- Output only a single JSON object.
- No prose before or after.
- Keys must match the schema below. No extra keys.
- If you cannot answer, output {"error": "<reason>"} and nothing else.

Schema: { "summary": string, "entities": string[], "sentiment": "positive" | "negative" | "neutral" }

Pinning the system message means the model sees this constraint before every turn, which is much more effective than expecting turn-one instructions to carry over.

8. Constrained Prompting vs Fine-Tuning

A common question: if you need consistent constraints, should you fine-tune a model or just keep prompting? The trade-offs are real.

When to stay with constrained prompting:

• The constraint changes frequently (different output schemas per task).
• You're iterating and need to adjust quickly.
• You're using a model API you can't fine-tune (e.g., a hosted model).
• The constraint is complex or conditional.
• You need zero infrastructure and zero cost.

When to fine-tune:

• The constraint is stable and you're scaling to millions of calls.
• You want to enforce a consistent style that's hard to describe in words.
• You can label training data showing input → constrained output pairs.
• You want to reduce per-call token cost (fewer reminders in the prompt).

Constrained prompting is almost always the right starting point. It's free, fast to iterate on, and surprisingly effective when done well. Fine-tuning is a scale optimization, not a first resort. Many people rush to fine-tune when better prompting would solve their problem at zero cost.

A useful middle ground is caching or templating prompts. If you maintain a library of constrained prompt templates for common task types — extraction, summarization, classification, code review — you get most of the consistency benefit of fine-tuning without the ML pipeline.

Practical Constrained Prompt Checklist

Before deploying a prompt that needs to stay constrained, run it through this list. Each item catches a real, common failure mode.

• Is the output format explicit? Don't say "summarize." Say "output 3 bullets, each 15-25 words, no intro line."
• Are out-of-scope topics listed? Tell the model what not to discuss, not just what to discuss.
• Is there a fallback instruction? What should the model do if it can't answer? ("Output: I don't know," not invent an answer.)
• Are banned words or phrasings listed? Default AI-isms can be constrained away.
• Is there a length constraint? Words or token count, with an upper bound.
• Is the schema or template provided in full? Models follow templates better than descriptions of templates.
• Is the constraint repeated at the end? Especially for long prompts, end on the constraint.
• Have you tested edge cases? Ambiguous input, empty fields, conflicting constraints. Run these against the prompt.
• Does the model know when to stop? If using an API, set stop sequences for completion-style tasks.
• Is the temperature appropriate? Lower temperature (0.2-0.5) for strict format adherence, higher for creative tasks.

Common Failure Modes Even After Constraints

Even with good constraints, a few issues persist. Knowing them in advance helps you spot them fast.

• Schema drift with complex outputs: The more fields you require, the more likely it is the model will miss one or add an extra. Test with random fields missing from the input.
• Constraint violation under long inputs: As input text grows, instruction following can degrade. Move critical instructions to the end or split into prompts.
• Over-constraint paradox: Too many constraints make the model spend its output budget on constraint-monitoring instead of content. Keep constraints to the ones that matter.
• Conflicting constraints: "Be concise" plus "be comprehensive" will produce unstable output. Pick a priority.
• Format constraint vs reasoning trade-off: Very strict format constraints sometimes degrade reasoning quality. If you need both depth and structure, give the model a scratchpad first, then ask for formatted output.

When You Don't Need Constrained Prompting

Constrained prompting is worth the effort when output is downstream of a parser, when many users will see a standardized output, or when you're evaluating at scale. For exploratory work — brainstorming, early drafts, idea generation — constraints get in the way. If you're asking a model to help you think, not to produce a fixed-form artifact, leave constraints off. Over-constraining creative tasks produces bland output.

The skill is in knowing which mode you're in. Production tasks tend to be constrained. Tasks where you're not sure what you want yet tend to be exploratory. Most people default to under-constrained prompts; the experiment worth trying is to add one explicit constraint and see if your output becomes more usable.

Conclusion

Constrained prompting is the difference between a model that sometimes gives you what you want and one that reliably gives you what you need. The techniques here — boundary statements, format templates, vocabulary rules, length limits, stop sequences, instruction hierarchy management, and multi-turn maintenance — work because they convert your implicit expectations into explicit instructions the model can actually follow.

Start with the boundary statement and an explicit output format. Add vocabulary and length constraints if the output still feels generic or sprawling. Use stop sequences if you're working programmatically. Re-inject constraints in long conversations. The rest is iteration — but starting from a constrained baseline rather than an open-ended one will save you most of the editing and re-rolling that makes AI-assisted work feel slow.

If you want to practice these techniques against real-world tasks and get feedback, sign up at promptwright.net — the platform includes guided exercises on constrained prompting and dozens of other advanced prompt engineering skills, with examples tuned to current models.