Why Cleaner LLM Instructions Can Make an Agent Worse

Why cleaner LLM instructions can reduce agent performance, and why prompt wording, structure and repetition need careful testing.

It is natural to assume that a custom AI agent will benefit from a cleaner instruction set.

Remove unnecessary formatting. Delete decorative emojis. Combine similar statements. Replace several lines with one concise sentence. Preserve the meaning while reducing the length.

For ordinary documentation, that is sensible editing. I have become much less convinced that it is sensible when the document being edited is the instruction set for a large language model.

I ran into this while refining a custom agent that had been performing unusually well. It could solve practical problems that several of my other agents repeatedly struggled with, and I wanted to tidy its instructions without changing what they actually said.

I asked another AI assistant to remove unnecessary emojis, excessive spacing and similar cosmetic clutter.

Instead, it proudly reported that it had reduced the instructions by roughly 40–50 per cent. It had combined similar lines, removed repetition and condensed statements it considered redundant.

That was not what I had asked it to do.

More interestingly, it raised a question I had not intended to investigate:

If two instruction sets appear to mean the same thing to a human, why might the shorter one produce a less capable agent?

The more I looked into it, the more the answer seemed to be that semantic equivalence is not necessarily behavioural equivalence when prompting an LLM.

A human reads meaning while an LLM receives a token sequence

Consider these two instructions:

Prefer simple, robust solutions. Bias toward approaches that could actually be built, tested or simulated. If something is theoretically possible but impractical, say so explicitly.

And:

Prefer simple, robust, testable solutions and clearly distinguish theoretical feasibility from practical viability.

As prose, the second version looks better. It is shorter, cleaner and appears to preserve the important ideas.

But the model does not receive an abstract representation of the meaning that is guaranteed to be identical in both cases. It receives two different sequences of tokens, with different words, sentence boundaries, relationships and ordering.

An LLM does not first reduce both passages to one perfectly stable version of their “true meaning” and then execute that meaning like conventional program code. Its response is conditioned on the actual sequence it receives, the surrounding context and the statistical patterns learned during training.

There is good experimental evidence that this distinction matters.

Research has repeatedly found that semantically similar prompts can produce materially different results. One study of mathematical reasoning found that relatively subtle paraphrasing affected both answer distributions and solving rates. See Paraphrase and Solve, NAACL 2024.

A broader study introducing a Prompt Sensitivity Index found that instruction tuning and increased model size do not necessarily remove this sensitivity. Interestingly, it also found that even a single worked example could substantially reduce variation. See A Prompt Sensitivity Index for Large Language Models, EMNLP 2024.

The practical implication is straightforward: the wording is not merely a container for the instruction. The wording is part of the instruction.

Repetition is not simply “weighting”

One explanation I was given was that repetition effectively adds weight to a desired behaviour.

• Simple
• Robust
• Buildable
• Testable
• Simulatable
• Practical
• Explicit about impracticality

I think that is a useful working metaphor, but I would be careful about treating it as a literal mechanism.

Repeating a concept does not assign it a numerical priority in the way that changing a value in a configuration file would. There is no reason to assume that the model simply counts occurrences and gives the most frequently repeated instruction the greatest importance.

Something subtler is happening.

Similar words can encode different tests

Take buildable, testable, practical and simulatable.

They overlap, but they are not interchangeable.

A solution can be technically buildable but economically impractical. It can be theoretically testable but impossible to test safely. It can be practical to prototype while being completely unsuitable for production. Something may be straightforward to simulate while being extremely difficult to validate against reality.

If all of those ideas are compressed into a phrase such as “practical viability”, the general intent survives, but several separate engineering checks may disappear.

What looks like redundancy to an editor may actually be a collection of related but operationally distinct constraints.

Redundancy can provide fault tolerance

LLMs do not obey every part of a complex instruction set with perfect reliability.

Research into complex instruction following has found that models increasingly omit, misinterpret or violate requirements as the number of constraints and their interactions increase. INFOBENCH, ACL 2024 investigated this problem, and more recent work such as EIFBENCH, EMNLP 2025 has continued to find limitations even with highly capable models.

Expressing an important principle in several related ways can therefore act as a form of behavioural redundancy. If one cue is underused in a particular generation, another may still steer the response in roughly the intended direction.

That does not mean repetition is always beneficial. Enough overlapping or conflicting instructions will eventually create their own problems. The useful distinction is between purposeful reinforcement and indiscriminate duplication.

Specific words bring different associations with them

There is another possibility.

Words such as robust, production-ready, engineering constraint, testable and practical viability appear in different contexts across the material on which language models are trained.

It is therefore reasonable to expect them to influence continuation differently, even when a human considers them broadly related.

Research into lexical sensitivity supports that general idea. Substituting individual words can reduce model performance even when the resulting prompt remains perfectly reasonable to a human reader. See Unveiling the Lexical Sensitivity of LLMs, EMNLP 2024.

This may help explain something I have seen repeatedly in practice: wording discovered through trial and error can outperform a more elegant paraphrase.

The improvement may not exist because the original sentence expresses a better abstract idea. It may exist because that particular collection of words interacts with the model more effectively.

Sometimes a list is actually an algorithm

Another part of the original instruction set contained the following:

Re-frame the problem clearly.

Identify what is actually being asked versus what is being assumed.

Restate the core engineering challenge in plain terms.

An editor could quite reasonably compress that into:

Clearly restate the underlying engineering problem and distinguish it from assumptions.

The shorter version is not inaccurate.

But I do not think it is equivalent.

The original can be read as a three-stage process:

1. Change the frame through which the problem is being viewed.
2. Separate the actual request from assumptions embedded in it.
3. Construct a new statement of the engineering problem.

The condensed version describes the desired result. The original also describes a way of getting there.

