As a senior software engineer, project lead, and data scientist, I've noticed a pattern over the last year: more and more of my week goes to reviewing clients' system prompts to answer a few typical questions.

"Why was the answer formatted this way?", "Why was this paragraph added in?", and most commonly "Why does this paragraph include this value?"

More often than not, I find my answer to be the same: "Because it fits your provided examples."

Think about the last time you were trying to have an agent review a set of records and provide a summary of them. Maybe you've instructed the agent to "create a table that compares these records" and expected something simple with a couple of columns outlining the high-level differences. Your instructions seem pretty clear but you end up getting a CSV file that has 32 columns with a paragraph per column per row outlining differences down to the bit. This isn't a case of a bad model or bad data, but instead it's a case of a model that's a bit too smart with a bit too much data and not enough direction.

In the example outlined above, you provided seemingly basic instructions to compare data and put it into a table. As humans, we might think that is very straightforward at first glance. However, once we actually dive into the work a few questions might pop up, "What parts of the dataset should this comparison be focused on? What should the format of the comparison be? How do we want to output this table? Do we need to style it in a particular way?" Every agent goes through a similar thought process but more often than not, they make an assumption and run with it. This leaves it up to you to reprompt the agent with minor tweaks until you've happened to answer all of those questions without realizing it.

Those reprompts usually end up looking something like this:

  • What should the comparison focus on? "Ignore the metadata values about created and updated time; compare the $ values and quantities."
  • What should the format be? "One row per record, a short phrase per cell, and a final column for the key difference."
  • How should it be output? "Return a simple table in your response, not a file."
  • Does it need styling? "No styling. It's getting pasted into an email."

So what does that mean for our prompts? Well, it means that all of the unnecessary work could have been avoided with some upfront direction: a green light for what we want, a red light for what we don't, and a little bit of yellow to keep it balanced.

Green Light: Tell It What You Want

Let's go back to our table. The first fix is to put those answers into the original prompt instead of spreading them across four reprompts. That alone gets you most of the way there.

The second fix is to add an example, and it's a good one. Anthropic calls examples "one of the most reliable ways to steer [the model's] output format, tone, and structure." So you write up a clean sample table and paste it into the prompt.

Next run, every comparison comes back with the exact same columns, the same column names, and suspiciously similar wording in every cell, even when the data called for something different. That's the answer from the top of this post: it fits your provided examples. The model isn't misunderstanding you, it's following you a little too closely. OpenAI warns that models can use sample phrases "verbatim and start to sound repetitive," and notes that its newer models follow instructions more literally than older ones. Anthropic recommends examples that vary "enough that [the model] doesn't pick up unintended patterns."

A good example shows the model the target. What it doesn't show is which parts of that target actually matter, and that's where the red light comes in.

Red Light: Tell It What You Don't Want

This is the piece I see missing most often. The prompts I review are full of what the team wants and almost never say what they don't.

Interestingly enough, both Anthropic and OpenAI tell you to lead with the positive. Anthropic says to "Tell [the model] what to do instead of what not to do" and OpenAI says "Instead of just saying what not to do, say what to do instead." But when you look at their own example prompts, the "don't" never actually goes away. OpenAI's improved prompt still tells the agent not to ask for PII, it just adds what to do instead: point the user to a help article.

Anthropic's frontend sample prompt has a "Focus on" list sitting right next to an "Avoid" list that calls out things like "purple gradients on white backgrounds." And when Anthropic improves "NEVER use ellipses," it keeps the "never" and adds the why: the response is read aloud by a text-to-speech engine that can't pronounce them.

So the lesson isn't to stop writing "don't." It's to never leave a "don't" on its own. Pair it with what to do instead, and tell the model why.

The same goes for examples. Remember that 32-column CSV? That isn't a failure to throw away, it's the raw material for your negative examples. Take what went wrong (extra columns, paragraphs where a phrase would do, a file nobody asked for), put a version of it in the prompt, label it as a negative example, and say why it's wrong. Now the model can see both the target and the edges around it.

When I add negative examples to a client's prompt, I try to stick to a few rules. Label them clearly, because an unlabeled negative example is just another example to copy. Make them near-misses rather than obviously wrong, because a negative example that looks almost right teaches the most. And pull them from real failures you've actually seen in traces, evals, or user complaints.

If your agent uses tools, this matters even more. Anthropic says tool descriptions should explain "When it should be used (and when it shouldn't)" and OpenAI tells you to "describe when (and when not) to use each function." In the agents I debug, a missing "when not to use this" is one of the most common reasons a tool gets called when it shouldn't.

Yellow Light: Don't Underdo It, Don't Overdo It

Too few signals and everyone guesses. Too many and nobody gets anywhere. Once people discover the red light, the temptation is to put one on every corner. For the sanity of everyone involved, resist it.

Underdoing it is what got us that 32-column CSV in the first place. There wasn't enough direction, so the agent filled in the gaps with its own assumptions. Overdoing it fails in a different way. Anthropic's take on stuffing a prompt with every edge case you can imagine is "We do not recommend this," and it suggests a small set of "diverse, canonical examples" instead. More rules also means more chances for two of them to disagree, and OpenAI warns that contradictory instructions can be especially damaging for its newer models, which burn reasoning trying to reconcile them. The sweet spot is the red lights you've actually run into, not every one you can think of.

It also helps to remember that you're not writing for a human. A lot of what we do to get a person's attention, like writing in all caps, repeating the important part a few times, or adding a "PLEASE" for good measure, is just noise to an agent. OpenAI's guide says it's "generally not necessary to use all-caps or other incentives like bribes or tips," and that leaning on them can cause the model to pay attention to an instruction "too strictly." What does carry over from talking to people is the why. A short reason behind a rule gives the agent something to generalize from, which is exactly why it helped back in the red light section.

And whenever you change a prompt, re-run your evals. OpenAI notes that even adding examples "may hurt performance for reasoning models."

Putting It All Together

Here's what our table prompt looks like with all three lights on:

Compare the order records below. Ignore the created and updated timestamps; compare the $ values and quantities. Return a simple table in your response with one row per record and these columns: record, price, quantity, key difference. Keep each cell to a short phrase, with no styling.

Don't add columns beyond these, and don't export to a file. This table gets pasted into a weekly status email that's read on a phone, so anything wider than four columns or longer than a phrase per cell won't get read.

If a record is missing a value, write "n/a" rather than guessing.

Good example:
Record | Price | Quantity | Key difference
Order 1042 | $1,200 | 40 | Lowest price per unit
Order 1043 | $1,850 | 40 | Same quantity, $650 more

Negative example:
Record | Price | Quantity | Created | Key difference
Order 1042 | $1,200 | 40 | 2026-09-14 | Order 1042 costs less than Order 1043 for the same quantity, which suggests a better negotiated rate with the supplier.
Why it's wrong: It adds the created timestamp this prompt says to ignore, and the key difference is a full sentence instead of a short phrase.

To keep the demo short, there's only one example of each. In a real prompt, include a few varied good and negative examples so the agent learns the pattern instead of copying the wording of a single sample.

Green lights show the model where to go. Red lights show it where to stop. And the next time someone asks me why their agent added a paragraph nobody wanted, I'd love for the answer to be something other than "because it fits your provided examples."

Have any questions, or want to discuss how Elevate can help you and your team skip the traffic jam with proper signalling? Contact us and we'll be happy to help!