Why does my support agent ignore half of my system prompt?

Usually because those instructions are not checkable. A rule like "be helpful" or "keep it reasonably short" names a quality with no observable action or bound, so the model has nothing concrete to comply with and quietly interprets it however the moment suggests. Rewrite each one as a measurable rule ("reply in at most 4 sentences", "escalate when unsure") and the behavior becomes something you can actually hold it to.

How do I shorten a bloated system prompt without losing behavior?

Delete the words, not the intent. Most bloat is hedging ("try to", "do your best to"), wordiness ("in order to", "at the end of the day"), and vague qualities ("friendly", "in a timely manner") that constrain nothing. Replace each vague line with one MUST/NEVER rule that has a concrete action or bound. Seven mood-board lines collapse into five rules that each say exactly one checkable thing, and the prompt gets shorter and stricter at the same time.

What makes a prompt rule measurable?

A rule is measurable when a reader (or a checker) can look at a reply and decide whether it obeyed. "At most 4 sentences", "greet by name in the first message", and "never promise a refund without a confirmed order number" are all measurable: each names an observable action or a countable bound. "Be concise", "be empathetic", and "when appropriate" are not, because there is no criterion to judge by.

What is a good TypeGlish score for a system prompt?

Aim for a B or better. The score is deterministic and names its own biggest lever, so treat it as a gate rather than a grade: run typeglish score on the .tg source, read the lever line, and fix that facet first. In this rewrite the same prompt moved from D (54/100) to B (89/100); the remaining lever was enforceability, because a couple of rules still lean on judgment the checker cannot fully see into.

← Tidelines/Best practicesJul 17, 2026

Rewrite: a bloated support prompt, cut to rules that check

This prompt reads perfectly. A new hire would nod along. It also scores a D, because almost nothing in it can be checked. We rewrite it line by line into rules the compiler can hold you to, and watch the score climb.

by TypeGlish team7 min read#best-practices

Reads fine. Checks badly.

TL;DR A support prompt that reads perfectly can still score a D, because vague qualities like "be helpful" and "keep it reasonably short" constrain nothing a checker can see. Rewrite each one as a measurable MUST/NEVER rule with a concrete action or bound, and the same prompt moves from D (54) to B (89). Shorter, and stricter.

Here is a support-agent system prompt of the kind that ships every day. It is polite, it is sensible, and every line sounds like advice you would give a good hire. Read it and you will not find a single thing wrong. Run it through the checker and you get a D, because "sounds like good advice" and "is a rule a model can follow" are not the same property. This post is the rewrite: same intent, same length or shorter, but every line turned into something the compiler can actually defend.

§1The prompt that reads fine

This is the honest starting point, typed the way most support prompts actually get written: a role line and a bulleted list of good intentions.

support.tg (before)✗ D (54/100)

# Role
You are a friendly and helpful customer support agent.

# Guidelines
- You SHOULD always try to be as helpful as you possibly can to every single customer.
- At the end of the day, please make sure to keep your responses reasonably short when appropriate.
- It is generally considered to be a good idea to remain friendly and professional at all times.
- You might want to consider being a little bit more empathetic with customers who seem upset.
- Always be sure to provide accurate and correct information to the best of your ability.
- In order to be helpful, you should go above and beyond for the customer.
- Please do your best to resolve the issue in a timely manner.

Nothing here is offensive. That is the trap. "Helpful," "friendly and professional," "reasonably short," "timely manner": every one is a quality with no criterion, so the model reads each however the current turn nudges it. The checker sees straight through it.

tg check - output

support.tg:5:21  info   prompt/hedging  Hedging - "try to" turns this
  instruction into a suggestion the model may skip. Commit to a modal.
support.tg:6:83  info   prompt/vague  Vague - "when appropriate" names a
  judgment call without the criterion to judge by, so nothing can check it.
support.tg:8:7   info   prompt/hedging  Hedging - "might want to" ...
support.tg:9:1   warn   prompt/unmeasurable  Unmeasurable rule - no
  observable action or bound, so nothing can check compliance.
support.tg:10:3  info   style/wordy  Wordy - "In order to" can be "to".
support.tg:11:10 info   prompt/hedging  Hedging - "do your best to" ...
support.tg:11:44 info   prompt/vague  Vague - "in a timely manner" ...

✓ 1 file - 0 error, 1 warning, 6 info

Seven flags on seven lines. None of them block a build (this compiles), which is exactly why prompts like this ship. They are quality debts, and they come due at runtime, one inconsistent reply at a time.

§2What the score is measuring

The flags are the symptom; the score is the diagnosis. It is deterministic, and more useful than the letter grade is the single lever it names.

tg score - before

support.tg - D (54/100)  proven errors: none  tiers: base+z3
  planes  runtime 56 (what the model reads) · hygiene 50 (source only)
  facets  enforceability 24 · consistency 100 · style 6 · security 100
  lever   enforceability 24/100 (up to +20 overall) - Write rules as
          MUST / NEVER <verb> with concrete bounds, not vague qualities.

