A prompt is not a magic spell; it is the runtime environment you hand the model. Once you see context as a system with a budget and a layout, most “prompt engineering” problems become ordinary architecture problems.
This is a working note rather than a definitive guide — the patterns here come from systems I’ve actually shipped and the trade-offs I kept running into along the way.
Lay out the context window on purpose
I decide what belongs in the window the same way I decide what belongs in a request: stable instructions first, retrieved facts next, and the volatile turn-by-turn state last, where the model weights it most. Everything that earns its place gets a reason.
Context is the API surface between your system and the model.
Tools are the other half of that surface. Give the model a small, sharply-typed set of actions, validate every call, and you get a loop you can actually evaluate — and improve — instead of a black box you keep re-rolling.
None of this is glamorous, but it’s the part that decides whether a design holds up once real traffic and real deadlines arrive.