Prompts grow the same way legacy code does: one incident at a time.
Something goes wrong, someone adds a line telling the model not to do that again, it works, everyone moves on. Repeat for six months and you have a two-thousand-token instruction block that nobody dares touch, full of rules whose original incidents nobody remembers, some of which now contradict each other.
The instinct when an agent misbehaves is to add an instruction. It's usually the wrong move. Here are three we took out.
1. "Do not make up information. Only use the provided context."
The most common line in production prompts, and one of the least effective.
It's a request for a behaviour the model can't reliably self-police. The model doesn't experience "making things up" as a distinct act it could choose to avoid — it's generating plausible continuations, and a fabricated citation feels exactly like a real one from the inside. Asking it to try harder not to is asking for a guarantee it isn't structured to give.
What replaced it: structural constraints instead of a plea.
Every factual claim must map to a retrieved passage, and the response format requires the source ID inline. Then a validation step checks that each cited ID actually exists in what was retrieved. If a claim has no source, it doesn't ship — it gets flagged, and the workflow escalates rather than guessing.
The instruction became a check. The model still occasionally reaches beyond its context; it just can't get past the door any more.
2. "Be concise but thorough. Use a friendly, professional tone."
This one survived a long time because it's inoffensive. It's also close to meaningless.
"Concise but thorough" is a contradiction the model resolves by splitting the difference, differently every time. "Friendly, professional" describes an enormous space of outputs, most of which sound like a generic brand. And the words fight each other — asking for both brevity and completeness in the same breath produces the medium-length hedge that reads like AI.
What replaced it: examples, and a hard limit.
Three or four real messages the client actually sent, in their real voice, with a note on why each works. Plus one concrete constraint — under 80 words for a WhatsApp reply — because a number is enforceable and "concise" isn't.
Examples outperform adjectives by a wide margin. Voice is a thing you show, and every operator already has a folder of good replies. They're better training material than any description of tone.
The version that stuck at Microcrew isn't a tone paragraph at all. It's the operator's own past messages, and a word count.
3. "If the customer seems frustrated, escalate to a human."
Reasonable-sounding. In practice it made escalation worse.
Two problems. First, "seems frustrated" is a judgment the model makes inconsistently — a terse message from a busy client reads as annoyance, three exclamation marks from a cheerful one doesn't. Second, and more damaging, the instruction implied escalation was a special case triggered by mood, when escalation should be triggered by conditions the system can verify.
What replaced it: explicit, checkable triggers in the routing layer, outside the prompt.
Escalate when the conversation exceeds N turns without resolution. When required information is still missing after two attempts to get it. When the request touches a category on the always-human list — refunds, complaints, anything contractual. When retrieval returns nothing above the confidence floor. When the customer asks for a person, in any phrasing.
Sentiment still plays a role, but as one input among several, scored and logged, not as a vibe check buried in an instruction the model may or may not weight this time.
The result is escalation you can audit. When someone asks "why didn't this reach a human sooner," there's an answer with a rule attached, rather than a shrug about the model's mood-reading.
The pattern
Each deletion follows the same move: take the thing you were asking the model to remember to do, and make it something the system does structurally.
That's not a criticism of prompting. Prompts are how you convey task, voice, and context, and that work matters enormously. But a prompt is a request, and a request is the weakest available enforcement mechanism. Anything that must be true every time belongs in code — in validation, in routing, in the schema of the output, in the tools the agent is and isn't given.
A good diagnostic: read your system prompt and mark every line that's there to prevent a failure. Those lines are your bug list, written in the least reliable notation available. Most of them want to be a check, a tool constraint, or a routing rule.
What this needs to work
You can only delete prompt lines safely if you can tell whether the deletion broke something — which means an eval suite, and versioned prompts so you can see exactly what changed between the version that worked and the one that didn't.
Without those, nobody will ever remove a line, because the downside of removing a load-bearing rule is invisible until a customer finds it. That's how prompts get to two thousand tokens: not because anyone thinks the rules are good, but because deletion is unmeasurable.
Make deletion measurable and prompts get shorter on their own.
Monday: would you let it email your client? The trust threshold, from the operator's side of the desk.