Context Engineering Is Just Information Architecture With Consequences
What you put in an LLM's context window is information architecture. The same principles apply — priority, grouping, hierarchy — but the stakes are higher.
Context engineering — the practice of deciding what goes into an LLM's context window, in what order, and in what structure — is not a new discipline dressed in new language. It's information architecture. The principles are the same: most important content first, related content grouped, structure that helps the reader find what they need. The difference is that in a website or a document, a confused reader can scroll. In a context window, a confused model hallucinates.
The Hierarchy of Context
A well-structured LLM context has a predictable shape. From most to least authoritative:
- System prompt — defines role, constraints, output format, and any invariants the model should never violate
- User message — the specific task, including all task-relevant detail
- Retrieved documents — external content brought in to answer the question (RAG results, tool outputs, file contents)
- Tool results — outputs from prior tool calls in the conversation
This isn't just convention — it reflects how models weight information. Instructions at the top of a system prompt carry more weight than instructions buried at the bottom. Content at the end of a long context is attended to more than content in the middle (the "lost in the middle" effect is well-documented). If you bury a critical constraint in paragraph seven of a twelve-paragraph system prompt, don't be surprised when the model misses it.
Order and Structure Affect Output Quality
The clearest demonstration of this is the before/after prompt comparison. Here's a prompt that produces inconsistent output:
You are a helpful assistant. Answer questions clearly and accurately.
The user is asking about our product pricing. We have three tiers:
Starter ($9/month), Pro ($29/month), and Enterprise (custom).
Don't mention competitors. Be friendly. Answer in 2-3 sentences.
The user's question follows.
And here's the same information structured as IA:
<role>
You are the pricing assistant for Acme. Answer questions about our pricing
tiers clearly and concisely.
</role>
<constraints>
- Respond in 2-3 sentences
- Do not mention competitors by name
</constraints>
<pricing>
- Starter: $9/month — for individuals, up to 3 projects
- Pro: $29/month — for small teams, up to 20 projects, priority support
- Enterprise: custom pricing — contact sales
</pricing>
<task>
Answer the user's question about pricing using only the information above.
</task>
The second version follows IA principles: hierarchy is explicit, related content is grouped, the task is separated from the context. The model knows where to find what it needs. The output is more consistent and easier to verify.
The Parallel to Information Architecture
In traditional IA, you organize content for a human audience that navigates actively — they scroll, scan, click. In context engineering, you organize content for a model that processes linearly with attention mechanisms. The mechanisms differ, but the design principles converge:
Put the most important thing first. In a system prompt, lead with the role and the single most important constraint. In a user message, state the task before the context.
Group related things. XML tags in prompts are not a stylistic preference — they're grouping mechanisms. <constraints> tells the model that everything inside is a constraint. Without grouping, the model has to infer relationships from proximity.
Don't bury the lead. If there's one thing the model must do — or must not do — it should not be in the middle of a long paragraph. It should be at the top, explicit, isolated.
Eliminate redundancy. Every redundant instruction dilutes the signal of every other instruction. If you say "be concise" three times, the model is not three times as concise — it's trying to figure out why you said it three times.
Practical Techniques
Structured XML works well for separating concerns in system prompts. Role, constraints, context, examples, and task are distinct concerns — tag them distinctly.
Role-based context means giving the model a specific identity rather than generic instructions. "You are a senior TypeScript engineer reviewing a PR for correctness" produces different (and usually better) behavior than "review this code."
Task decomposition means breaking a complex task into explicit steps in the prompt rather than describing the end state and hoping the model finds the path. "First, identify all functions that mutate state. Then, for each one, check whether it handles null inputs" is more reliable than "review this file for state mutation bugs."
Retrieved documents last — put context documents after the task statement, not before. The model should read the task first and then know what to look for in the documents.
Context engineering is IA. The audience is a model, not a person, but the practice of organizing information for a reader who can only see what you give them — and who will act on what they find — is the same discipline. Apply the same rigor.