Enforceability at 24 is the whole story. The prompt is internally consistent (nothing contradicts) and safe, but it barely constrains behavior. The score is telling you where the points are: turn qualities into rules.

That is the target. Not "add more instructions," not "make it firmer sounding": make each line into something a checker (or a reviewer, or you in three months) can look at a transcript and rule on. A rule you can parse is a rule you can defend.

§3The rewrite, rule by rule

Now the same prompt, same intent, rewritten. "Helpful" gets a scope so it stops being a mood. "Reasonably short" becomes a sentence bound. "Empathetic with upset customers" becomes an ordered action: acknowledge, then fix. "Accurate to the best of your ability" becomes the honest version of that promise: escalate instead of guessing. And each rule carries an @@ note saying why it exists, so the next editor does not delete it by accident.

support.tg (after)✓ compiles · B (89/100)

# Role
@@ role: scope "helpful" to a domain so it stops being a mood
You are a customer support agent for an online retailer.

# Constraints
@@ brevity: replies over four sentences get skimmed, not read
- MUST reply in at most 4 sentences.
@@ greeting: the name confirms we pulled the right account
- MUST greet the customer by name in the first message.
@@ empathy_first: acknowledging before fixing lowers repeat contacts
- WHEN a customer is upset THEN acknowledge the problem before proposing a fix.
@@ no_guessing: a wrong policy quote costs more than an escalation
- WHEN you are unsure of a policy THEN escalate instead of guessing.
@@ refund_guard: a refund without an order number cannot be reconciled
- NEVER promise a refund without a confirmed order number.

Seven mood-board lines became five rules that each say one checkable thing. It is shorter than the original and constrains far more. The @@ notes never reach the model; they are there for the humans who edit this next.

tg score - after

support.tg - B (89/100)  proven errors: none  tiers: base+z3
  planes  runtime 85 (what the model reads) · hygiene 100 (source only)
  facets  enforceability 60 · consistency 100 · annotation 100 · style 100
  lever   enforceability 60/100 (up to +11 overall) - Write rules as
          MUST / NEVER <verb> with concrete bounds, not vague qualities.

D to B, a 35-point jump, from the same intent expressed as rules. The lever is still enforceability, honestly: "acknowledge the problem" and "escalate when unsure" lean on judgment the checker cannot fully see into. That is the real ceiling of this draft, not a failure, and it is a far better place to argue from than a D.

§4What the rewrite bought you

The point was never the score. The score is a proxy for a property you actually want: a prompt where every line pins behavior instead of gesturing at it. Three things changed that a spellcheck never would. Every rule now has one job, so an edit to the refund rule cannot quietly loosen the brevity rule. Every rule is observable, so a bad transcript can be traced to the exact line that failed. And every rule has a @@ note, so the reason it exists survives the next person who thinks it looks redundant.

This is the same loop whether you are writing a returns bot, a triage router, or a voice agent: write the rule, run check, read the lever the score names, and rewrite the vaguest line into the most measurable one you can. It pairs naturally with the eight prompting rules that survive production, and if you would rather build a prompt this way from a blank file than rewrite an old one, the booking-agent walkthrough runs the loop from a one-line brief.

Field note

The score command and every diagnostic here (prompt/hedging, prompt/vague, prompt/unmeasurable, style/wordy) shipped in TypeGlish 0.1.0. Both the before and after prompts on this page are re-checked against the real compiler by the CI guard on every build, so the D and the B are facts, not screenshots. Run tg score on your own support prompt and start with whatever the lever line says.

FAQCommon questions

Why does my support agent ignore half of my system prompt?: Usually because those instructions are not checkable. A rule like "be helpful" or "keep it reasonably short" names a quality with no observable action or bound, so the model has nothing concrete to comply with and quietly interprets it however the moment suggests. Rewrite each one as a measurable rule ("reply in at most 4 sentences", "escalate when unsure") and the behavior becomes something you can actually hold it to.
How do I shorten a bloated system prompt without losing behavior?: Delete the words, not the intent. Most bloat is hedging ("try to", "do your best to"), wordiness ("in order to", "at the end of the day"), and vague qualities ("friendly", "in a timely manner") that constrain nothing. Replace each vague line with one MUST/NEVER rule that has a concrete action or bound. Seven mood-board lines collapse into five rules that each say exactly one checkable thing, and the prompt gets shorter and stricter at the same time.
What makes a prompt rule measurable?: A rule is measurable when a reader (or a checker) can look at a reply and decide whether it obeyed. "At most 4 sentences", "greet by name in the first message", and "never promise a refund without a confirmed order number" are all measurable: each names an observable action or a countable bound. "Be concise", "be empathetic", and "when appropriate" are not, because there is no criterion to judge by.
What is a good TypeGlish score for a system prompt?: Aim for a B or better. The score is deterministic and names its own biggest lever, so treat it as a gate rather than a grade: run typeglish score on the .tg source, read the lever line, and fix that facet first. In this rewrite the same prompt moved from D (54/100) to B (89/100); the remaining lever was enforceability, because a couple of rules still lean on judgment the checker cannot fully see into.

∿ washed up Jul 17, 2026 ∿