AGENCYSCRIPT
CoursesEnterpriseBlog
πŸ‘‘FoundersSign inJoin Waitlist
AGENCYSCRIPT

Governed Certification Framework

The operating system for AI-enabled agency building. Certify judgment under constraint. Standards over scale. Governance over shortcuts.

Stay informed

Governance updates, certification insights, and industry standards.

Products

  • Platform
  • Certification
  • Launch Program
  • Vault
  • The Book

Certification

  • Foundation (AS-F)
  • Operator (AS-O)
  • Architect (AS-A)
  • Principal (AS-P)

Resources

  • Blog
  • Verify Credential
  • Enterprise
  • Partners
  • Pricing

Company

  • About
  • Contact
  • Careers
  • Press
Β© 2026 Agency Script, Inc.Β·
Privacy PolicyTerms of ServiceCertification AgreementSecurity

Standards over scale. Judgment over volume. Governance over shortcuts.

On This Page

What You Need FirstA Specific, Observable BehaviorA Few Test CasesTry the Positive Version FirstThe Counterintuitive First MoveWhen to Reach for the NegativeConfirm It Actually WorkedWhere to Place the ConstraintThe Beginner TrapsNaming the Forbidden ThingPiling On ProhibitionsAssuming It Stays WorkingJudging on One OutputA Complete First PassA Concrete First ExamplePick and FrameMeasureConfirm and StopFrequently Asked QuestionsWhy does the model ignore my negative instruction?Do capital letters or repetition make a constraint stronger?Should I always try the positive framing first?How do I know my first constraint actually worked?Key Takeaways
Home/Blog/A First Constraint You Can Actually Prove Works
General

A First Constraint You Can Actually Prove Works

A

Agency Script Editorial

Editorial Team

Β·December 11, 2022Β·7 min read
negative promptingnegative prompting getting startednegative prompting guideprompt engineering

If you have tried negative prompting, you have probably had the frustrating experience of telling a model not to do something and watching it do exactly that. The instinct is to write the prohibition more forcefully, in capital letters, repeated three times. That rarely helps and often makes things worse. The reason is that negative prompting works differently than people expect, and once you understand the few principles that govern it, you can get a reliable first result quickly without the trial-and-error flailing.

This piece is the fast path. It assumes you have access to a model and a behavior you want to suppress, and nothing more. It walks through the minimum prerequisites, a concrete first example, how to confirm the constraint actually worked, and the two or three mistakes that trip up almost everyone at the start. By the end you should have one negative constraint you can prove is changing outputs, which is a far better foundation than a dozen you merely hope are working.

What You Need First

A Specific, Observable Behavior

The single biggest predictor of success is choosing a behavior you can actually see in the output. "Be less annoying" is unworkable because you cannot point to it. "Do not start responses with a greeting" is workable because you can look at the first words and know instantly whether the constraint held. Start with something concrete and observable.

A Few Test Cases

You need three to five example inputs where the unwanted behavior tends to appear. Without them you are judging success on a single lucky output, which proves nothing. These cases are your evidence, and they take five minutes to assemble.

Try the Positive Version First

The Counterintuitive First Move

Before writing a single "do not," try describing what you want instead. If the problem is the model greeting users, the positive version is "begin every response with the answer." Models follow positive targets more reliably than they avoid negative regions, so this often solves the problem outright with no negative needed. This is the central insight from Trade-offs, Options, and How to Decide, and it belongs at the very start of your practice.

When to Reach for the Negative

If no clean positive framing exists, or if the behavior is a genuine prohibition you must block, then write the negative. Keep it to one sentence, stated plainly: "Do not include any pricing figures." Plain beats forceful β€” capital letters and repetition do not increase adherence and waste tokens.

Confirm It Actually Worked

This is the step nearly everyone skips, and skipping it is why people think negative prompting is unreliable.

  • Run your three to five test inputs without the constraint and note how often the unwanted behavior appears.
  • Run the same inputs with the constraint and count again.
  • Compare. If the behavior dropped, the constraint works. If it did not, the constraint is not doing its job and you need to change approach, not volume.

This paired check is a miniature version of the discipline in How to Measure Negative Prompting: Metrics That Matter, and it turns guessing into knowing.

Where to Place the Constraint

A small detail with outsized impact is where in the prompt the constraint sits. A prohibition buried in the middle of a long instruction block gets less attention than one stated cleanly near the end, close to where the model begins generating. As a beginner you do not need a theory of placement, but you should know that if a constraint is being ignored, moving it to a more prominent position is worth trying before you conclude the constraint itself is wrong. Position is a free variable that costs nothing to adjust.

The Beginner Traps

Naming the Forbidden Thing

Telling a model "never mention the word jackpot" puts the word jackpot directly in its context, and weaker models sometimes echo it. When you can, describe the category positively instead of naming the forbidden item. If you must name it, test specifically for whether the model now repeats it.

