Instruction Placement: Top, Bottom or Both?

The advice is usually “put important instructions at the beginning and repeat them at the end.” It is reasonable advice. It is also not free, it is task-dependent, and the part it leaves out is what the repetition costs you in cache.

Three placements

One instruction — say a strict output contract — and one long body of material. Three arrangements:

top     : [INSTRUCTION] [material................] [question]
bottom  : [material................] [INSTRUCTION] [question]
both    : [INSTRUCTION] [material................] [INSTRUCTION] [question]

At short lengths the three are hard to tell apart. The differences appear when the material is long — tens of thousands of tokens — which is exactly the regime a context-engineered application lives in.

What the research supports

There is published work adjacent to this question, and it is worth being precise about what it does and does not establish.

• Liu et al., “Lost in the Middle” (TACL, 2024) reports a U-shaped curve for the position of relevant content within a long input: beginning and end are used more reliably than the middle. It is about retrievable documents rather than instructions, but it is the strongest reason to believe the middle is the worst place to put anything that must be followed.
• Vendor guidance from several providers recommends placing long documents before the instruction that operates on them, for long-context tasks specifically. That is documented advice from the people who trained the models rather than an independent finding, and it should be weighted as such — but it is a real, citable position and it points at bottom.
• What nobody has published is a transferable number for your task. Position effects vary by model, by length, by whether the instruction is a format contract or a reasoning directive, and by how many instructions compete. A table of someone else’s percentages would be the least useful thing this page could contain.

The mechanism most often offered for why bottom helps is also worth stating as the hypothesis it is: an instruction placed after the material is read in the presence of the material, and it is closest to the point of generation. That is plausible, it is consistent with the U-shape, and it is not a proven causal account.

The cost nobody quotes

Here is what the standard advice omits. Instruction placement is not only a quality question; it interacts directly with prefix caching, and the three placements have different economics.

Which reframes the trade. “Repeat at the end” is close to free for a short, critical instruction — an output contract, a refusal boundary, a format spec — and genuinely expensive for a long persona block. So the right question is not “top or bottom” but which parts of the instruction earn a second copy. Almost always that is a small subset: the rules whose violation is detectable and costly, not the whole system prompt.

A harness that settles it for your task

Because the answer is task-specific, the useful deliverable is the experiment rather than a result. This is small enough to run in an afternoon and gives you a number that is actually about your workload.

const PLACEMENTS = {
  top:    (i, m, q) => [i, m, q],
  bottom: (i, m, q) => [m, i, q],
  both:   (i, m, q) => [i, m, i, q],
};

// One fixed instruction, N held-out cases, K material lengths.
// The grader must be mechanical: does the output satisfy the contract?
for (const [name, build] of Object.entries(PLACEMENTS)) {
  for (const len of [2_000, 20_000, 100_000]) {          // pad to length
    let pass = 0;
    for (const c of cases) {
      const out = await call(build(INSTRUCTION, pad(c.material, len), c.q));
      pass += check(out, c) ? 1 : 0;      // regex / schema / exact match
    }
    report(name, len, pass / cases.length);
  }
}

Four things make the difference between a harness that answers the question and one that produces noise:

• Grade mechanically. Instruction-following is checkable — did it emit valid JSON, did it stay under the word limit, did it use the required heading? If your grader needs a model, you have added a second source of variance to a small effect.
• Vary length, because length is the variable. At 2,000 tokens all three placements will look identical, and reporting that as “placement does not matter” would be the wrong conclusion drawn from the wrong regime.
• Hold everything else fixed. Same wording, same temperature, same model, same cases. If the instruction text differs between arms you are running a prompt A/B and not a placement one.
• Use enough cases to see a small effect. Placement effects are usually small. Twenty cases cannot distinguish 85% from 90%, and reading a difference of one case as a result is how these experiments produce confident nonsense.

Re-run it when you change model. This is a refresh-decay question by nature: the answer is a property of a model family at a length, and both of those change under you.

A defensible default

Until the harness says otherwise, this ordering is consistent with the published position work, cheap in cache terms, and easy to reason about:

[ full system block        ]  <- top, cacheable, the complete instruction
[ tool schemas             ]
[ static reference         ]
[ history                  ]
[ retrieved material       ]
[ tool results             ]
[ SHORT contract restated  ]  <- bottom, uncached, only the checkable rules
[ the question             ]

The restatement should be a handful of lines, not a copy: the output format, the hard prohibitions, the length limit. Everything whose violation you could detect with an assertion. It also happens to be a direct mitigation for instruction dilution, which is the failure this placement question usually surfaces through — the contract erodes at turn thirty, and a late restatement is the cheapest available answer.

One thing not to do: restate an instruction in different words in the two positions. Two phrasings of a rule read as two rules, and where they differ even slightly the model has to reconcile them. Copy the same text or omit it. This is also a maintenance hazard rather than only a modelling one — the two copies drift as one of them is edited, and the resulting contradiction is invisible in a diff because the two strings live hundreds of lines apart. Render the restatement from the same constant the top copy uses, so drift is impossible by construction.

The same reasoning bounds how many instructions deserve this treatment. Restating three rules is a targeted mitigation; restating fifteen recreates the dilution problem at the end of the prompt instead of the beginning, and it costs full price every request. Choose the restated set by a test that has nothing to do with importance-in-principle: does a downstream assertion fire when this rule is broken? If yes, restate it, because you will find out when it fails. If no, leave it in the system block.