That is an important distinction.

When we call several lines “repetitive”, we may be looking at something that is actually procedural decomposition. Each line gives the model another intermediate operation to perform before producing the answer.

This idea is consistent with work on complex instruction following, where researchers often decompose compound prompts into individual requirements because models do not necessarily satisfy a merged requirement as reliably as its individual components. See ULTRAIF, EMNLP 2025.

I therefore think describing the effect as “cadence” is probably too literary. A more defensible explanation is that the original wording encoded a sequence of cognitive operations, while the summary encoded only the destination.

Position and structure matter too

The wording itself is not the only variable.

Where information appears in a context can change how reliably it is used.

The well-known Lost in the Middle research showed that models can use information more successfully when it appears near the beginning or end of a long context than when equivalent information is placed in the middle.

That work concerned information retrieval rather than custom-agent instructions, so I would not claim that it directly proves where agent rules should be placed. It does demonstrate the broader point, however: identical information can have different effects depending on where it appears.

Formatting probably matters for related reasons.

Headings, lists, sentence boundaries and repeated checkpoints distinguish roles, constraints, procedures and examples from one another. They also resemble structural patterns the model has encountered throughout training.

Removing an emoji is unlikely to ruin a good agent.

Removing a section boundary, collapsing three procedural steps into one sentence, or deleting what appears to be a repeated engineering constraint is a very different operation.

Why asking an AI to “clean up” a prompt is risky

This is where my original request went wrong.

I thought I had asked for cosmetic editing. The model interpreted the task as editorial improvement.

From the perspective of normal writing, its behaviour was completely reasonable. Repeated ideas are normally considered defects. Editors are supposed to remove redundancy, combine overlapping points, simplify verbose prose and produce a more coherent structure.

Those instincts become dangerous when the text being edited is an operational control surface.

An agent instruction set is closer to configuration, policy or lightly structured code than it is to an essay.

A line that appears stylistically redundant may be doing actual control work.

This means that “preserve the meaning” is not a sufficiently strict requirement when asking another model to tidy an agent prompt. It may preserve what it considers the semantic meaning while substantially changing the resulting behaviour.

A much safer request would be something like:

Perform formatting-only changes. Preserve every word, sentence, repetition, example, ordering relationship, heading and operational distinction unless I explicitly approve a substantive change. Do not paraphrase, merge, summarise, deduplicate or condense any instruction. Report potential redundancies separately without modifying them.

That wording makes the boundary much clearer. The task is not to improve the prose. It is to preserve the control logic while changing presentation only.

This does not mean longer prompts are better

There is an obvious trap here, which is to conclude that if repetition can help, more instructions must be better.

That does not follow.

Long instruction sets have their own failure modes. Important requirements can become harder to locate. Similar instructions can conflict subtly. Exceptions can weaken the primary rule. Additional detail consumes context. Eventually there may simply be more constraints than the model can reliably satisfy at once.

Research into prompt compression has shown that substantial reductions can sometimes preserve performance. LLMLingua, for example, explores methods for compressing prompts while attempting to retain information important to the task.

The important difference is that this is treated as an optimisation problem, not an ordinary prose-editing exercise.

Similarly, work on dense instruction sets suggests that continually adding requirements does not guarantee better performance because instructions can compete for limited compliance capacity. See What Prompts Don’t Say.

So my conclusion is not “never shorten a prompt”.

It is this:

Never assume that shortening a prompt preserves its behaviour merely because a human reader believes the revised wording means the same thing.

Treat a good instruction set like working software

This is probably the most useful thing I took away from the exercise.

If a custom-agent instruction set consistently solves difficult cases, it is no longer just prose. It is a tested artefact.

I would now approach changing one in much the same way I would approach changing working software:

1. Preserve the original version.
2. Build a representative set of test problems.
3. Record the behaviours that matter and the failures you are trying to avoid.
4. Change one category at a time, such as formatting, wording, ordering or length.
5. Run the original and revised versions against the same cases.
6. Compare actual behaviour rather than how elegant the instructions look.
7. Keep the revision only if it performs at least as well.

Repeated runs matter because LLM output is variable. One success or one failure is weak evidence.

The test set also needs to contain the awkward cases that made the original agent valuable in the first place.

This is important because a compressed instruction set may appear completely successful on ordinary questions while quietly losing the behaviour that differentiated the agent from every other one.

What I think is actually happening

My original observation still seems sound:

Instructions that look redundant to a human can contain useful behavioural scaffolding for an LLM.

I am less willing, however, to describe that effect simply as repetition “adding weight”. There are several plausible mechanisms, and probably more than one is operating at once.

• Repeated concepts provide multiple opportunities to influence generation.
• Near-synonyms can preserve separate operational tests.
• Separate lines can turn a broad objective into a sequence of executable steps.
• Different words carry different learned associations.
• Formatting helps preserve boundaries between procedures, constraints and examples.
• Position can affect how reliably information is used.
• Condensation can remove examples, emphasis or structure that was doing genuine work.

What I would not claim is that we can look inside a proprietary model and identify with certainty which of these mechanisms caused one particular instruction set to work better.

Phrases such as “this word activates a reasoning pathway” or “the cadence makes the model think differently” may be useful intuitions, but they should remain hypotheses unless we have evidence for the underlying mechanism.

What we can observe externally is enough to be useful.

LLMs are sensitive to wording, structure, ordering and context. An edit that preserves meaning for a person is not guaranteed to preserve behaviour for a model.

That changes how I think about mature agent instructions.

If an instruction set is performing exceptionally well, I would not optimise it for elegance or word count simply because parts of it look untidy. I would preserve it, benchmark it and change it incrementally.

The untidy parts may be carrying more of the intelligence than they appear to be.