Piling On Prohibitions

The day-one impulse is to write ten rules at once. Resist it. Add one constraint, prove it works, then add the next. A stack of unverified prohibitions is exactly the mess that makes prompts unmaintainable. The 7 Common Mistakes with Negative Prompting (and How to Avoid Them) piece catalogs the rest of these.

Assuming It Stays Working

A constraint that works today can stop working after a model update. You do not need to obsess over this at the start, but know that your test cases are reusable β€” re-run them whenever the model changes. The five minutes you spent assembling test inputs keeps paying off every time the ground shifts beneath you.

Judging on One Output

The final beginner trap is declaring victory after a single good output. Models are probabilistic; one clean response proves nothing because the next input might fail. This is precisely why the paired comparison across several inputs matters β€” it replaces a lucky anecdote with evidence. Get into the habit early of never trusting a constraint you have seen succeed only once.

A Complete First Pass

Put it together: pick an observable behavior, write three to five test inputs, try the positive framing, fall back to a single plain negative if needed, run the paired comparison, and confirm the violation rate dropped. That entire loop takes well under an hour and leaves you with a constraint you can defend. From there, the path forward is to add constraints one at a time with the same discipline, and to read Best Practices That Actually Work once you are ready to scale beyond a single prompt.

A Concrete First Example

To make the loop tangible, here is a complete first pass on a real behavior: a summarization assistant that keeps adding its own opinions to summaries.

Pick and Frame

The behavior is observable β€” you can read a summary and see editorializing like "this is a smart approach." Your three test inputs are three articles that tend to provoke commentary. You try the positive framing first: "Summarize only what the text states, attributing every claim to the source." You run it.

Measure

Without any constraint, all three summaries contained opinion. With the positive specification, two of three were clean and one still slipped. The positive framing helped substantially but did not fully solve it, so you add a single plain negative as a backstop: "Do not add evaluation, praise, or criticism of the content." You re-run the three inputs and all three come back clean.

Confirm and Stop

You now have evidence: editorializing went from three of three to zero of three across your test set. That is a defensible first constraint. The temptation is to keep going and add five more rules about tone, length, and structure right now. Resist it β€” add the next constraint only when you have a behavior to fix and the bandwidth to measure it. This single-constraint discipline is what the Best Practices That Actually Work guide builds on, and the Step-by-Step Approach to Negative Prompting walks the same loop in more detail.

Frequently Asked Questions

Why does the model ignore my negative instruction?

Usually one of three reasons: the behavior is not observable enough to enforce, the instruction is buried among too many other rules, or a positive framing would work better. Start by making the behavior concrete and trying the positive version.

Do capital letters or repetition make a constraint stronger?

No. They do not measurably improve adherence and they waste tokens. A single, plainly stated constraint outperforms a shouted or repeated one.

Should I always try the positive framing first?

Yes, as a default. Models follow positive targets more reliably than they avoid negative regions, so a positive specification frequently solves the problem without any negative at all.

How do I know my first constraint actually worked?

Run your test inputs with and without the constraint and compare how often the unwanted behavior appears. A drop proves it works; no change means you need a different approach, not a louder one.

Key Takeaways

  • Pick a specific, observable behavior and assemble three to five test inputs before writing anything.
  • Try the positive framing first; it often solves the problem without any negative instruction.
  • If you need a negative, write one plain sentence β€” capital letters and repetition do not help.
  • Confirm the constraint worked by comparing the unwanted behavior's frequency with and without it.
  • Add constraints one at a time and avoid naming forbidden concepts, which can make the model repeat them.

Search Articles

Categories

OperationsSalesDeliveryGovernance

Popular Tags

prompt engineeringai fundamentalsai toolsthe difference between AIMLagency operationsagency growthenterprise sales

Share Article

A

Agency Script Editorial

Editorial Team

The Agency Script editorial team delivers operational insights on AI delivery, certification, and governance for modern agency operators.

Related Articles

General

Rolling Out AI Hallucinations Across a Team

Most teams discover AI hallucinations the hard way β€” a confident-sounding wrong answer makes it into a client deliverable, a legal brief, or a published report. The damage isn't just to the output; it

A
Agency Script Editorial
June 1, 2026Β·11 min read
General

Case Study: Large Language Models in Practice

Most teams that fail with large language models don't fail because the technology doesn't work. They fail because they treat deployment as a one-time event rather than a discipline β€” pick a model, wri

A
Agency Script Editorial
June 1, 2026Β·11 min read
General

Thirty-Second Wins Breed False Confidence With LLMs

Working with large language models is deceptively easy to start and surprisingly hard to do well. You can get a useful output in thirty seconds, which creates a false confidence that compounds over ti

A
Agency Script Editorial
June 1, 2026Β·10 min read

Ready to certify your AI capability?

Join the professionals building governed, repeatable AI delivery systems.

Explore Certification