Context engineering: what the model sees next

Imagine giving the same model the same coding task twice. The first time, it receives one vague sentence. The second time, it can also see the relevant files, the project rules, the current git state, and the command that proves the change works. The model has not changed, but the second attempt has a much better chance of succeeding.

That difference is context. It is the working environment around the request: what the model can see, what it can use, and what it knows about the task at the moment it chooses its next action.

A prompt is the immediate instruction. Context engineering is the wider job of deciding which instructions, evidence, tools, and current state belong beside that prompt—and when each piece should appear.

One useful analogy is a computer. The model is the processor. The context window is its temporary working memory. Your files and databases are storage, and tools let it act on the outside world. The analogy is not exact, but it reveals the design problem: you would not load an entire hard drive into memory for one small task.

A large context window tells us how much text can fit. It does not guarantee that every detail will be noticed, connected, or used at the right time. Old logs, duplicated instructions, and unrelated documentation can compete with the one fact that actually matters.

Research on long-context models has found that information can be harder to use when it sits in the middle of a long input. The practical lesson is simple: do not measure context quality by volume. Measure it by whether the model can find and apply the right evidence for the next decision.

During the session, we reduced context engineering to four practical moves. They are useful whether you are working with a chat assistant, a coding agent, or a longer automated workflow.

Chats are useful working spaces, but they are poor long-term memory. Important decisions become buried in transcripts, and the next session begins without the reasoning that shaped the last one.

We looked at a practitioner pattern sometimes called an LLM Wiki: keep raw sources unchanged, then maintain a smaller set of linked Markdown pages that capture facts, decisions, contradictions, and provenance. The wiki is not a magical replacement for retrieval. It is a way to turn repeated work into a maintained knowledge structure the next task can navigate.

A strong memory system keeps concise, validated strategies and useful snippets. It does not preserve every sentence the model ever produced. Repeatedly rewriting noisy summaries can slowly weaken the original meaning, so the raw sources should remain available as the ground truth.

A short AGENTS.md or CLAUDE.md file can act as a routing layer for a codebase. It should tell the agent where the important knowledge lives, which rules are permanent, and how to verify its work. Detailed specifications, architecture notes, and decisions can stay in normal versioned files and be loaded when the task needs them.

The goal is not to squeeze the whole organisation into one instruction file. It is to give the agent a reliable map that points to the right source of truth.

We made the idea concrete with Pulse, a fictional employee check-in product. Its product brief, user research, and security policy did not agree on whether anonymous check-ins should be supported. That contradiction was intentional: real project context is rarely neat.

The workshop was not about asking the model to guess. It was about building a context system that could expose the disagreement, cite the original sources, and make the unresolved product decision visible to a human.

Before your next meaningful AI task, write a tiny context map: the goal, the relevant files, the constraints, the current state, and the command or observation that proves success. Then give the model that map and let it retrieve the details it needs.

This keeps the prompt focused without pretending the whole product can fit inside it. The prompt asks for the next action; the context system helps that action remain connected to the work around it.